<PotentialUser-39>Just to check if i did everything right: i made a 1gb partition in cfdisk with EFI system as its type, then i marked it with esp in parted, then i mounted it in /mnt/boot/efi and proceded with the installation
<Brendan[m]2>I'm trying to package something that requires an -alpha2 rust package. it errors with "prerelease package needs to be specified explicitly". Any idea how to make them behave?
<Brendan[m]2>Actually, turns out I'm a big dummy. there is a lower major version release i think works
<mfg>is there a place in guix where files are stored which are just copied into a build?
<peanutbutterandc>Question: I've been seeing a lot of guix.scm in quite a few repos. Like this one: https://termbin.com/vgbp and I know that it's supposed to be used with `guix environment -l guix.scm` to start up a build/dev environment. But this particular guix.scm file does not work. Am I missing something?
<peanutbutterandc>wait... neither does the guix.scm in the guix repo works for me with `guix environment -l guix.scm`. Educate me please.
<mfg>peanutbutterandc: -l evaluates that file, i think this is not what you want
<peanutbutterandc>Am I correct in assuming guix.scm files are used to generate a build/dev environment conveniently, and are supposed to be used with `guix environment`? Or is there some other purpose? o.O
<mfg>If you look into such files and see *->manifest i would assume it's a manifest. In the guix repo i don't see anything like it, so i guess it has another purpose
<mfg>But: ig you want a dev environment for guix just use guix environment guix
<peanutbutterandc>Yes, precisely. Which is why I'm a bit confused as to the use of guix.scm file
<peanutbutterandc>Oh... it seems that the Makefiles and friends refer to guix.scm. So, perhaps not really for `guix environment` (?)
<mfg>The comment says it's a composite module that re exports every publicly defined modules, so i guess it's a shortcut of importing all publicly defined guix modules? But i'm not sure i don't know the source that good...
<peanutbutterandc>I see... That comment line: it's all greek to me. Anyways, thank you very much!
<marusich>peanutbutterandc, some guix commands can load files as input. For example, as you know, "guix environment -l foo.scm" will drop you into an enviornment in which the inputs of the package defined in foo.scm are available.
<marusich>This fact is documented in the manual in section "Invoking guix environment": "Create an environment for the package or list of packages that the code within FILE evaluates to."
<marusich>The file can be named anything. By convention, some people choose to use the name "guix.scm".
<marusich>Other commands expect the file to contain different stuff. For example, although "guix environment -l foo.scm" expects foo.scm to be Guile code which evaluates to a package, the command "guix package -m foo.scm" expects foo.scm to evaluate to a manifest, which is not the same as a package.
<marusich>So in general, the name of the file doesn't matter, and the expected contents of the file depend upon what command you are using.
<peanutbutterandc>marusich, I see. I was wondering what the use of guix.scm in the guix repo is....
<marusich>Do you mean the guix.scm that appears in the root of the Git repository? There are 4 guix.scm files in various locations in the repository. The one at the root exists as a convenience, so you can import the (guix) module and get a lot of common modules easily in Guile.
<marusich>For example, if you're in a Guile repl with access to the Guix libraries (e.g., by running "guix repl"), you can just run ",use (guix)" and you'll have access to all the usual things. For example, the %current-system procedure. Normally you would have to know that %current-system is exported by the (guix utils) module, and then you would have to run something like ,use (guix utils) to make it available.
<marusich>Sure thing. Sorry for misinterpreting your question earlier!
<peanutbutterandc>So, the way to figure out what guix.scm files are --- beyond knowing that files containing (manifet are to be -m-ed with `guix environment` and files just listing a package are to be -l-ed --- is to be familiar with guile and stuff, too.
<peanutbutterandc>But in general, guix.scm-s are to be used with guix environment. And are either to be --manifest-ed or --load-ed.
<marusich>0.16.0 release cannot guix pull without substitutes due to failing build: /gnu/store/f98gcg2vl9jga7a97r2rqlz3mzbqhzpl-python-minimal-3.7.0.drv
<marusich>similarly, 1.0.1 release cannot guix pull without substitutes due to failing build: /gnu/store/6hpqhrgrmgh9ra4fh6nv2myh59c9c8mr-python-minimal-3.7.0.drv
<peanutbutterandc>Ah! "cannot pull WITHOUT substitutes". I missed that part. Sorry I misunderstood. I haven't tried pulling without substitutes yet.
<marusich>similarly (but due to a different derivation), 1.1.0 release cannot guix pull without substitutes due to failing build: /gnu/store/ssj7xx3q05l4b84iyzrc90rdw79c90b3-tcc-boot0-0.9.26-6.c004e9a.drv
<marusich>I wonder to what extent the binaries provided by the build farm are carried over incrementally from commit to commit between releases. I wonder if anybody is actually testing whether we can guix pull without substitutes from the release.
<cbaines>I wouldn't quite frame the problem like that, but with Cuirass, it just builds each output once
<cbaines>that's OK for providing substitutes, but not great for doing continuous testing
<cbaines>for testing purposes, you actually want to build each derivation multiple times, across a range of hardware, and check you get consistent results
<rekado>if it’s the same derivation why would it make sense to build it again?
<marusich>Yeah, it feels like maybe some derivations that got built successfully in the past are carried forward even if they become unable to be built in the future.
<rekado>if it’s the same derivation, why would they become impossible to be built later?
<cbaines>Say you've got a single core x86_64-linux machine, and one with 32 cores. If you build the same derivation twice on each machine, you might notice that it fails consistently on one machine, and not the other
<cbaines>I've encountered and fixed/worked around those kind of issues with Guix packages, often when it fails to build with multiple cores, but definately one odd case when it only could be built with multiple cores (the more the better)
<cbaines>although that mentions >= 3.10, and I'm running 5.2.21
<cbaines>but that's something that might cause different behavior
<cbaines>Given you're building on Debian and Fedora, it might be good to pick some other distros and continuously test building all packages on them, to see if there are any weird issues that just crop up on other distros
<marusich>Is that a ppc specific bug though? I'm building on x86_64-linux
<mfg>How do i create and populate a file in a build-phase? i tried (call-with-output-file "file" (lambda (port) (display "text" port))) but the file doesn;t get created. Is there anything special i have to pay attention to?
<cbaines>that's probably what the reports about, the issue looks similar though
<mfg>or is there a guix helper function for such a thing?
<marusich>crossing my fingers that building with 16 cores helps. i doubt it will, but at this point i'll take what i can get!
<marusich>cbaines, what about /gnu/store/ssj7xx3q05l4b84iyzrc90rdw79c90b3-tcc-boot0-0.9.26-6.c004e9a.drv ? do you know anything about that derivation...? it is the one i could not build on debian when guix pulling without substitutes from the binary guix 1.1.0 release
<marusich>it also failed on fedora, as i recall, following the same steps.
<marusich>my goal here, by the way, is just to build enough stuff, without substitutes, to be able to compile guix from source.
<marusich>i already tried running 'guix environment guix' from the releases, and it fails in similarly frustrating ways.
<marusich>hence the reason why i tried to do guix pull
<marusich>i am trying to verify that %gcc-static cross-builds for powerpc64-linux reproducibly with some changes i've made. that's why i'm being particular about not using substitutes.
<marusich>cbaines, rekado python-minimal failed on intel but succeeded on amd cpus.
<marusich>Specifically, /gnu/store/f98gcg2vl9jga7a97r2rqlz3mzbqhzpl-python-minimal-3.7.0.drv (involved in doing 'guix pull' from guix's binary 0.16.0 release) fails to build on an EC2 c5.xlarge, but it succeeds on a c5a.xlarge. The former is intel, the latter is AMD.
<marusich>Guess I'll switch my instance back to intel and hope nothing else funky happens while I finish "guix pull"ing.
<marusich>it's possible i got lucky somehow and it wasn't because the cpu was amd vs. intel, but i suppose i will find out when i try again on fedora.
***terpri_ is now known as terpri
<marusich>anyway, hopefully it'll work. i'm going to sleep because it's super late.
<peanutbutterandc>Okay.... for a package that uses gnu-make-system but a completely different compiler, where do I add the compiler? (native-inputs)? or (inputs)?
<mekeor>hello. i ran `guix package -i glibc-locales`, added `export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"` to my .bash_profile, and i re-logged into bash, and i checked `echo $GUIX_LOCPATH` and `guix package -I`, but when i run `guix pull`, i still get the "guile: warning: failed to install locale. hint: Consider installing the `glibc-utf8-locales` …" warning. why?
<peanutbutterandc>mekeor, It is because the guix-daemon, that runs as root, does not yet have GUIX_LOCPATH set (or glibc-locales installed)
<peanutbutterandc>mekeor, To fix this, log in as root `sudo guix ...` seems to be a bad idea to me: the last time I did that, I ran into trouble. Install glibc-locales. And then export the variable.
<peanutbutterandc>Maybe I didn't write that clearly enough. The "warnings" are from the guix-daemon. Which is running as root. The 'root' user's guix profile does not yet have glibc-locales installed. Neither is the GUIX_LOCPATH set in the environment where guix-daemon is currently running. Hence the warning.
<mfg>so as i see it plain-file is defined in (guix gexp), right? so i need to #:use-module it? i tried it and i still get unbound variable: plain-file errors, is there a restriction on where it can be used?
<mfg>https://dpaste.org/wvwv i noticed though that copy-file isn't the right function there, because it doesn't expect a file-like object but a string. I just want to create the file with static contents, everything i tried didn't work and gave no errors...
<mfg>that's why i'm trying out as much as possible :D
<raghavgururajan>civodul: Can you see the hash on the line shell/disroot.org ? If so, create a block rule with that hash. It is an identd hash. No matter what nick the spammer, if the connection to the gatway is from same xmpp account, the hash will remain same.
<raghavgururajan>Don't include that shell/disroot.org part, else I will also get kicked. 😅
<mfg>so the build system of the package i'm trying to package automatically deletes the just injected file and doesn't recreate it, that's why it seemed like the file doesn't get created ... D'oh
<roptat>so groovy actually needs a fork of antlr4, which depends on itself... I tried to break the loop, but couldn't, so I'll have to use older versions to build the newer versions of that fork
<roptat>I tried using antlr4 to generate a file in the fork's source tree. that worked, but that file won't build without the proper runtime library from the fork it belongs to
<roptat>then I tried to build only a subset of the runtime library that's required to build the fork of antlr4, so I can use it to generate the sources for the full runtime library, but the minimal set of runtime library includes the generated file
<roptat>antlr4 itself contains a runtime library, so I tried to use it, plus an even more minimal subset of the runtime library of the fork, but that failed because the two are actually incompatible, despite being the same version
<roptat>so I'll have to follow the pom.xml files that use older version of the fork, and build ~6 years of historical versions of that fork
<cbaines>that sounds quite awkward! Hopefully there aren't too many versions in that 6 year period
<stikonas>roptat: groovy can be bootstrapped, but it's complicated...
<stikonas>oh, wrong channel :), this is already guix
<guix-vits>roptat: next 1 April "joke": 'Java banned in Guix. Because.'
<Nemin>Heya, I'd like to dual-boot GuixSD with my Arch install, with the Arch managing the bootloader. How can I instruct Guix to not install one? I've tried passing --no-bootloader to guix system, but it's still
<user_oreloznog>Nemin: I don't know if I can help, maybe have a look to my own config, (on line N°40 of the file) where dual boot with Debian and Guix System is configured...
<roptat>and there's a path from antlr2 to antlr3 actually
<nckx>raghavgururajan: If disroot decide to die on the hill of being a freezepeach spam-cannon we'll be forced to ban them. I hope it doesn't come to that.
<apteryx>janneke: thanks. I'm trying to enable xz multi-threading in a reproducible fashion (it seems to be possible, but I need --memlimit=50%, and the current version in the bootstrap binaries doesn't know about '%').
<apteryx>janneke: oh, that's nice, it inherits from the current packages. So if I can just regenerate the bootstrap binaries it should just work.
<nckx>Nice. Weird that an amount that varies across machines makes it reproducible.
<apteryx>it's rather convoluted, but the trick is to have the xz code stay into the 'multi-thread' code path
<apteryx>so you enforce at least --threads=2 (not 1), but need a way to scale down its thread counts from N (parralel-jobs) to 2 because it can use a lot of memory.
<apteryx>that's where --memlimit=50% comes into play
<janneke>apteryx: oh my -- looking at your paste -- that's unexpected!?
<apteryx>janneke: I can workaround xz-bootstrap erroring when receiving the '--memlimit=50%' argument (which I presume is because it a bit dated, as the current xz doesn't suffer from that).
<janneke>the bootstrap binaries are actually used to created patched sources -- yuck!
<janneke>iwbn to change that, if it's at all possible
<apteryx>but if I don't need workarounds (as in, simply bump the xz-boostrap version), that's even nicer in my opinion.
<apteryx>about boostrap binaries being used to create patched sources; isn't that inevitable?
<janneke>i don't know -- i realise that i haven't looked at that at all...
<marusich>rekado, cbaines it occurs to me that to avoid using substitutes when building stuff using my custom guix, i can just configure guix to use a different store path. then i can use substitutes all i want in order to build the custom guix, without worrying about my custom guix re-using those substitutes later. i feel silly for not thinking of that sooner... but it was an interesting adventure in seeing how the same derivation can succeed in one
<apteryx>janneke: is it possible to partially regenerate the bootstrap tarballs (such as just refreshing the %bootstrap-binaries-tarball, which includes xz). I guess that's too dirty, in the sense that you now need two guix commits to regenerate the same tarballs collection.
<mfg>what kind of characters do i need to escape in a substitute* statement? do i need to escape $?
<marusich>I see. The thing about the bootstrap binaries is that they are rarely updated; it's kind of a security feature to avoid updating them, so that nobody can sneak in something hidden in the root binaries of our bootstrap tree.
<apteryx>mfg: substitutes use the ERE regexp flavor, as described in the sed info manual
<marusich>So even if you could make it faster, I am not sure we would want to replace the ones we have?
<ryanprior>I'm packaging a bunch of Go deps building towards Hugo. Gonna be a long road. Right now I'm stuck on an error in the "unpack" stage where it says "In procedure copy-file: Permission denied"
<ryanprior>Anybody dealt with similar before where Guix couldn't unpack?
<marusich>ryanprior, without more context, the first thing I would suggest is to figure out why permission is denied. e.g., find out what command it's running which returns that error, check for more verbose errors, run with "guix build --keep-failed" and try to manually reproduce the error, and if necessary strace the failing process to see what it's doing at the syscall level.
<apteryx>marusich: makes sense (to touch them only rarely, and have a couple people verify them well).
<marusich>However, a likely cause is that something in the build logic is trying to modify a file in the store, which is immutable.
<apteryx>I guess my case is not strong enough to warrant touching them, so I'll implement a workaround.
<ryanprior>I'm working on pushing this work out into my repo so I can provide some more context :) thanks for your thoughts marusich
<marusich>apteryx, yeah, but i am not sure how extensively they have been "verified" beyond when they were initially added. I looked into this a little bit, and I could not find evidence in the email list archive that, for example, any of the prior binaries were actually reproduced bit-for-bit, without using substitutes, on separate machines/OSes. But people did on occasion verify that they could produce the same bits (perhaps using substitutes -
<marusich>sometimes that wasn't clear in the emails)
<apteryx>marusich: If I recall mhw looked into reproducing them carefully
<marusich>I am currently working on this bug to try to make the powerpc64-linux bootstrap binaries bit-for-bit reproducible, and it's really time consuming. I am honestly not sure if it is better than just accepting the set of binaries we build 2 months ago, and just using them.
<marusich>Personally, I would be pleasantly surprised if I found out that any of the existing bootstrap binaries were actually verified by building two times from source with no substitutes on two different machines.
<marusich>I know that some of them were verified by building two times on two different machines because some emails said as much. However, the emails I saw didn't clarify whether substitutes were used.
<efraim>xelxebar: just getting back to my computer after off for a few days, last I saw I was way too many hours into qemu-minimal's test suite and now I can't connect to the board. I'll probably adjust qemu to skip the test suite on the board if it's not done
<ryanprior>Here's the package I'm working on, aws-sdk-go. Its dependencies all build, but when I try to build this package it fails in the "unpack" step with "In procedure copy-file: Permission denied"
<efraim>ah, yeah, the "can we just delete it and pretend it isn't there" idea
<marusich>Turns out, if you re-use the exact same inputs (e.g., by manually copying them allll over onto the other machine), then simply adding the --disable-libstdcxx configure option to %gcc-static's package definition succcessfully eliminates the non-reproducibility. Now I'm testing whether it remains reproducible on debian vs. fedora if i build everything from source, including all inputs.
<marusich>I don't know if libstdcxx is required to build the next thing(s) in the bootstrap path on powerpc64-linux, but i'm all about easy fixes, so if this works that would be nice.
<ryanprior>It says those are "regular files" with uid and gid of 0
<marusich>When you're in the failed build directory, /tmp/whatever, you can source the environment-variables file via ". environment-variables" and then manually walk through the steps taken to build the package. to know what steps are taken, you either have to see what it says it did in the build log, or read the package definition.
<ryanprior>It would be nice to let people know when I'm making progress on a package people are wishing for
<luis-felipe>Hi, I found a segfault in Glade 3.36.0 and reported it to the Glade project. They are asking me for a stack trace, they provide some instructions, but I'm not sure how to map them to the Guix System.
<rekado>ryanprior: we don’t but I suppose you could just comment right there on the wishlist
<rekado>mfg: now inside that lambda you can use the variable inputs, map over it, etc
<ryanprior>rekado: that may be true, but I don't know of any other similarly public-accessible way to request a package. Editing a wiki is already a fairly high bar, using the guix-devel mailing list even moreso.
<mfg>rekado: hm ok, i did something else wrong then...
<ryanprior>rekado: sending an email to a list feels like shouting into a void. I think people are less hesitant to open an issue on a wiki or a git-forge like GitLab because they can see other people doing the same and getting responses
<rekado>I wonder if thihs means that we need more visible and more attractive archives.
<pineapples>rekado: I should've elaborated a little more: I'm hesitant to open an issue by sending an email to a list because I feel uncomfortable revealing my personal email address, and dislike the idea of having to set another email address up. All it'd take to convince me to contribute to the project would be an ability to hide it from other participants
<rekado>pineapples: with issues.guix.gnu.org you can already comment on an existing issue without having an email address. (You won’t receive notification on updates, though, because the system would need to know your email address.)
<rekado>pineapples: we don’t have this yet for submitting new issues.
<pineapples>rekado: The last time I tried to send a comment through the web interface, it didn't go through for some reason. Submitting new issues via issues.guix.gnu.org would be a huge deal-maker to me if you ask me
<mbakke>NieDzejkob: can you submit the patch and mention the failing use case? maybe other hackers already know what the problem is.
<luis-felipe>pineapples: That has happened to me before. I sent a message, and it seems it never goes through.
<mroh>If I have a pkg that has source of libs like zip or lz4 or lua in a folder of the tarball/checkout, but I ./configure --usesystemlua=true it to use our library/input, do I still have to mention the license of that library in the license field of the pkg?
<peanutbutterandc>mroh, I would think not. As the license of that library will already be in the package definition of that library that is already in the gnu system.
<luis-felipe>peanutbutterandc: geiser should be able to give you information about things defined in the haunt library too.