IRC channel logs
2024-02-15.log
back to list of logs
<Guest9769>hi guix people, could someone explain the logic that cuirass follows to build packages? i specified a period in my specification, which is correctly followed by cuirass, but the packages I listed in the build field have been only built once for the first guix derivation that was pulled by cuirass. I now have a list of guix revisions pulled in the cuirass specification page. my expectation would be that cuirass would rebuild packages <dissoc>i use slim and i need to create file /etc/X11/xorg.conf.d/50-tablet.conf that is Input Class section. How do I do this? I see i can pass xorg-configuration to slim service but how do I add that to the xorg-configuration? <graywolf>Given a rust crate, how should I propagate build time dependencies? I have a crate rust-foo and a app bar. Bar depends on rust-foo. During compilation of bar, some program (protoc) needs to be available. <graywolf>How can I express that? Any package I could use as an inspiration? <mange>dissoc: You can use extra-config in xorg-configuration to add arbitrary configuration to the xorg configuration file. <graywolf>My understanding: (native-inputs) of rust-foo will not be visible during build fo app. (inputs) will be, but they will be also be installed with app (which is not required). <graywolf>I could use (native-inputs) of app, but every user of the crate would need to do that, which seems suboptimal. <mange>Patch the cargo build system to also include native inputs of cargo-inputs? <graywolf>That seems like something that could work, but also completely outside of my ability to implement :) <mange>It doesn't look too tricky, looking at guix/build-system/cargo.scm. I don't know of another solution to your problem, sorry. <graywolf>Alright, thanks for the suggestion, I will give it a shot tomorrow <dissoc>mange: thanks. i will give that a try <dissoc>is guix able to handle patches for packages that are stored in remote channels? <dissoc>like if the patches are stored in a directory in that remote channel but then it is later built locally <mange>I don't understand your question. Do you mean, can you define a package in a channel that applies a patch to the fetched source before building? <dissoc>say i have channel X in it's repo. in that repo there are packages and patches. but then i build that package locally. is it able to reference that patch for that package in the channel to build? in the past i had a problem with that but that was when i was fairly new to guix <mange>Yes, you can do that, but the usual "search-patches" macro/function only searches %patch-path, which probably won't find your patches, so you can't just copy+paste from existing packages. Using relative paths from the root of the channel directory should work, though. <dissoc>ah. i can handle that. i think i wasn't using path from the root. thanks! <Gooberpatrol66>Is installing guix using cow-store on a drive that already has data on it safe? none of the files are system files, they're backups in a backups dir <oriansj>just skip the formatting of the disks <oriansj>just don't expect to preserve anything in /gnu/ <apteryx>is it possible to use 'guix repl' in a guile script shebang[/ <apteryx>so that it runs it within an environment where the guix modules can be used? <sham1>Has anyone here tried to run maven recently? Because I'm getting an error where Maven cannot even launch because it apparently can't find a class from cglib (ReflectUtils to be exact) while it's clearly in there <futurile>darn what's the bot called that can give someone a message when they come to channel later? <futurile>sneek: tell dissoc there's a recent email on guix-devel about creating a channel with patches in it (and package derivatives) <sneek>dissoc, futurile says: there's a recent email on guix-devel about creating a channel with patches in it (and package derivatives) <jpoiret>futurile: you need to say "later tell", otherwise it instantly tells it <civodul>wasn’t someone looking into fixing the hamburger menu of Cuirass recently? <jpoiret>civodul: small question: I forgot to add libcrypt to Guile's inputs, and now the `guix` package won't build because some tests rely on (crypt ...). Am I doomed to rebuild the world? <jpoiret>I don't really understand where the dependency of everything on guile-3.0.9 comes in <mfg>so when booting, it never gets past the populating etc stage, so i guess this might have something to do with the warning i pasted <mfg>now i can at least roll-back to older generations but trying to reconfigure and build a new one always leads to this warning <civodul>jpoiret: use of (crypt …) in OS configs is documented too, so i think we need to have a Guile build that provides ‘crypt’ <civodul>i’m afraid this is bad news for you :-) <dkxr>greetings, how do i build sdl source files/ what is the command to build with source files included? <dkxr>its guix build *something* *something*? <jpoiret>dkxr: wdym "with source files included"? <dkxr>i mean for instance i can build gcc with the c files, while guix comes only with the header files of gcc <dkxr>i just want to get the source files of programs like gimp <dkxr>but i guess sdl is just header files? <dkxr>since its a graphics api <jpoiret>if you want the source of a package you can do `guix build -S PACKAGE` <jpoiret>mfg: the fact that unspecified appears like this might mean there is an error in your configuration <futurile>is there a way to delete all referrers of something in the store: I tried guix gc --delete $(guix gc --referrer xxx) - but I must be doing something wrong (my bash foo is weak) <futurile>formbi: judging that it's from May 2023 I would say 'no - no-one has looked at it'. <futurile>formbi: doesn't look like any comments on it - so presumably no-one replied - maybe on the dev mailing list <futurile>formbi: you could try bumping it - do a v2 of the patch - check they apply cleanly etc <formbi>because upgrading stuff is still impossible thanks to glib <futurile>formbi: well guess you can help it along maybe, but after a year little chance unless someone nurtures the patch <formbi>I guess I could try, but I'm afraid I'm too stupid for that <sham1>I wonder how much hubris it would take to contribute a maven importer, because doing Java stuff is just ridiculous <sham1>Would be quite useful to have, tho <formbi>importing stuff from most of the fashionable languages is horrible <mfg>jpoiret: thanks, i will have a look at it <cow_2001>where's the "guile" package definition? i see many guile-* package definitions, but not just guile <sham1>cow_2001: gnu/packages/guile.scm:326:2 <sham1>Well that one has the define-public fairly close, so I'd say that counts <cow_2001>i mean, the name is defined in (name "guile"), not in (define-public guile-3.0 ...) <futurile>anyone having problems with qa.guix.gnu.org? I'm getting a bad gateway message <parnikkapore>Hi Guix! I noticed that all Cuirass evaluations (as in `cuirass evaluate`) are stuck using one CPU core, even when multiple evaluations are going on in parallel. Is this intended? <parnikkapore>^ Ooh, I got something else on the home page: misc-error #fvector->list: expected vector, got ~S#f#f (sic) <Hamilton>Can guix be used on debian as a parallel package manager or setup tool for dev environment ? <Hamilton>I mean in the sense the same way nix can with nix or direnv <ieure>Hamilton, Yes, there's an official package, `sudo apt -y install guix'. <ieure>Sorry, I don't know what you're asking. <Hamilton>I mean suppose we're developing a package that depends on X and Y. But X and Y are not installed globally. In Nix, people declare dependencies at the project level in some file and some mechanism ensures that when we switch into that dir, X and Y will be accessible for dev tools like make and the like <ieure>I think there's something for that, I don't know what it is. guix.scm in the directory and some shell hooks, something like that. <parnikkapore>per-project development environments are done using `guix shell`; it does what you describe above, except for the "switch environments upon cd" part <parnikkapore>...actually that second page is a touch complicated. for repos that support it, you only need to run `guix shell` upon cd-ing in. <parnikkapore>or `guix shell -m manifest.scm` / `guix shell -f guix.scm` to skip the Guix-side safety confirmatino <rekado>Hamilton: additionally, you could also use “eval $(guix package --search-paths -p $PWD/.guix-profile)” if you’re using persistent profiles per project directory. <rekado>personally, I don’t bother with direnv and just use “guix shell” (no arguments) when I want to activate a development environment. It works with guix.scm and manifest.scm <Hamilton>There is no flake-like schism since everything is in Guile, right? <Hamilton>In Nix, you can do declaration of project-specific deps with either shell.nix or flake <parnikkapore>if you're talking about the switchover controversy though... I'm honestly not sure how using Guile would lead to something like that being less likely? <jpoiret>PotentialUser-70: can you do `zless /var/log/guix/drvs/x4/BLABLALBA`? where you replace the last part with the path that's written on the error message? <parnikkapore>In the meantime, you could use Guix as a package manager on another distro (should allow you to avoid this dependency for a while at least) <snape>I wonder if 'guix pull' would work here <jpoiret>PotentialUser-70: could you retry the same command that failed before? <jpoiret>`guix pull` would maybe help, but this is quite fishy <jpoiret>maybe the package's tests are flaky, and the first time around they worked on CI and everyone got the substitutes <snape>I'd try `guix pull`, PotentialUser-70 <jpoiret>it's been upgraded on master in the meantime, maybe that's fixed <snape>and then `guix system init...` again <parnikkapore>yeah; an alternate is to leave off the "--substitute-urls" and see if we can grab it from berlin for now <snape>python-afdko is definitely building fine on master <jpoiret>have you tried building it multiple times? <jpoiret>I noticed yesterday that python-trio sometimes fails <jpoiret>flaky tests can sometimes trigger only once per 10s of tries <snape>parnikkapore: OP is not on master <snape>jpoiret: substitutes are available for python-afdko on master anyway <jpoiret>huh, looking at the error message for the test, False = differ(str1, str2) but those strings are clearly different 🤔 <jpoiret>well actually i don't know what differ does but it's definitely not comparing two strings <tachymelia>does the guix-devel mailing list require manual approval or smth? sent an email last night & wanna make sure I didn't like, fumble sending it or smth <jpoiret>it will be manually moderated at some point <sham1>Probably a good thing to prevent spam, tho <jpoiret>sham1: I don't think moderation on bug-guix/guix-patches is specific to debbugs, but rather to guix mailing lists. could be wrong though <parnikkapore>PotentialUser: yeah, `guix pull`, `hash guix`, then try the `guix system init ...` again <sham1>I meant more that it's a similar procedure of making sure that the poster isn't a ne'er-do-well <snape>yeah it's manual moderation first time only <snape>i talked to the people doing the moderation a few times btw, they are very nice <snape>I imagine debbugs moderation is just the guix-patches@gnu.org one <parnikkapore>anw, I noticed that all Cuirass evaluations (as in `cuirass evaluate`) are stuck using one CPU core, even when multiple evaluations are going on in parallel. Is this intended? <Guest14>How can I make the vm from "guix system vm" be the exact same Guix version as my host? <lilyp>Unless you really want to use time-machine, just don't use `guix pull' in-between reconfigure and vm? <Guest14>I don't understand. Basically I want that "guix --version" reports the same commit in the vm as of my host since I need to debug why Emacs comp is giving me "Warning (comp): x86_64-unknown-linux-gnu-gcc-10.5.0: fatal error: cannot execute ‘as’: execvp: No such file or directory" since I upgraded the system <ieure>Guest14, Yep, not loading for me. <Guest14>This happens quite often. Someone knows why that is the case? <ieure>Guest14, Because Guix is a volunteer run project with a userbase which has outgrown its infrastructure. <Guest14>That is obvious, I mean why Mumi has problems. I guess something is broken if Nginx generates 502 all the time. Maybe it is even Nginx itself (config or something) <ieure>nginx 50x errors are almost always caused by the upstream service it's reverse proxying being broken. <ieure>Anyway, I don't really know what the deal is, other than some major component of Guix infrastructure seems to be completely broken nearly every day. <PotentialUser-70>guix init was giving me an error wich I solved with --force but the init crushes on the grub-install without --force and the installation stops, so can I just reboot if I installed grub manualy? <Guest71>guix init was giving me an error wich I solved with --force but the init crushes on the grub-install without --force and the installation stops, so can I just reboot if I installed grub manualy? <rekado>Guest71: I suggest you confirm that there is in fact a grub entry for the newly installed system <Guest71>error: will not proceed with blocklists <rekado>ieure: there really is no problem with the infrastructure, but with the number of people volunteering to operate it. <ieure>rekado, If it breaks constantly without manual attention, it's broken. <ieure>I'm not pointing fingers or assigning blame; just observing that something major breaks all the time. <Guest71>that error was from grub-install --target=i386-pc --boot-directory /mnt/boot /dev/sda, I ran it manualy with --force and worked out, what do I do now? <rekado>Guest71: as I suggested: do check that there’s a grub entry for your newly installed system. <ieure>I have neither knowledge nor preference to the solution taken (whether that's fix what's there, replace it, whatever). But clearly *some* plan of action is needed. <rekado>someone keeps spamming the graphql endpoint with page long URLs <Guest71>the awk -F\' '/menuentry / {print $2}' /boot/grub/grub.cfg shows nothing <Guest71>the command outputs nothing, but just cating the /mnt/boot/grub/grub.cfg there is a menuentry "GNU with Linux-Libre" <rekado>Guest71: if there is more output than just “error: will not proceed with blocklists” we’d be happy to receive a bug report via email to bug-guix@gnu.org. <rekado>but at this point I think you could try to reboot and see what happens. <Guest71>there were 2 warnings before the error <Guest71>Im waiting for init to ran again to see what they were exactly <janneke>does guix system build/image lack --without-tests=PACKAGE? <Guest71>this GPT partition label contains no BIOS Boot Partition embeding wont be possible <Guest71>embeding is not possible GRUB can only be installed in this setup by using blocklists. However blocklists are UNRELIABLE and their use is discouraged <lispmacs[work]>if I'm defining an image, should the operating-system section look like (operating system (host-name ...etc....)) or (operating-system (operating-system (host-name ...etc...))) <ieure>lispmacs[work], The latter; or you can (define %my-os (operating-system (host-name ...))) and then (image (operating-system %my-os)). <ieure>The outer operating-system is a field name in the image structure; the inner is the operating-system structure you're assigning as the value of that field. <lispmacs[work]>when operating systems definition does something like (boatloader-configuration (keyboard-layout keyboard-layout)) is keyboard-layout a defined variable in some guix module, or is it a reference to the keyboard-layout definied earlier in the OS definition? <ieure>lispmacs[work], It's a reference to the system keyboard-layout. I'm not sure how it works, exactly, but there has to be some magic to it. <lispmacs[work]>I'm just wondering about it because if I wanted to separate out code like the bootloader configuration and the services, into their own variables, then these definitions would be referencing a keyboard-layout out of their scope <lispmacs[work]>I suppose I could just make the keyboard layout its own variable tooo <lilyp>lispmacs: there's some syntactic sugar that makes it so that record fields can be referred to by name <lilyp>so if you've specified (keyboard-layout %my-layout) early on, you can refer to it as keyboard-layout later <rekado>janneke: “guix deploy” is also missing transformations, but when I think about it I don’t know if they would make sense at all, given that one can deploy to many different systems at the same time. <janneke>rekado: hmm, but how does that translate to guix system? now i had to edit the source which is slightly more inconvenient <rekado>for “guix system” I do think we should support transformations. <dthompson>guix deploy should be strictly configuration as code imo <lispmacs[work]>Hi, I wanted to make a 128GB raw image using guix image, which I could just copy over byte for byte to disk. My plan was to build the image onto an external drive I have, since my computer hard disk does not have enough space for that. But it seems that guix image does not have a way to output the image to somewhere outside of the store. <lispmacs[work]>I see there is a "tarball" format. Is that just the raw image compressed, or the individual partitions, or...? <lispmacs[work]>It looks like there is a way to copy qcow to a real disk, so maybe that is the way to go <lispmacs[work]>I guess there is a question here also of whether intermediate files are going to exhaust local disk space <ieure>lispmacs[work], I'd assume the tarball format is just the files that would end up on disk, and you need to label/partition/format the disk, mount everything, and extract it onto that. The Guix docs probably say what the format is, though. <ieure>lispmacs[work], Generally, for this kind of thing, you want to make a small image and resize filesystems on first boot. I believe there was some discussion around a system service that would do that, either here and/or on guix-devel. I don't think anything is availble in Guix master at this time to do that. <ieure>You have to resize partition(s), then resize the filesystems on them, is my understanding. I don't know what all the mechanics are. Basically every raspberry pi SD card image works like this, though. <ieure>Because nobody wants to stick 128gb of zeros on their disk, and you probably don't want to make a bunch of images for different target disk sizes. <lispmacs[work]>that makes sense. I'm a little fuzzy on what adjusting the (GPT?) partition will look like, but seems like there is information on the Internet <ieure>Probably gparted can do that. <PotentialUser-37>Hi all. Trying to get a recent guix ISO, but trying the download on guix.gnu.org gives " <cow_2001>will later also patch the latest version of guile's guix installation script and call it guile-for-guile-cv <PotentialUser-37>Can someone else confirm so I can be sure it's not a network thing on my end? <PotentialUser-37>wait, maybe its specific to the build daemon, in which case guix expression would be more appropriate <daviid>cow_2001: nice work, thanks - can't help 'here', but 'quietly' looking and forward to see a proper guile for those working with large to very (very very) large data structures ... this is definitely missing - no one wants to see a(ny) raised exception printer(s) displaying as part of 'its error message' 20M 32bit floats ... <PotentialUser-37>alright, figured out how to generate an install image. But it is still weird that I can't download one from the website <rekado>PotentialUser-37: yeah, there’s a problem with cuirass, the platform powering ci.guix.gnu.org. 
