<dftxbs3e>it's passing algorithm, name, etc. to guix-daemon and the hash is not calculated in the Scheme code (expected, since that runs unprivileged)
<sundbry>i dont understand what youre doing guix will recompile itself if you modify some super low level package like libc or mesboot or jemalloc which will trigger the whoel world to rebiuld from source
<vagrantc>and then you'll need wip-full-source-bootstrap-for-real once wip-full-source-bootstrap is merged, too :)
<dftxbs3e>luke-jr, oh okay, so you want to reproduce the bootstrap binaries?
<luke-jr>dftxbs3e: or just run the ones I have, either way
<dongcarl>dftxbs3e: Yes, but from his own Gentoo install
<luke-jr>if I need to recompile tar/bash/mkdir/xz again, no big deal
<luke-jr>I suspect it would just work if I could add my existing ones to the store with a false store hash ☺
<sundbry>you should probably stop screwing around with hacking hashes etc and figure out how to write a package first
<sundbry>then you could just write a package to provide gcc etc using your binaries
<dftxbs3e>luke-jr, don't do that, instead, you can use make-bootstrap.scm to re-generate the bootstrap binaries. You need to find the exact commit that was used to generate those bootstrap binaries with gnu/packages/make-bootstrap.scm
<vagrantc>luke-jr: fwiw, the filename passed to guix download affects the /gnu/store/HASH
<vagrantc>well, if you build a simple C program, it will have /gnu/store/HASH-glibc-VERSION/lib/... embedded in it
<dftxbs3e>luke-jr, replace what hashes, gnu guix calculates them for you if you change the file without the hash, you can then use that hash, if you write a gnu guix package to generate the bootstrap hashes it will give you their hashes outright, otherwise rely on the error
<vagrantc>i might be mixing different issues, though
<dftxbs3e>luke-jr, please explain precisely what you have done and the errors you're getting
<dftxbs3e>If you empty the list, or make it point to a local directory or URI, you are certain it will only get them from here if ever
<dftxbs3e>Once full-source-bootstrap is here, I believe that will be much easier to achieve since there wont be any third party binary. Still can't find out how i686-linux bootstrap binaries were generated, still investigating.
<dftxbs3e>Full Source Bootstrap already works AFAIK, it's just not merged yet
<dftxbs3e>luke-jr, it doesnt really feel good expressing how annoyed you are in this channel, a bit accusatory to be honest. Full Source Bootstrap is ongoing work, if you want to participate, please do. And report binary blobs issues at firstname.lastname@example.org
<dftxbs3e>And have a conversation with civodul (for historical knowledge) or OriansJ and janneke (for their investigations and work on full source bootstrap) about the bootstrapping, they may be able to tell you more.
<dftxbs3e>OriansJ, they are trying to compile GNU Guix from their handmade bootstrap binaries set (they do not want to download any binary from online and want to reuse the ones from their Gentoo install)
<dftxbs3e>They are not using Full Source Bootstrap yet AFAICT
<OriansJ>dftxbs3e: fair and actively encouraged on the #bootstrappable side
<entre-parentesis>The issue I'm running into is a build issue with the package because (from what I've gathered) I don't have the dbus development libraries installed (I'd be happy to share the exact error rust message, if it helps).
<entre-parentesis>I have found the `dbus-c++` and `dbus-cxx` packages but am not convinced that either of them are what I need for building this package - i.e. equivalent to the `dbus-devel` package (for instance) on Debian.
<entre-parentesis>Could anyone suggest if one of these are the packages I need or if I'm just missing something else?
<vagrantc>maybe i should go back to my fallback plan of reverting the one upstream patch that i think breaks with python 3.8
<vagrantc>well, that seems to be going well, rather than tests erroring out and/or failing, i'm getting passed tests :)
<entre-parentesis>lfam: Ah, yes... I messed up my configuration. I had `#:cargo-inputs` specified (which included "rust-dbus") but I forgot to include `#:inputs` (which would need to include "dbus"). Thank you, again, for your assistance. First package built! :)
<awb99>I have some difficulty understanding the channel with all the patches. It seems for example that postgres and mongodb in the official main channel are 2 years old. But the patches repo is up to date. How would I use packages from the Patches? Adding the patches channel to my profile? Does it work like a normal channel? Or would I just have to select certain patches that are applied to the official channel? Thanks!
<dftxbs3e>awb99, hello! what do you mean the patches channel?
<brendyyn>awb99: people enjoy adding new things more than updating old things or reviewing other peoples stuff, so thats how it goes. i wish we could get donation money to fund someone doing this important boring stuff
<dftxbs3e>I think we instead have to make it funnier to review things
<dftxbs3e>People don't like it because it's a repetitive and under-optimized process
<awb99>Or patches are first moved to a unstable channel. And then somehow it has to be tracked how many people use the dev packages. Atvs threshold one could roll to stable automatically
<dftxbs3e>awb99, I think two channels for "well-maintained" vs "left behind" would be great
<awb99>Also what I think is missing is a list of public channels.
<dftxbs3e>But we need reviewing always because the software provided can't be mislabeled or straight out malware
<awb99>I had to google as few days to find channels
<dftxbs3e>Maybe there's a way to do "sandboxed channels"
<dftxbs3e>I am going to update postgresql to 13.2 :-D
<awb99>I am pretty new to guix. I see it's huge potential. Now I am thinking how I can actually start using it. And so one of my first steps was to install all the stuff I normally use and then export the manifest.
<awb99>And where I struggled was that a lot of stuff I am using right now is mainly in patches.
<awb99>For data science a lot has been done is some of the channels that I posted above.
<terpri>snowdrift.coop might be promising in the future, although it's basically in alpha right now (hosted by hcoop.net of course :))
<awb99>So I am working on my developer laptop (running fedora) and use Guix currently only as a package manager. I am beginning to install stuff I need via guix. And then I am removing the apps that work via Guix from my fedora dnf package manager.
<cbaines>currently, I don't think there's a way in the Guix Data Service to compare build status across architectures, like find packages that build on x86_64-linux but fail on powerpc64le-linux, but that might come in useful maybe
<dftxbs3e>cbaines, by the way last time I told you about sending info about builds to the mailing lits, you told me "added", what did you mean exactly? Since I've seen no automated follow up to any bug about successful builds for example.
<cbaines>My longer term plan for things like notifications is to get the Guix Data Service sending out a stream of events, and then support subscribing to those via an intermediate service
<dftxbs3e>cbaines, maybe integrate into mumi's or debbugs UI without spamming automated messages to the mailing list? Well on the Linux mailing lists for example, they send out automated emails from some build farms to patch authors.
<leoprikler>Can someone fix our docs? db6b9d2f inadvertently broke `guix pull` without itself being related to the error message.
<gn21[m]>Hello, my default browser on trisquel and abrowser, but when I click on a link in telegram-desktop installed via guix opens the browser chromium also installed via guix. I would like to open in my standard browser. Thanks
<kondor>After long while, I am running Guix as an OS again. Can someone tell me how does one update packages inside `(packages ...)` section of the system configuration file. Is it enough to do `guix system reconfigure ...` after a pull?
<brown121407>What's the official position on using #:skip-build? #t for Rust packages? I see the importer does it by default, but the manual says "we try to refrain from ... using #:skip-build? when possible"
<luke-jr>pivoting: how do I get a SSH server on the official VM image? (not sure why it isn't just enabled by default..)
<luke-jr>don't see any mention in the docs where the operating-system file thing is supposed to be
<brown121407>luke-jr: I think the system config after installation is in /etc/config.scm
<roptat>also, the guix you have in the VM can only know about an older version of guix than itself, so you're also installing an older guix. Unless you run guix pull in there, you'll keep downgrading the VM
<roptat>if yes, you want to look into /run/booted-system instead or current-system
*kondor thinking out loud: isn't it better to create *package bundles* (a virtual package listing bunch of propagated inputs) than multiple profiles? Easier to combine these bundles together than different profiles.
<jackhill>argylelabcoat: Yes, I use guix gopy over ssh. I assume it's not working for you. What goes wrong?
<roptat>the version that was on the machine that generated the VM, but not on the VM itself
<roptat>anyway, I'd like to treat it as a bug on our side, but pulling this commit should help you
<jackhill>argylelabcoat, dissoc: hmmm, I think someone else is going to have to step in for help wiht the ssh authorization. I have mine set up with passwordless keys (perhaps bad, but I have a need for the copies to be automated sometimes).
<dissoc>jackhill: i was under the impression it had to use ssh key and no password. that's how i used it
<orbz>Hello! Have a problem with `guix-eval' from emacs-guix.
*luke-jr recreates teh VM to make sure it wasn't past stuff bloating it
<jackhill>argylelabcoat: another thing to check: you've authorized the signing key of the sending machine on the receiving one?
<argylelabcoat>jackhill, yes, I copied the signing_key.pub over there and authorized it
<luke-jr>roptat: does guix pull --commit actually tell git to only get what it needs for that commit? :x
<luke-jr>just that one step pulls in 187 MB; would think it'd be much smaller
<dissoc>argylelabcoat: ussing ssh from command line works with no errors?
<jackhill>argylelabcoat: Unfortunately, I'm out of ideas. I was hoping that I could look at my working configuration and help, but there doesn't seem much to my configuration, it just worked. I do continue to think it's independent of the package definition, but since I don't know what the problem is, who am I to say :)
<argylelabcoat>yeah, I can ssh just fine, no password prompt, I just am instantly over there, running Ubuntu 20 on both machines and guix at same commit on both
<jackhill>argylelabcoat: oh! All my hosts run Guix System. I wonder if it's a PATH or environment issue, and it's not finding the right guix command on the remote host.
<argylelabcoat>I'm worried that to be able to function, I'll have to do something awful and wrap a binary distribution of node@12 in a guix package with the copy build system
<jackhill>argylelabcoat: yeah :/ Hopefully someone else will step in an save the day
<argylelabcoat>jackhill, thanks for trying, I greatly appreciate the helpfulness of the guix community
<orbz>The following string is working as expected using guix-eval-in-repl: "(use-modules (guix packages) (gnu packages emacs-xyz)) (package-home-page emacs-guix)" and returns a string of url (in guix repl). But with guix-eval happens this:
<argylelabcoat>I'm hoping I get competent enough with this tool to be more of use to others
<ejh>in gdm usually there is a cog graphic for changing desktop environments but I'm not seeing it in guixsd
<ngz>I want to hack on the crate importer to fix a bug. I modified it locally. But when I want to test my changes using "./pre-inst-env guix import crate foo", I get a backtrace unrelated to my change. What is the proper way to test them?
<luke-jr>roptat: while you're fixing issues with the VM image.. can there be *some* way (ideally just preinstall SSH server) to access it without a GUI? :P
<roptat>luke-jr, yeah, that shouldn't be too hard ^^
<lf94>So yesterday I decided to look into Guix. Mind=blown.
<lf94>The manual is super well done. Excellent work to whoever put it together.
<luke-jr>roptat: well, the hard part would be communicating a SSH key to it safely ☺
<leoprikler>kondor: regarding virtual packages, that does not actually solve all problems, that multiple profiles solve
<leoprikler>sure, you get easy environments and "simple" installations, but you still blow up the default profile
<dissoc>i would image writing the policies for selinux would be interesting since the programs exist in non standard locations
<lfam>I configured the build with "--localstatedir=/var --sysconfdir=/etc", built it, and then ran `sudo -E ./pre-inst-env guix-daemon --build-users-group=guixbuild --substitute-urls=https://ci.guix.gnu.org` as recommended in the manual section Running Guix Before It Is Installed
<lf94>I imagine the common case is with substitutes if guix becomes more popular
<rekado_>upgrades on that machine have to be well-planned, because substitutes might not be available and the machine might freeze
<rekado_>(“freeze” is an odd way of saying “overheat”, hmm)
<lf94>Im surprised there is no flag to say "stop installation if no subs"
<roptat>for a server, 10 or 20 GB of storage are enough, for a desktop machine, you'd need 50GB or so to feel confortable (honestly I have a few big packages and 120GB are sometimes not enough)
<lfam>One *huge* impediment to replacing apt/dpkg with guix would be that Debian doesn't use a monorepo. Packaging workflow is totally decentralized, for better or (definitely) for worse. Socially, that would be impossible to change, I think. It would probably destroy the Debian community to really push for a change on that
<jackhill>lf94: I didn't monitor it very closely, I was using the small VM to test other stuff, but probably, I don't think it ended up using that much swap. Naturally, it depends on what else guix is competing with for resorses :)
<lf94>jackhill: fair. I would then say 1GB is "safest"
<lfam>nckx: Regarding branching, people kept pushing to the wrong branch even after we merged the latest staging branch into master. I thought by forcing a choice between -frozen and -next, it would make people think about what they were doing and investigate the right course of action
<roptat>I kinda remember before I added some swap to the server, I had to stop my nginx service for guix pull to complete ^^'
<roptat>then I created a small swap file, and I haven't had to stop the server since then
<nckx>lf94: One of the (not insurmountable) issues with a ‘--substitutes-only’ flag is that some profile derivations always get built locally, and there's no way to draw a line without doing so manually, which is a bit ick. Possible, though.
<lfam>nckx: It's not really normal to only have a -next branch. That was something I ignored for a bit while we discussed improvements to the workflow
<nckx>lfam: Git won't warn that you're creating a new branch unless I'm mistaken?
<lf94>nckx: I think it'd still be good even if some manual intervention is needed.
<rekado_>lf94: one way around this is to use a more powerful machine to build packages when needed.
<nckx>Tab-completing both lf94 and lfam is fun and doesn't confuse HexChat at all 😛
<rekado_>the i686 could ask the more powerful x86_64 laptop to build things
<lf94>rekado_: not everyone has more powerful machine.
<nckx>lfam: To be clear, I'm suggesting never having a -next branch, and sometimes having a -frozen fork that receives no or minimal (fix-build-style) updates before being merged & deleted. So ‘staging’ is *always* the right place to push, unless you're fixing the build of staging-frozen (in which case, you're very aware that it's the branch you want).
<lf94>I think it's important for software to be accessible to most hardware.
<nckx>Does that not make sense? Maybe it does not make sense.
<lfam>nckx: Yeah, it makes sense. But I think people will end up pushing their fixlets to e.g. "staging" instead of "staging-frozen"
<roptat>lf94, in a package, you have build systems, descriptions, different types of inputs, ... a bag has no build system, but build instructions, only native and non-native inputs, some other minor differences
<luke-jr>roptat: another thing: apparently the UEFI partition is AFTER the rootfs, which makes it a pain to resize the Linux one
<nckx>Never heard of it but ‘devel branch with feature branches’ sounds like us.
<roptat>luke-jr, I'd encourage you to send a bug report then :)
<lf94>nckx: ah ok. it's the popularized term for it
<nckx>Thank you. Good to know it's not just me at least.
<ngz>I have a question about hacking Guix. I want to fix a bug in the crate importer. So I apply some changes, add some (pk ...) around, but when I try ./pre-inst-env guix import crate whatever, I get unrelated errors. So, how am I supposed to check my changes?
<ngz>(a video on how to hack Guix proper would be terrific, BTW)
<roptat>ngz, well you'd have to fix these errors first
<guix-noob>hi, is it possible for someone to help me with my config.scm? I recently installed guix and I wanted to make my xorg configured right so I tried to use set-xorg-configuration but it looks like I did it wrong. guix system configure suggests that I forgot a use-modules; unfortunately I don't know much scheme/lisp currently so I'm kind of flying blind