<maximed>tribals: put the , before the (string-append: #~`(,(string-append foo bar ...) other things ...) <maximed>with #~`,((string-append ...) ...), you're trying to somehow use the result of string-append as a procedure <maximed>rust+cargo+crates.io: While it's great to have a system for not having to update everything at once when doing an incompatible update of a dependency, you often don't have to do that, please don't do 29 different incompatible 0.XX releases and forget to update dependents to the new API <maximed>18 done, 27 to do (some of which require changes to source code for new dependencies) ***yewscion is now known as yewscion-away-g
***yewscion-away-g is now known as yewscion
<fnstudio>hm... i've tried using guix system like this: guix system image -L . -e "(use-modules (my-oses)) my-base-os" but it doesn't work: error: '(use-modules (my-oses)) my-os' does not return an operating system or an image <fnstudio>if i try the exact same code in a file and run: guix system image -L file.scm, then that works <fnstudio>am i misunderstanding the way -e (--expression) should be used? ***yewscion is now known as yewscion-away-g
<patched[m]>Is it possible to build a package without checking the hash? I'd like to skip this for definitions of local packages. <nckx>Hopefully sometime this summer, but there is no clear timeline yet. <polyex>i tell everyone about guix. it's the best OS <polyex>no other way to manage all the complexity of computers <nckx>PotentialUser-90: Take this with a grain of salt as I'm not a KDE user, but I don't think KDE packaging or integration in Guix have changed significantly in quite a while. So whatever was true then is probably still true now. There simply aren't (m?)any KDE users that contribute to Guix. Chicken & egg & all that. <nckx>PotentialUser-90: Sway (the Wayland clone of i3). Not ‘really’ a DE, the nitpickers would say. <nckx>I spend 97% of my time in a terminal, emacs, or Web browser so the E would only get in the way. <singpolyma>nckx: better than a DE. But still Wayland so only partly better ;) <nckx>PotentialUser-90: That's just my preference though, not a Guix limitation. Quite a few Guixers use GNOME. We're just biased towards one of the big 2, for now, unfortunately. <nckx>singpolyma: I dread to ask what would be better… <nckx>Used i3 for years; config-file compatibility was a nice touch I'll admit. *nckx ~> AFK, perchance to dream, but maybe not. <PotentialUser-90>nckx: I appreciate the help. I like shiny looking things so KDE works for my purposes, but I was interested in it's approach to packages and apps not included in the Trisquel repos. I'm a casual user who mostly just needs browsers, mail and office stuff. Thx ***yewscion-away-g is now known as yewscion
<vagrantc>does python-build-system not support #:parallel-build? #f ... ? <vagrantc>i get Unrecognized keyword: #:parallel-build? ... when adding it to the patchwork package definition ***yewscion is now known as yewscion-away-g
***yewscion-away-g is now known as yewscion
***yewscion is now known as Guest1478
***yewscion is now known as yewscion-away-_g
<raguay>How would I install guix on Parrells for Mac on a M1 chipset? <unmatched-paren>raguay: i don't believe it would currently work, unless you're talking about asahi? even then i doubt it would function. <raguay>Does anyone know how to install guix on Parrells for Mac on a M1 chipset? <raguay>Yea, it's the faster VM on MacOS. <unmatched-paren>looks like a VM for running windows...? at least that's what they're marketing it as <raguay>I've looked all over the guix website and haven't found anything. The qemu build is still Intel chip only. I'm using an M1 chip system. <raguay>No, the vm have to have the same architecture. The site says it supports that chipset, but doesn't tell how. <raguay>I thought that aarch64 am M1 was the same. <unmatched-paren>so much so that there's a whole Linux distro project working to get linux running on m1 <unmatched-paren>The developers quickly realised that just attempting to boot the Linux kernel compiled for Apple silicon's processor architecture (AArch64) would be challenging, as it involved working out the functionality of proprietary Apple code used in the boot process. The work was time consuming and took most of the year, including submitting pull requests to the main Linux kernel developers to keep development in sync and avoid regressions. However, i <unmatched-paren>t subsequently led to a thorough and comprehensive explanation of the previously undocumented boot process, which Martin and others published on GitHub.[2] <raguay>Is it possilble to add on top of my existing Ubuntu for M1? <PurpleSym>Hm, is the recursive importer not inserting any blank lines between the packages for me only any more? <pranavats>Is there any effort to package Web Assembly software for guix? Like, are there packages for wabt or binaryen somewhere? <jpoiret>fnstudio: a bit late, but -e expects one statement only, so you should wrap that with a begin <jpoiret>or directly use (@ (my-module) my-os) <fnstudio>hey jpoiret, not late at all, i was just about giving this another try now <nikola_>Hello, I'm new to guix and i was just playing around with it in a VM <nikola_>Now I'm thinking about installing it to real hardware <nikola_>Are there any resources like tutorials to help me learn the proper way to manage the system <fnstudio>nikola_: did you have the chance to look at the official docs? <ardon>Hi Guix, I'm constantly getting this error "[GSSH ERROR] Channel opening failure: channel 67 error (2) open failed" when invoking `guix deploy'. As I pointed out a few days ago, if I re-run the command a few times it will eventually go through, but it's quite annoying. I should also add that when this happens I notice sshd-PID processes popping up in `herd status'. Has anyone else experienced this or know what might be the root of the <nikola_>Yes i have, i do have a few questions though <nikola_>For example, am i supposed to update guix separately for each user (my own and root) <voroskoi>i set up the user version to guix-daemon <fnstudio>nikola_: (disclaimer: i'm not an expert) i think there can be packages installed globally and those only need to be updated once - but individual users may have additional packages installed in their paths and those will have to be updated separately <nikola_>Also i have a Ryzen CPU with Vega graphics and an Intel wifi chip, what kind of support can i expect for them <jpoiret>you do not need to update root's guix <jpoiret>as long as you use sudo, you can use your own user's guix, but with root privileges <jpoiret>basically, the workflow would be: `guix pull` to update your copy of the Guix software (in the ~/.config/guix/current/ profile), `sudo guix system reconfigure /path/to/config.scm` to update your system generation with your new Guix copy, and `guix package -u` to update your user-installed packages (in the ~/.guix-profile/ profile) <jpoiret>steps 2 and 3 are independent and can be swapped <jpoiret>or you could do one but not the other (although there might be issues if eg we update the glibc) <nikola_>I just don't need to worry about root's guix <jpoiret>yep (and it might not have one, if you've never ran guix pull as root <nikola_>Are there known issues with guix and ryzen and Vega though <jpoiret>although it might not include everything <jpoiret>guix uses the linux-libre kernel, that removes proprietary blobs and the ability to load them <jpoiret>although you can easily switch which kernel you're using, but the Guix proper only provides support for linux-libre ***CodeKiwi is now known as DigitalKiwi
***wielaard is now known as mjw
<johnjaye>unmatched-paren: the vm reconfigure command froze again <johnjaye>i'll try one more time then maybe switch to qemu or hardware. <johnjaye>worst case scenario i can just use the install as is? <johnjaye>ok the gpg sig checks out. so it's not the downloaded file i think <nikola_>Has anyone written a runit service for the daemon <pranavats>jpoiret: I wonder what the status of your patch for grub2 is. The one fixing support for luks2. <jpoiret>pranavats: it's been reviewed twice (my c skills are terrible), but now there's a clearer picture of what we're going to do <jpoiret>basically, there is another patchset that does something similar (but not totally), and we're going to adapt them to keep the best of each <pranavats>jpoiret: I have the old patchset applied in my config. Where can I keep track.of this issue? ***GNUcifer is now known as cehteh
<apteryx>it's the 2nd Tuesday of the month ;-) <efraim>Oh, right. I'll be there in a minute <nikola`>I installed guix on my artix installation <nikola`>And it seems to prepend path with it's own path <nikola`>That is, when i try to use GCC it's always guix gcc <nikola`>Is there a way for that to not happen <rchar01>after: guix system delete-generations <rchar01>guix system: error: symlink: Permission denied: "//var/guix/gcroots/bootcfg.new.new" <ulfvonbelow>nikola`: I assume you refer specifically to your user profile (~/.guix-profile) and your 'guix pull' checkout (~/.config/guix/current)? You'll probably want to keep guix itself pretty early in the search order, but the user profile you could probably move farther back. The ideal solution would be to have your profile generated such that ~/.guix-profile/etc/profile appends rather than prepends, but I'm not sure how to do that. <nikola`>The script /etc/profile.d/guix.sh always prepends the guix path <DynastyMic>Greetings, I want to download Allegro CL on Guix, however I run on the following error: <nikola`>So when i move it out of profile.d i get my normal config <DynastyMic>~/guix-packages/acl10.1express.64 $ ./allegro-express <DynastyMic>/gnu/store/lnni4nl00jin1kp766ksb933dlpr7zr7-emacs-27.1/bin/emacs: /home/ivan/guix-packages/acl10.1express.64/allegro-express: No such file or directory <ulfvonbelow>it'll be a little slower than sourcing the profile, but you could change /etc/profile.d/guix.sh to instead use 'eval "$(guix package --search-paths=append -p ~/.guix-profile)"' <DynastyMic>Isn't it possible on guix to just decompress the installation and run with ./ ? <nikola`>Should i just manually source guix.sh when i need it <nikola`>I have to start the daemon manually anyway <ulfvonbelow>'guix package --search-paths -p <profile>' emits the environment variables that profile defines. --search-paths takes an optional parameter (one of 'exact', 'prefix', or 'suffix') that indicates where in the search paths those environment variables should go <ulfvonbelow>"exact" replaces the search paths altogether, "prefix" puts guix directories at the front of the search order, and "suffix" puts guix directories at the end of the search order <nikola`>Is it ok if I manually source guix.sh when i need it <rchar01>guix system: error: symlink: Permission denied: "//var/guix/gcroots/bootcfg.new.new" <ulfvonbelow>and (re)installing a bootloader definitely sounds like a system-wide action <rchar01>it is an error after guix system delete-generations <rchar01>is it sth wrong with deleting generations? <ulfvonbelow>when you say an error "after" guix system delete-generations, do you mean that the error message shows up after you press enter to run 'guix system delete-generations', or that after you ran it the first time, the error now shows up no matter what you try to do with 'guix system'? <ulfvonbelow>I'd say try to run 'sudo guix system delete-generations' <rchar01>after running the command: guix system delete-generations <avalenn>my bad, I forgot the "?" at "#:recursive?" <rchar01>What is the purpose of guix pull and guix upgrade, should I run both to upgrade the system (get the latest packages)? <ulfvonbelow>generally speaking, 'guix pull' gets updated package definitions (as well as an updated guix), while 'guix upgrade' replaces your user profile (~/.guix-profile) with one populated using the newly-obtained package definitions. <rchar01>I found everything in the manual, thanks again. :-) <reza[m]>is there a way to resolve symbolic links in guile? like readlink does in bash? <civodul>reza[m]: yes, it's called 'readlink' too :-) <reza[m]>ah nice, can I use it to get the real paths of files in a go build? <ulfvonbelow>and if you want "readlink -f", I believe that's 'canonicalize-path' <reza[m]>but itis using `//go:embed` to embed files into the source which does not accept symbolic links, how do I circumvent this? <reza[m]>I tried to use `canonicalize-path` but this does not seem to work <ekaitz>with the new input definition based on lists, how can I choose an input from a package making sure I chose the right one <ekaitz>imagine the case of a package that has an input that is (cross-libc triplet), how can I differentiate that from the libc that comes with the gcc toolchain? <abrenon>I don't think it changes something on the selection, since the list contains the values themselves, not their name <ulfvonbelow>you could use 'define' or 'let' to bind the result of cross-libc, then evaluate it both in the input list and in the gexp. <abrenon>but anyway, I think the new system still accepts the old assoc list form, doesn't it ? <ulfvonbelow>although it should also work to evaluate cross-libc twice with identical arguments <ekaitz>so they are directly obtained from the name of the package so for my case it's probably better to re-evaluate <ekaitz>did anyone find errors with `cross-base` <ekaitz>it's giving me weird errors to use it <ekaitz>in projects that didn't have them (I tried to time-machine and they work in the past) <ekaitz>looks like the commit b55310603f0df7d5ae02d47cb8d4be58bf1d41ca is weird <Guest2477>hello guys, why did the guix, which is a free distribution, restrict access to the site and repositories with ru ip? I can't open the website and install the system <vagrantc>Guest2477: it may be some point in between guix's hosted services, it was not a decision of guix <Guest2477>got it, I'll try hard to install the system via vpn, thanks for the answer. I hope the problem gets resolved <abrenon>ekaitz: what do you mean ? what's weird about this commit ? <ekaitz>abrenon: well, literally that it broke cross-base for me <abrenon>ok, sorry, I thought you meant something in the diff itself looked suspicious <ekaitz>abrenon: i'm porting stuff for riscv so i need to (cross-libc "riscv...") a lot and I don't know how but I'm pretty sure that commit broke the cross-base but I can't really explain why <ekaitz>abrenon: I mean, the commit is legit, but there's something weird there that it's breaking :( <Guest2477>vagrantc Thanks a lot for your help, I understand now <vagrantc>Guest2477: in a follow-up, seems like some ip blocks were banned due to attacks on the hosting provider <vagrantc>Guest2477: there's a mirror in china that might be accessible too ... don't have the URL handy <abrenon>I'm afraid I won't be of much help in that area, sorry : / <Guest2477>vagrantc I realized, I tried to install the system for an hour by passing traffic through TOR, but since it often changes bridges, this causes short-term Internet outages and an installation error, I will try to try through VPN <mitchell>Hello guix. I have a set of patches I would like to contribute. Can someone help me review them, I've never done this before <jpoiret>mitchell: have you looked at the "Submitting Patches" part of the manual? <vagrantc>mitchell: i've had ok-ish luck posting links to proposed patches here for really rough work-in-progress review <mitchell>jpoiret: Yes, I built several times and ran them through the linter. Now i have 4 patchs but I'm not sure what to do with them or how to arrange them <mitchell>vagrantc: any review would be appreciated. How do I do this? <vagrantc>mitchell: use the full commit hash, not a short one <mitchell>I wonder if its possible to add a rule for that in guix lint <vagrantc>and then there is (version (git-version "1.2.3" revision commit)) <vagrantc>mitchell: you'll also want to have in the commit something like * gnu/packages/fpga.scm (abc): ... describing the changes <vagrantc>mitchell: see other commits for examples <maximed>mitchell: Replace 'rev' by 'revision' <maximed>"guix refresh -u" knowns about 'revision' but does not recognise 'rev' <maximed>(will be important for the not-yet-compleded 'git-generic' updater, also currently important for Minetest mod packages on ContentDB) <maximed>mitchell: #:f is the keyword #:f, which will be interpreted as if it was #true, write #false instead <lechner>vagrantc: Hi, i'm not sure what that means. I sent them to guix-patches <vagrantc>lechner: if you sent to bug-guix@gnu.org ... but sounds like you didn't <maximed>mitchell: propagation is suboptimal for $various_reasons and can often be avoided by adding a phase that replaces an invocation of a program by the absolute path (try a combination of 'substitute*' and 'search-input-file') <lechner>vagrantc: Should they have gone there instead? <maximed>vagrant: There is a simpler way of setting the make flags: <maximed>(arguments (list #:tests? #false #:make-flags #~(list (string-append "PREFIX=" #$output)) #:phases #~(modify-phases ...))) <maximed>(probably no need to replace the 'install') <lechner>vagrantc: that's okay. i'll talk to you! <maximed>Though I'm not sure if the default install phase respects #:make-flags, maybe that's only for the build ĥase, so maybe not. <vagrantc>lechner: are the debbugs.gnu.org pages paginated? <mitchell>/maximed: There was a reason, but its been a while now so i've forgotten <maximed>mitchell: the indentation of modify-phases (for symbiyosys) is non-standard -- "./pre-inst-env guix style symbiyosys" should fix that <lechner>i've had more than 400 bugs in my packages <maximed>mitchell: (for symbiyosys): the makefile runs "gcc" to compile things. However, when cross-compiling (with guix build --target), the cross-compiler TARGET-gcc is required (where TARGET=aarch64-linux-gnu or such) <lechner>vagrantc: yeah, thanks! sorry, i have poor eyesight and thick glasses <mitchell>maximed: So i need to conditionally replace gcc by the cross compiler? <maximed>That could be fixed with #~(modify-phases ... (add-after 'unpack 'fix-cross-compilation (lambda _ (substitute* "Makefile" (("\\bgcc\\b") #$(cc-for-target))))))) <maximed>mitchell: If you use cc-for-target, you can make the replacement unconditional <mitchell>maximed: oh i see. I guess i just assumed the build system would handle details like that <maximed>#$(cc-for-target) -> TARGET-gcc when cross-compiling, #$(cc-for-target) -> gcc when compiling natively <maximed>mitchell: Some build systems take care of such details (e.g. meson-build-system) <maximed>However, no (guix) build system automatically patches makefiles <mitchell>maximed: Is there a reason that "gcc" isn't always pointing to cc-for-target? <maximed>mitchell: Because sometimes a native compiler is required even when the package is cross-compiled <maximed>some packages first compile a tool (natively, not cross-compiled) to generate ‘source’ code, and then compile the ‘source’ code with the cross-compiler <vagrantc>lechner: i can relate to subtle differences between bugs.debian.org and debbugs.gnu.org too :) <maximed>mitchell: cc-for-target currently assumes "gcc" or "target-gcc" (it never uses clang) <johnjaye>about how long should a 'guix system reconfigure /etc/config.scm' command take? <maximed>mitchell: For yices2: Guix supports non-linux and non-x86_64 systems <maximed>To figure out the GNU triplet (e.g. x86_64-unknown-linux-gnu), use (%current-target-system) <maximed>a combination of 'or', '%current-system', 'nix-system->gnu-triplet', '%current-target-system'? <maximed>There were some patches to simplify that ... <mitchell>seems like something that should be reified in gexp's <maximed>that will always return the "x86_64-unknown-linux-gnu"-like thing <mitchell>nikola: staged build expressions similar to traditional backquoted s-expressions but with syntax to make quoting/unquoting build expressions saner <maximed>nikola`: A convenience for separating the Guile code that runs in Guix and the Guile code that is run during the actual compilation <maximed>with some nice things for being able to import any module from any Guile package (even when not a dependency of Guix) -- using with-extensions <maximed>and being able to ‘copy’ modules from Guix -- using with-imported-modules <mitchell>#$target-system would be a nice thing to type <maximed>mitchell: You can type: #$(current-target-gnu-triplet) <mitchell>but that doesn't always work you were saying <maximed>mitchell: %current-target-system won't always work for your package, but current-target-gnu-triplet does <maximed>(the issue is that %current-target-system returns #false when compiling natively) <lechner>vagrantc: thanks again for your help! <maximed>mitchell: on symiyosys: the home page is considered to be conceptually separate from the repository url, even if sometimes they coincide <maximed>in this case, I'd consider the documentation website to be more home-y: <johnjaye>this reconfigure seems very prone to fail <johnjaye>my internet fluctuated and the process halted a minute after i started it <johnjaye>what exactly does system reconfigure do? <maximed>johnjaye: First it download everything that will be needed, then it performs the reconfiguration <mitchell>johnjaye: it attempts to make your current system reflect the operating-system fed to it. If you don't have the packages you need in your store it will attempt to download/build it <maximed>The first step requires Internet to download, the second step should be immune to shenanigans <johnjaye>ok. i'll babysit it until the download part finishse then <maximed>The first step is the same for "guix shell", "guix build", "guix package -u" <maximed>then you should have to intervene less often <johnjaye>can i just repeat the command like with apt until it finishes? <johnjaye>my internet is ideal for stress testing network things as it randomly disconnects every hour or so <johnjaye>well you see first the package name is printed. like gcc <johnjaye>then it prints these little # characters. #....#....#.... or like #####. then the hashes just stopped. very disconcerting you know <maximed>I mean, what's the last few output lines <maximed>johnjaye: I'd hesitate to run "sudo guix system reconfigure" in a loop, but running "guix system build" in a loop should be ok <maximed>(the latter only downloads/build the required things, without performing the actual changes) <johnjaye>unmatched-paren said to do guix pull && guix system reconfigure /etc/config.scm && guix upgrade <johnjaye>i have to do something like that with large apt upgrades as well. e.g. while true do apt-get install -y stuff <johnjaye>assuming the process has no problems how long should it take approximately. <johnjaye>this is from a fresh install in virtualbox with the iso <vagrantc>ugh. this has become a habit... guix gc --delete $(guix build PACKAGE) <maximed>depends on the number of packages and services in the system configuration and the speed of Internet (locally and on the substitute farm) <johnjaye>it's also disconcerting you don't find it disconcerting <johnjaye>this is the 3rd time i've tried to get guix working in a vm. download, verify iso with gpg, then install. very basic stuff. <johnjaye>so unless i'm really far out of line here I would think it shouldn't be this hard <maximed>I mean, Internet speeds vary around the world, how could a rando from the Internet have a clue how long the downloading will take for you? <johnjaye>i can get a debian system up with gnome in less than 24 hours. much less usually. <maximed>ok, I guess I misunderstood the question <maximed>I though the question was: how long does it take for "guix system reconfigure" to complete <johnjaye>ok fair enough. i meant here the total time to do all 3 commands plus the cd install. guix pull, system reconfigure, upgrade <johnjaye>like i can sit here today because i don't have to go anywhere. but i can't babysit this process constantly. <mitchell>use the one in the vm as the baseline. but edit it to look more like this <maximed>(1) start with a lightweight installation (you can always add stuff later) (like mitchell suggests) <Guest2491>will guix be faster than debian? for low perfomance system <maximed>(2) grab some reliable Internet if available <mitchell>but since you can fine tune the builds, some pieces of software may run faster. <maximed>(3) run thee "guix system build --keep-going" in a loop (while :; do guix system build --keep-going; dpne) <maximed>mitchell,Guest2491: (when using --tune, currently only available for a very few packages but could easily be added to others) <johnjaye>so the default /etc/config.scm has packages as %base-packages plus nss-certs <maximed>johnjaye: TBC, you're using the installer, right? <johnjaye>should i edit mate-desktop-service-type out of the services list? <johnjaye>maximed: virtualbox. 2G ram. 50G drive. installed and gpg verified iso from website. internet drops frequently <maximed>johnjaye: you could give it try I guess if you want to go desktopless, <maximed>but it has been a long time ago since I used the installer <johnjaye>that's a good idea. should give a better chance of completion <unmatched-paren>johnjaye: when i installed guix it did take some time, but not an hour... <johnjaye>then i might be able to get mate desktop afterward <johnjaye>ok. i let it run overnight since i had no reference for how long it would take <maximed>johnjaye: also (4): speed benefits from parallelism, so maybe use "-M 8" or such <johnjaye>well. i guess i can order a 50ft ethernet cable to test that assumption <maximed>johnjaye: WDYM with ‘that's a good idea’? (what idea was that referring to?) <johnjaye>the manual says -M 8 is for jobs. does that mean downloads or cpu time <maximed>it also includes building a package (technically, a derivation) <johnjaye>i thought it downloaded everything at the start <maximed>johnjaye: usually, yes (with some exceptions w.r.t. grafts, where Guix does not know in advance what to download) <maximed>"guix" usually downloads things before building things <maximed>so first the download jobs, then the build jobs <vagrantc>did the patches to split out the concept of download-jobs and build jobs not get merged? <vagrantc>e.g. you could have a different level of parallelism for downloads than builds <maximed>didn't know that build jobs and download jobs have separate parallelism <vagrantc>well, there was a patch set to make that possible ... <maximed>vagrantc: When I do "guix build --sources=transitive hexyl", it starts downloading sources one-by-one <maximed>vagrantc: When "guix build --sources=transitive hexyl -M4", it downloads multiple in parallel <mitchell>is the "-m" flag different then the "-c" flag <mitchell>i've been using "-c" to limit the number of cores <maximed>mitchell: Yes: --cores --> parallelism _inside_ a builder <maximed>(not necessarily respected by the package's build scripts) <johnjaye>wait. to be clear, this means that throughout the entire process it will be downloading things, then building, then downloading, then building? <maximed>Basically corresponds to "make -jCORES" <maximed>johnjaye: Well, if substitutes are available and grafts aren't complicating things, then it's first downloading, then building <maximed>but in some situations, you can have the latter <maximed>johnjaye: do you want to built everything from source (very slow, but possible) <unmatched-paren>Pretend there's a make target for each download and build. The builds depend on the download and their dependencies. Now imagine you're running the makefile with -j8, like maximed said. <johnjaye>i don't know what i want. i just ran the commands unmatched said. <johnjaye>if i want to develop at all i have to right? <maximed>or would you accept downloading ‘officially compiled’ versions from ci.guix.gnu.org? <unmatched-paren>johnjaye: it's only if you're really paranoid/have enough processing power <maximed>johnjaye: You can choose to switch whenever you want. <maximed>johnjaye: I noticed it downloaded a fuse tarball and gcc tarball, so maybe it's building from source <maximed>OTOH, findutils-4.8.0, so maybe a mix <maximed>I guess not everything had a substitute available? <unmatched-paren>can you see any .tar.* files being downloaded? those are likely source tarballs <jgibbons[m]>If I provide the things necessary to make a guix-produced Debian package for guix, including scripts to set up and clean up the daemon, will guix provide an offical .dpkg? <vagrantc>jgibbons[m]: you mean will guix have a .deb ? <vagrantc>offical is a bit of a confusing term when you're talking about two projects :) <vagrantc>admittedly, there are some inscrutible bugs in the debian guix package, but not really all that different from a foreign distro <vagrantc>or should i say Debian package of guix ? <vagrantc>as opposed to thise hypothetical Guix package for debian <unmatched-paren>vagrantc: i mean that the debian package is very outdated, and the only thing it's really good for is bootstrapping a `guix pull`ed version <vagrantc>the current released version of guix is available in debian bookworm/testing <vagrantc>though guix hasn't released for quite a while... <vagrantc>jgibbons[m]: yes, also the version in testing <vagrantc>well, maybe guix should release a new version then :) <vagrantc>unmatched-paren: but yes, i never really saw it as much more than something to bootstrap a trust path <unmatched-paren>vagrantc: i think that'll happen soon, but a rolling package management system that tracks master constantly is no fit for a stable distro's repos imo :) <Guest2491>Do you have a deluge torrent client installed without any problems? <vagrantc>i'll believe/package it when i see it! :) <vagrantc>jgibbons[m]: so are you talking about a .deb that more-or-less follows master ? <unmatched-paren>thing is, the releases will become outdated very quickly; they're only symbolic milestones <unmatched-paren>but yes, it's helpful for installing guix on a foreign distro easily. <unmatched-paren>apparently though the debian guix package shadows the guix pulled one <vagrantc>unmatched-paren: i've never had that problem <jgibbons[m]>It would be no more useless than the binary release or install iso <unmatched-paren>vagrantc: it seems to sometimes take priority in executable lookup over the pulled one <vagrantc>unmatched-paren: like, when your PATH doesn't include current/guix ? <unmatched-paren>vagrantc: i dunno. i've just seen that being reported, and vaguely remember it happening to me at some point -.o.- either way, i still think a .deb option would be overkill, although some `guix-bootstrap` executable would be nice to have for a similar purpose <jgibbons[m]>Options under "latest" are use CI and follow master, don't they? <unmatched-paren>you'd basically have no other choice but to uninstall the deb after you'e <vagrantc>unmatched-paren: that's just ... not true <maximed>vagrantc: Debian's guix package is convenient for setting up to daemon <unmatched-paren>or download a new guix deb, i guess, but then you'd lose channels and that process sounds a little annoying <vagrantc>maximed: although then it's stuck running an ancient daemon :) <maximed>though Debian seems to forget to update the deb when the daemon is updated <unmatched-paren>as in, i don't think you can use a guix that isn't from `guix pull` with alternative channels? please correct me if i'm wrong <vagrantc>guix doesn't update the daemon unless you reconfigure your system. same with debian. <maximed>vargrantc: I'm not seeing it in README.Debian <maximed>it doesn't say anything about being ancient <jgibbons[m]>Wouldn't the .deb install guix & daemon to a system profile? <maximed>It just installs it in /usr/bin/guix and /usr/bin/guix-daemon <jgibbons[m]>A guix-produced .deb includes a profile, doesn't it? <vagrantc>a guix packed .deb woudl be a little more different and ... presumably not too hard to build <maximed>vagrantc: I read that, but I don't see being mentioned there <johnjaye>unmatched-paren: ah yeah i get ya. it sounds like it's a debian stable situation where the stable is so old it takes a ton of effort to update it <vagrantc>maximed: "The guix-daemon and guix-publish servers are configured run from the binaries in /usr/bin, rather than from the "root" user's guix profile. <johnjaye>ok failed again. screw this. i'm doing that while build loop someone mentioned before <vagrantc>maximed: in other words, it updates guix daemon when you update the package. not from guix pull or whatever. <unmatched-paren>johnjaye: hmm... do you get an error pointing you to a compressed log file? <vagrantc>maximed: obviously, you can override that ... i guess i could spell that out in more detail <maximed>though the original remark was: ‘though Debian seems to forget to update the deb when the daemon is updated’ <unmatched-paren>johnjaye: sorry about this! it doesn't usually fail to install like this <vagrantc>maximed: it only packages the released versions of guix. <vagrantc>maximed: there might have been a security update patch or something <johnjaye>unmatched-paren: can you tell me the exact command then <vagrantc>maximed: it can't possibly follow guix-daemon from master ... <jgibbons[m]>guix-daemon on guix system is only updated with guix system reconfigure, correct? <maximed>vagrantc: the problem is that there sometimes are important changes to the daemon, leading to bug reports in bug-guix@ that (IIUC) result in ‘your daemon is ancient’ <unmatched-paren>johnjaye: i'm not entirely sure why you're running it in a loop; might be missing context from earlier. you probably have substitutes disabled, which would make the download take a lot longer of course <maximed>(though maybe that was for _really_ ancient like 1.1.0, maybe not 1.3.0) <johnjaye>no this is 1.3. just tell me exactly what to type <maximed>vagrantc: wait, "apt show guix" says 1.2.0-4 <unmatched-paren>johnjaye: it's usually guix system reconfigure /etc/config.scm... and i can tell that isn't working :( <vagrantc>maximed: current versions in debian are 1.2.0 and 1.3.0 ... if there are relevent guix-daemon patches (e.g. security) that need backporting, it could happen <johnjaye>unmatched-paren: the error this time said something about how a get was somewhat slow so i think it's still stuck on the download portion <unmatched-paren>ok, to be clear: is it that reconfigure is taking too long, and so your internet cuts out while it's doing stuff? <vagrantc>maximed: sounds like you're running "stable" currently named "bullseye" <jgibbons[m]>Can a guix-built .deb include a cron job that updates the profile that contains guix-daemon? <johnjaye>i'm not sure. last error was guix substitute: warning: while fetching... server is somewhat slow <vagrantc>jgibbons[m]: obviously, it can do whatever. it's basically a tarball with some scripts at runtime. <unmatched-paren>johnjaye: aha, that's the "haha your internet cut out take this cryptic message" error <jgibbons[m]>Would it be better to include an "update-guix-daemon" script? <johnjaye>ok. is there some analogue of repeating apt-get in a while loop? that's what i always did on debian <johnjaye>something like while:; sudo apt-get -y install mypackage; done <unmatched-paren>`guix system reconfigure` basically creates a system, then switches the "current system" symlink to the new system. `guix system build` does all that *except* changing the symlink <johnjaye>ok. i wasn't sure how to lookup the command. apparently 'man guix system' is sufficient <johnjaye>unmatched-paren: to be fair my networking is fairly unusual. it's good enough to do most common tasks. but debian and fedora installers hate it! <vagrantc>awesome ... node-addon-api ... has this integrity checksum that differs each time you build it: <vagrantc>│ │ │ │ │ + "_integrity": "sha512-LOfBSMNHncejhcGiQMdYi6QruOXGGb8vt7z0jaWGHw2Gc8HkO5/BmjPVocMgPiubf9mnHEsWqGXDxr7px9boBw==", <unmatched-paren>johnjaye: the majority of guix's documentation is in `info` format. as you probably know, info is knid of... opinionated <vagrantc>│ │ │ │ │ - "_integrity": "sha512-Sne3jnbNCK1ZTcM/5ve2Ehh7NQNNGo4nfjbVtwJWuUEAsy+1ZP1Z+qntA5dAUcWaV6QUpPtL8KZxswN2aK1NpQ==", <johnjaye>oh right i forgot. in gnu land everything is info <johnjaye>by the way. to help lighten the mood a bit. i tried running the install instructions through a tts reader just to see if it would work. <unmatched-paren>johnjaye: it's one of the only things where i prefer to use a web browser instead of the specialized tool :) <johnjaye>had several problems. but the command pronuncation in particular was bad. like chmod was "schmod" and "gnu" was "nu" <jgibbons[m]>So, back to my question, if I provide the things necessary to make a guix-produced Debian package for guix, including scripts to handle the daemon, would guix provide an offical .deb? <johnjaye>so i changed it to say "gu nu slash lee nux" <johnjaye>the hardest part i believe is that when it reads commands it doesn't read them like a human would. i'm just speculating. but i think like when you read an ip address say you don't read it in a monotone <vagrantc>jgibbons[m]: seems more appropriate question for guix-devel@gnu.org <unmatched-paren>the former sounds like someone dislikes chmod and is saying something along the lines of `chmod schmod`... :P <johnjaye>like one nine two dot one six eight dot. i think you put stress on the number syllables so it sounds more natural. so it sounds jarring when when the numbers and the punctuation are given equal volume <vagrantc>although i frequently run things via irc as a first pass too :) <unmatched-paren>johnjaye: anyway, running `guix system build /etc/config.scm` in your while loop should work <johnjaye>i did. it's saying a lot about substituting. like this line says substituting gnome-desktop <vagrantc>jgibbons[m]: i suspect you'd want to spell out what it provides over the existing options (e.g. binary tarball + installer script, the package from Debian, etc.) <johnjaye>ok. so it's purely a network issue maybe? *vagrantc breakfasts and wanders off <unmatched-paren>johnjaye: it's almost certainly guix just giving up when your internet temporarily disconnects <nckx>Guix doesn't handle disconnection well. The error reporting you've already noticed, and there's no resume-from-byte-X feature. <johnjaye>that's on the *new* bnet by the way. the one that has extra friendly reconnection <johnjaye>indeed. well i'm going to go now. come back in a few hours. if it fails i'll retry with no desktop. <vagrantc>johnjaye: can you set up another machine somewhere with a caching proxy close to you? <johnjaye>maybe. but i'd need a guide to do it. debian preferably <johnjaye>by the way i assume guix is based off debian? <nckx>So installing Debian has a Guixy vibe? I thought they used Calamares. <nckx>Only because I thought $everyone used Calamares. <unmatched-paren>and if a system doesn't use dpkg, can you even call it a debian-based system? <maximed_>sneek: later tell vagrantc: I've made a list at https://paste.debian.net/1243366/, possibly some of them are already in Debian's 'guix package' though. I guess I could give switching to Debian's guix a try ... <johnjaye>the text installer is probably the same i guess <vagrantc>i've installed many a hundred debians, but mostly with debian-installer, not calamares <sneek>Welcome back vagrantc, you have 1 message! <sneek>vagrantc, maximed_ says: I've made a list at https://paste.debian.net/1243366/, possibly some of them are already in Debian's 'guix package' though. I guess I could give switching to Debian's guix a try ... <johnjaye>red and blue make the most sense for high contarst <nckx>Once you go TUI, the only background colour anyone likes is blue, so you quickly end up in a vibe. <unmatched-paren>nckx: does debian use calamares though? last time i installed it, it used some fullscreen installer app <johnjaye>to be fair turbo c had a blue/yellow thing going on <nckx>unmatched-paren: I dunno! <unmatched-paren>i particularly remember the debian installer's somewhat oversized mouse for some reason... :P <johnjaye>debian allows graphical or text install. netinst uses text by default i believe <johnjaye>pro tip: if you want to boot with some preseeding params hit escape as the logo comes up <nckx>It's used by the ‘Live medium’ whatever that is. [wikipedia] <johnjaye>you can also access the rescue prompt but that is more indirect <johnjaye>anyway i'm off. thanks for the help unmatched-paren and everyone <unmatched-paren>and apparently they're replacing it with something web-based... naturally :( <maximed_>question: would downgrading the daemon (to 1.2.0 + Debian patches) be safe? <nckx>maximed_: That depends entirely on what ‘Debian patches’ means? E.g., they probably patch <https://bugs.gnu.org/47229>, but check, and I doubt anyone's going to stick their neck out with a ‘yep’. <maximed>(didn't expect a ‘yes, safe’ answer, but maybe there was an incompatible change in database format or something that people know about --> ‘nope’) <maximed>nckx: (on debian-legal) oof, I thought it was a mail about removing Guix for distributing GFDL+invariant-sections manuals (: <nckx>I think there were some bug fixes to how well it speaks the protocol but no changes to the protocol since 1.2.0. <nckx>maximed: Sorry for the false alarm! I was just happy to see Guix in a (to me) unexpected place. Now let's hope the Debian detectives don't discover something we missed. <maximed>not a false alarm, just speculation that was easily resolved by actually opening the link <nckx>All links on IRC should instantly and unquestionably be clicked. Especially when posted by me. <nckx>I don't know about you, but I would almost certainly click that? <nckx>See, the access.logs are rolling in. <unmatched-paren>we must immediately patch logs.guix.gnu.org to remove that message! :P <nckx>It will never die. Eons from now, people will emerge from their fallout shelters deep inside the husks of a scorched earth, and whisper ‘please, how to install guix sd?’. <the_tubular>I remember trying for a whole week trying to install guix for my first time <unmatched-paren>(is it bad that i only realized the joke was about the old guixsd name after you said 'please, how to install guix sd?'?) ***mark_ is now known as mjw
<nckx>(I was referring purely to the ‘guixsd’ name yes. Installer improvements of course welcome.) <unmatched-paren>either way, we must scrub it from existence. i will get my h4xx0r friends to ddos ur site!!!1 <nckx>unmatched-paren: I was clearly too cryptic, or I'm too easily triggered :) <nckx>unmatched-paren: I think that will be trivial considering what I ’spend’ on hosting it, so OK bye I guess. <nckx>unmatched-paren: I just don't understand where they come from? The Web site, the ISO file name, the manual, the installer, the boot process, all say ‘System’. 15 minutes (or fine, hours) later: ‘hooray I have finally installed Guix esdee’. *unmatched-paren looks up "how do i telephone the emacs psychiatrist" <nckx>Clearly it's an ineradicable meme. *nckx should replace that URL with something truly offensive now, or a cute animal, so people will think it was truly horrible before. <unmatched-paren>sorry, i'll have to pm you. as long as you promise you won't faint in horror *nckx has kicked unmatched-paren from #guix (That's illegal.) <unmatched-paren>(so as not to leave some future reader wondering: i was talking about people using 'GUIX' :) <nckx>I'm sure they were absolutely riveted. <nckx>vagrantc: Impressive work. Thanks. ***rgherdt_ is now known as rgherdt
<nckx>Thanks. That looks very familiar… <nckx>I have an unfinished fix-that-precise-thing branch that hasn't yet managed to fix it, despite the code looking right. I'll give it another go. <nckx>Your war on time and entropy. <vagrantc>i think i've tipped that balance by 0.02% by now! ***jfred_ is now known as jfred
<vagrantc>i've pushed 15 commits recently, two of which didn't fix everything, one of which fixed three packages ... 15-2+3 ... 16 fixed packages ... out of 22086 packages ... 16/22086*100 ~= 0.07 ... you're right! <vagrantc>more than three times the influence i thought! <vagrantc>532 out of 1081, to be more precise ... not quite the majority... <mitchell>why are the --system arguments not triplets like the --target arguments <mitchell>armhf-linux system vs arm-linux-gnueabihf target <vagrantc>not sure, but guix picked different architecture names than what gcc would represent ... some of the features do not necessarily directly map to gcc triplets <nckx>mitchell: Because that's what Nix used. Perhaps a better question for #nixos, though the only authoritative person is probably Eelco. <vagrantc>what are the pros and cons of modifying source using a snippet in the source of a package definition vs. a phase in the arguments ? <mitchell>I know this one! Snippets modify the source as returned by 'guix build --source' which should be buildable on a foreign distro without guix. Therefore you should not use snippets to embed store names. Only use them to modify things like bundled projects and non-free aspects <mitchell>Use phases to patch sources with store names <maximed>mitchell: They are also used for non-bundled things and free things. <maximed>E.g., in case of a security fix to apply a patch <maximed>... actually, that's patches, not snippet <vagrantc>so ... using a phase will allow you to use the same tarball, whereas a snippet (or patches?) will actually generate a new tarball? <vagrantc>i've noticed occasionally some packages generate what appear to be multiple source tarballs in the process of building them ... linux-libre and maybe u-boot? <maximed>Though for some simple fixes I found writing a snippet more convenient than a patch or phase (in antioxidant) <maximed>(technically dependency updates but whatever) <mitchell>from section 19.4.5 "The boundary between using an origin snippet versus a build phase to <mitchell>modify the sources of a package can be elusive. Origin snippets are <mitchell>typically used to remove unwanted files such as bundled libraries, <mitchell>nonfree sources, or to apply simple substitutions. The source derived <mitchell>from an origin should produce a source that can be used to build the <mitchell>package on any system that the upstream package supports (i.e., act as <mitchell>the corresponding source). In particular, origin snippets must not <mitchell>embed store items in the sources; such patching should rather be done <mitchell>using build phases. Refer to the ‘origin’ record documentation for more <mitchell>information (*note origin Reference::)." <maximed>vagrantc: yes: if a snippet or patch is used, then Guix will unpack the source, apply the patch/snippet, and make a tarball again <maximed>something something about making the patching process transparant for the #:phases and build system <vagrantc>mitchell: well, good for being thorough, not so great for irc ettiquette :) <nckx>The idea being that the unpatched source is never 'offered' to the user. (FSDG) <nckx>It's frankly your client's fault, mitchell, though mine doesn't warn either. <mitchell>emacs would never do me dirty like that! <vagrantc>i suspect historically i've updated some packages that ought to use snippets that instead use phases as it was just what i was familiar with <maximed>I think the most important here is (1) it works (2) without licensing issues <maximed>and that the rest is a matter of convenience <maximed>(e.g., offering a source tarball usable on other distros is convenient, but IMO comes secondary to making it work on Guix) <maximed>I don't think there's a consensus on the border <mitchell>I think it offers a nice conceptual distinction though. If it breaks the build on another system maybe it ought to be a phase. <maximed>mitchell: There are some packages which removes bundled Windows binaries (because bundled, binary, and sometimes non-free) <maximed>that probably breaks the build on Windows systems <apteryx>'guix import pypi something' no longer outputs a trailing newline <maximed>mitchell: I've seen something likewise for Android (bundled, binary, but free) <nckx>Snippets aren't the place to put Guix-specific patches, for example. A --source that won't build without substitute*s is fine. Some folks don't get that. <nckx>Snippets should only remove 'questionable' code (legal, CVE). In practice this isn't always followed but that doesn't make it right. <maximed>mitchell: So it looks like a good criterium but not usable as a hard rule to me. <maximed>nckx: What about fixing bugs in a snippet, in a non-Guix-specific manner? <maximed>AFAIK fixing bugs is allowed in 'patches'. <maximed>So why is it allowed in patches but not in snippet? <unmatched-paren>mitchell: i use them for large changes that would be inconvenient to implement with e.g. substitute* <nckx>Patches make it muddy, just because of how they are implemented. <nckx>You'd need 2 patches fields for it to work. <maximed>nckx: For a more concrete situation, some time in the past I added MINETEST_MOD_PATH to Minetest, with a patch. <maximed>This patch was Guix-specific, but would also build on other systems. <maximed>This patch was added to the 'patches' field of 'origin', and not a phase. <nckx>Right. So it shows up in --source, when ideally it wouldn't, but that's just how patches are implemented. There is no concept of Guix-specific patchen and not-. <maximed>nckx: I don't follow with ‘when ideally it wouldn't’. <maximed>It's portable source code, and it adds something nice. <nckx>Ideally, guix build --source foo returns FSDG compliant code, not Guix specific code. In practice Guix-specific patches sneak in as an implementation detail: there's no 'apply-extra-guix-patches phase. <mitchell>why not a 'native-patches' field to the origin <nckx>What is a non-native patch? <maximed>nckx: I guess my problem with that, is that then the 'patches' field only exist because of the existence of non-free software. <nckx>I'm not saying patches should be system-specific! God no. <maximed>So if all software was free by law or something, then 'patches' wouldn't serve any purpose anymore. <maximed>But 'patches' could be useful even in a free world (e.g., the MINETEST_MOD_PATH patch). <nckx>mitchell: Sorry, I don't understand. Native applies to machine code, not source code. Patches apply only to source code. <vagrantc>wow, wine64. never thought i'd be building that. *vagrantc slices some timestamps out of wine64 <maximed>So, why restrict 'patches' to FSDG and CVE issues, why not expand it purpose. <vagrantc>nckx: what is the reason you want an un-guix-ified source? <mitchell>nckx: in package input definition "native" applies to things that only need to be there at build time. So i guess i was thinking a "native patch" would be one that only applied to our system <nckx>--source is not a recommendation algorithm, 'you asked for grep, but we think you'll love our VRgrep patch'. <nckx>'Adding nice features' is not its place. <vagrantc>well, if you want the upstream source, download the upstream source? <maximed>vagrantc,nckx: Like, if you want un-guix-ified source, why not just download a tarball/git clone from upstream instead of downstream. <maximed>nckx: My interpretation of "guix build --source grep" is: give me the source code of the 'grep' package. <maximed>And if our 'grep' package is extended with the VRgrep patch, then to me that implies the source code includes the vrgrep patch. <maximed>Like, I ask the source code of the 'grep' package from _Guix_, so I expect the source code of the _Guix_ package, not upstream's grep. <nckx>mitchell: How would a patch apply only during build but not affect the final output? <nckx>maximed: Yes. You've made it abundantly clear, thanks. *nckx e mobile, having trouble keeping up :-( <vagrantc>patching files not used during the build :) <nckx>Verified to have no effect. <vagrantc>i daresay a few of my "fixes" recently feel that way <mitchell>nckx: I do not know lol. I haven't thought about it that hard <vagrantc>"fixed it for me, but ci and bordeaux have different ideas" <nckx>Ohkay, sorry for banging on. I thought you had an underlying pount I was totally missing. <vagrantc>many ruby packages in guix aren't reproducible due to unsorted gunk in various shipped .gem* files ... something similar for node too <nckx>Naïve question: why does unsorted input matter? <nckx>I'm gonna regret learning this but shoot. <unmatched-paren>how to make a reproducible, bootstrappable package manager: build the source code of npm into a standalone executable that embeds node, then one's-complement (bitwise not) it. easy. <unmatched-paren>now when you run it you will get a well-behaved program that cooperates gracefully with distro packaging! :D <nckx>*unsorted but constant input, you get my *inhales* *ok* *i can do this* point. <nckx>The first one isn't emphasis, it's *correction. Just to trigger you. <nckx>Apparently not a universal convention, OK. *unmatched-paren adds a second item to REASONS_TO_USE_SED_ON_IRC.txt, below "Feeling smugly superior" <nckx>Sedding means I have to type twice as much. <nckx>Think 'thefuck', not 'sed'. <vagrantc>nckx: unsorted input may not matter as long as the output is sorted ... but sometimes the easiest way to get sorted output is to sort the input too ... <nckx>My fingies are getting really owie, I need to take a break. <nckx>Not really but this is Ruby & Node, I'll believe anything unbelievable. <vagrantc>i don't quite see it yet, that's why i've skipped all those so far :) <vagrantc>i've seen similar issues in python, but know how to fix some of them <DynastyMic>hi, does anyone have a guide on how to build a program on guix which uses its own ./install-program file <oriansj>the_tubular: would there be a point to that as most channels are logged? <maximed>DynastyMac: you probably have to replace the 'build' and 'install' phase <maximed>The specifics depend on the package. <maximed>I haven't seen an 'install-pgoram' file before. <maximed>oransj: I think the_tubular is looking for a package named mitmproxy: <maximed>the software, not the underlying concept <the_tubular>You don't attack SSL, you mitm yourself so you can see https in the clear higher on your network <oriansj>maximed: didn't parse that from the statement but I might be biased to writing code rather than finding the name for existing code <maximed>the_tubular: I don't know a package definition, but apparently it's on pypi <maximed>so the dependencies should be available with "guix import pypi" <maximed>the_tubular: I tried that, but it fails because only a binary version is on pypi <maximed>There used to be one, but it has been removved for having become broken. <the_tubular>I mean a good working one could give us access to tons of software. <kennyballou>I guess my question is realy: is there a way to specify the file mode to `computed-file`? I cannot seem to change the file during activation because the store is read-only, etc. <ulfvonbelow>kennyballou: after a store item is built, it is immutable. Regardless of what you set its permissions to during the building process, it will always end up with write permissions off for all users. If you need the config file to be writable, you'll have to copy an initial version to a non-store location where it can be found. <kennyballou>ulfvonbelow: I don't really need the file to be writable. I would simply like to modify the permissions so that I can start a service that performs a permissions check. Thank you for the confirmation. I was thinking that there's no way to do this because it essentially violates the principle of the store. <kennyballou>ulfvonbelow: you even suggested as much in your answer, again, thank you. <nckx>Immutability aside, you can't create files in the store that aren't world-readable. If slurm's whining about that then the above is your only option. <nckx>Of course, it's still theatre: the original file will still be in the store, readable. <kennyballou>nckx: yes, thankfully I can punt that problem for now since this is really only for my own local installations. I'm (un)?fortunately not managing an "actual" cluster. <vagrantc>hrm. have a few patches which remove timestamps, but don't solve reproducibility issues completely... hrm. <kennyballou>nckx: to competely unravel the onion, I'm trying to debug why jobs submitted by GWL aren't succeeding. I may be chasing something that doesn't even matter. <nckx>vagrantc: I have a similar ‘fix’ for smlnj. The other mismatches dwarf it, so it feels silly to push, but… hrm. *nckx was going to say ‘be sure to join #guix-hpc, kennyballou’ but… you did :) That channel is less active and GWL questions are certainly welcome here, but I haven't used it myself. <johnjaye>nckx: is most work on guix adjusting projects to build on guix? <johnjaye>i'm browsing the mailing list but i can't tell <vagrantc>and just keeping up with a constant stream of updates ... <vagrantc>also, because of the design, updating packages that directly or indirectly are used to built everything ... end up getting put into staging or core-updates, depending on how much has to be rebuilt when they are updated <vagrantc>but merging those branches tends to be challenging <nckx>johnjaye: Hm, I'm not sure how to measure or answer that. Most work is probably maintenance & integration work: making packages work together, not segfault, actually start a full DE, etc. Some of that work is necessary because Guix does some things differently, sure, but… I think that it's the majority of work in *most* distributions? <johnjaye>that makes sense. debian is probably similar <vagrantc>the rebuild cycles are definitely harder debian <nckx>So the possible implication (not saying it's yours) that ‘guix weird = more work’ isn't true. Plus, some of the weirdness actually helps save time. That's why it exists at all, after all. <vagrantc>guix sacrafices some conveniences for arguably more correctness (e.g. not assuming a "minor" library update is compatible with the old one) <nckx>The rebuild cycles are definitely long, but I don't know if they cause more human-hours in the end. It's more that we're a tiny team in comparison and honestly not very disciplined about it all… <nckx>That's a high-level answer. Maybe you meant: when adding a new package. I'd say yes, but that's the only ‘creative’ part of packaging anyway 😛 The rest is just copy-pasting descriptions, URLs, and dependencies. <nckx>So writing phases to adjust the build system to Guix can be 0% of the effort (well-behaved autotools) or 16,000% compared to the rest of the <package> boilerplate, it's not really that meaningful and depends heavily on the package. *nckx rambles off to bed; good night Guix o/ 