IRC channel logs
2023-08-29.log
back to list of logs
<vagrantc>did guix lint always cache CVE data? ... seems much faster than it used to after the first run <vagrantc>acrow: so i have patches that are enough different that seems like i should submit them as a ... v5 series? <vagrantc>acrow: mostly just whitespace changes from applying guix style ... and using a few string-append calls to break up long lines <vagrantc>acrow: and dropping some rearranging of the use-modules stuff ... which makes the diffs much simpler (if less orderly ... but i think orderliness should be it's own patch if that is really desired) <vagrantc>acrow: that said ... given this patch series is getting to be over 7 months old ... maybe i will just go for it. :) <acrow>vagrantc: Sounds great either way. <acrow>vagrantc: Sorry I was AFK for a few hours. <vagrantc>acrow: you've waited over half a year (and then some, if i recall) ... so ... :) <acrow>vagrantc: Don't know what to think of that. It has repeatedly passed QA (although now it says it is unknown) I'm not sure what would cause jericho-html to fail on i686 that works on other architectures. Hmmm..... <vagrantc>looks like some failure somewhere higher up on the toolchain ... seems to be rebuilding rust ... <vagrantc>although the build log is so long ... i have not yet loaded it <acrow>vagrantc: you know how I feel about rust...... <martin1>Are the package lists different between guix on a foreign distribution and guix system? On guix system, I have dino 0.4.2 installed, but on my ubuntu machine, I just installed guix, ran "guix pull" and "guix upgrade", but the newest version of dino is 0.3 <charlotte1123581>hi, anyone can recommend a sane default .scm file to start with? i just downloaded the .qcow2 and i cannot find the .scm file defining this particular image <charlotte1123581>i swear it didnt show up from find | grep but maybe i missed it. anyone else switched from nixos and willing to share some conclusions? <charlotte1123581>scheme is a joy for one, but the bootstrapping news is what pushed me to take the plunge. <charlotte1123581>which i would also like to replicate but i do not know how - is the process hex0 -> mes -> tcc -> gcc -> ... -> guix documented in detail somewhere? <podiki>martin1: no, there is but one package definition; maybe your shell is not using the updated guix, the manual should have instructions on what needs sourcing etc. <martin1>I already did a "guix pull" and "guix upgrade" <podiki>guix refresh is used to see if the package definition can be updated <podiki>if you installed something, say guix install foo; then after a guix pull if you want to update you can do guix package --upgrade <podiki>guix pull just updates guix itself/package definitions, it doesn't update anything you installed <ulfvonbe`>is there a particular reason we don't have tensorflow 2? <ulfvonbe`>I see we have tensorflow lite >= 2, but that doesn't provide a python interface <ulfvonbe`>written in java... tell me the bootstrapping story isn't as awful as gradle... <apteryx>I have a package for it, but it bundles a bunch of .jars <apteryx>I should send it out for someone else to finish <apteryx>I started looking at our Java packaging, which is not awesome <slartibartfast>"guix pull: error: cloning builder process: Operation not permitted" ... I'm root but in a container with certain resource limits imposed, I don't suppose there's any feasible workaround without getting restrictions relaxed...? <apteryx>maybe running the daemon with --no-chroot? <apteryx>anyone getting "help2man: can't get `--help' info from guix home" at build time? <apteryx>I think I got it to pass happily after working from a 'guix shell --pure -D guix' environment (adding --pure) <avp>Hello Guixers! Yesterday I've sent two an email to help-guix@gnu.org, one with attachment and one without (I removed the attachment thinking that could be the core of the problem), but it seems that none of the emails reached the mailing list for some reason. The emails title was "LaTeX: Need help with packaging a book in GNU Guix". What I'm dong wrong? <itd>first time posting to that list? (maybe some moderation.) <avp>itd: Yes, I registered there a day ago. <avp>Okay, maybe it's reasonable to wait more. Although a little notice email from the mailing list saying that my email is at least received and queued for moderation would be nice indeed. <drewjose>hi, I was looking at the nixpkgs package for babashka, and they use graalVM to build a native binary from a jar. I've never packaged anything for guix before, but would you have to add graalVM as an input and use that in a g-expression? <nckx>avp: I dropped the one without attachment. There's a limit, but it's rather generous and ~400k wouldn't hit it. <Pugwash>Is the Guix help mailing list moderated? <nckx>sneek: later tell Pugwash: 'Tis. <bobbma>Hi! Can i add a file to package without changing package definition? I want to replace style.css file in cgit package. <nckx>mrvdb: Thanks. It's not even giving a 502 here. <jpoiret>bobbma: not to a package, but there probably is a field for the service configuration for that, no? <nckx>bobbma: You can write a new package that inherits from cgit and adds a phase, or (if cgit were expensive to build, probably not) something that takes cgit as inputs and copies the output, replacing that file. <nckx>mrvdb: Restarted šāāļø <bobbma>jpoiret: there is an option to do that, but it isn't working correctly. <bobbma>It creates a file with styles to /gnu/store, but cgit frontend cant pull this file, there is a 404 error. <nckx>bobbma: Could you report that to bug-guix at gnu dot org? <nckx>Promise you won't be moderated for a week. <bobbma>No sorry, it seems to be working now lol. <andreas-e>rekado: When looking at whether we could get rid of hdf5@1.8, I come across pigx and related packages that still depend on it. Could you maybe have a look whether these could be updated to the most recent hdf5@1.14? <andreas-e>cbaines: On the bordeaux activity page, there are "build setup failures". What does it mean, and how can it be solved? The same R packages appear again and again on bayfront and harbourfront for at least an hour or two already. <cbaines>andreas-e, so there are several types of setup failure, looking at the logs on harbourfront, it seems like this is due to missing inputs <cbaines>2023-08-29 12:52:44 (DEBUG): ccccf7ea-0558-4635-9967-07d964681541: missing inputs: (/gnu/store/7wqws4fpj7dqxyarapy2laxibkp5p4z5-r-org-mm-eg-db-3.7.0) <cbaines>2023-08-29 12:52:44 (INFO ): ccccf7ea-0558-4635-9967-07d964681541: setup failure: missing_inputs <cbaines>the build coordinator segfaulted this morning, and I wonder if that disrupted handling some outputs <andreas-e>Okay. So apparently something went wrong in the scheduling, or the inputs were gc-ed? <cbaines>the coordinator thinks the outputs should be available, but they're not <cbaines>I can see there's no backlog in handling builds succeeding, so I presume something went wrong when handling the nar for this output <cbaines>I'm still not quite sure what's gone wrong, I'm just looking through the coordinator logs on bayfront for lines relating to build fd284e8f-734f-4433-ac64-8d3ff494cc9b <cbaines>hmm, I think there might be a concurrency issue in the coordinator. I think multiple threads are trying to process the same hooks at once <ngz>cbaines: I'll soon have around TeX Live 1300 packages to push in order to complete modular TeX Live. Those are very quick to build (a couple of seconds each on my under-powered laptop). Is it fine to push them in one go to master, or should I still split them into slices of around 300 packages and wait a few hours between pushes? <cbaines>ngz, it would be good to move to more/all changes going through QA, that way substitutes are available when changes hit master <cbaines>there aren't any branches in the queue to be merged at the moment, so you could just push all the changes to a branch, open a merge request, wait for QA to build them, and then push <ngz>Building these packages is roughly as fast as downloading substitutes for them. <cbaines>there's also no specific guidance on not pushing large numbers of new packages, so just pushing them all to master is an option <ngz>Not that I'm against creating a branch. I wonder know what would be the more efficient way to proceed. <aldum>I'm trying to start ssh-daemon to ease installation, but the shepherd socket refuses to connect, what am I doing wrong? <next4th>aldum: does 'herd' report that error in the live installation media? <next4th>aldum: seems something wrong in shepherd, maybe reboot? <graywolf>Any ideas if it's possible to get guix output less "jumpy" when running under eshell? The commands work fine, but the buffer tends to jump up and down a lot. <cbaines>andreas-e, I'm still not sure what went wrong with some of these builds, but I'm going to add some more logging to the coordinator <cbaines>I'll also manually restart the build success hooks for builds that are in an odd state <andreas-e>ngz, cbaines: I think it is fine to push the texlive packages. Essentially they "build" by copying a few data files to their output, right? <jpoiret>nikolar: i think nckx reverted the problematic commit <jpoiret>i'm still trying to figure out how that happened though <charlotte1123581>hi, anyone got a way to jump to definition from config.scm? i wanna understand wtf i am even doing lol. something akin to dumb-jump <ngz>andreas-e: Indeed. The final packages, which do not include those defining TeX formats, merely extract they "runfiles" from an ".ins" (or ".dtx" sometimes) file, and copy everything to the package outputs. <charlotte1123581>also, i like using plan9 mk more than make, how does one define new build-system? <jpoiret>charlotte1123581: with Geiser in emacs it should be possible using M-., you need to start a repl first though with C-c C-a <jpoiret>for how to define a new build-system, I'd suggest having a look at the existing build systems source, I don't believe there's documentation on that <jpoiret>although you can use trivial-build-system and write out the whole process in the phases <charlotte1123581>nice thanks. wtf is a g-expr is this guile specific? how does this relate to various normie quoting i am used to <jpoiret>it's Guix-specific rather. It's a fancier s-exp that also includes info about eg. what other modules need to be available for it to run, since the use-case is staging code to be run under the build process that's isolated. <charlotte1123581>so it behaves like quasiquote/unquote/splice but guix keeps some dependency metadata in the background? <jpoiret>yes! although that dependency metadata has to be added manually, but you usually don't need it too much <jpoiret>other important difference is how unquote works: objects have to be lowered to be inserted in a g-exp, usually that transforms them into store paths <jpoiret>for example you can #$some-package and it'll lower that to the path to the built package in the store <jpoiret>same for things like #$(local-file ...) #$(origin ...) #$(computed-file ...) etc. Those are objects that have a corresponding G-Exp compiler (most are defined in guix/gexp.scm) <jpoiret>basically it means "give my this fancy object's path" <jpoiret>that's not really beta-reducing though, esp. in a lisp <jpoiret>lowering an object converts a high level thing into a low-level one <jpoiret>low-level is almost always a derivation. But in guix you don't manually create derivation objects for all packages, we have the higher-level (package ...) abstraction for that. That package can then be lowered to a derivation. <charlotte1123581>hmm what is derivation? i see Derive(...), this doesnt look like scheme. what is a .drv file really? <charlotte1123581>so .drv is like instructions for guix daemon how to reproducibly build a package? <gabber>is a pretty good summary of the topic by unmatched-paren <charlotte1123581>guess i'll just start by reading all blog posts instead of pestering you guys lmao. <aldum>next4th: rebooted twice, now it seems to be ok, thanks <apteryx>seems we've got some: substitute: [Kupdating substitutes from 'https://ci.guix.gnu.org'... 0.0%guix substitute: warning: ci.guix.gnu.org: connection failed: Connection timed out on berlin <apteryx>we also still have knotd (DNS) problems on berlin: [knotd] 2023-08-29T14:59:20+0200 error: [guix.gnu.org.] zone event 'refresh' failed (no usable master) <andreas-e>apteryx: I can ping bayfront from berlin. Maybe we need to restart a service related to knotd on bayfront? <graywolf>Hm, any ideas how can a shepherd service report errors/warning in user-visible fashion? <gabber>graywolf: you mean other than, let's say, a line of text in /var/log/messages? <apteryx>andreas-e: I'm still blissfully ignorant w.r.t. knotd / DNS zones administration <ngz>Oooh. My local "tex.scm" is 102k locs. Take that "crates-io.scm"! <ngz>cbaines: I resurrected the "tex-team" branch, which is ready to be processed by QA. I'll write a proper bug report for that in a second. <ngz>100% TeX Live coverage! \o/ <cbaines>ngz, woo, hopefully it won't take too long for the builds to start <ngz>cbaines: Unfortunately, master, upon which "tex-team" is based, is not green-ticked. I hope this will not have horrible consequences. <graywolf>gabber: yeah, I was considering just writing to the tty, but it seems guix just scroll everything away before displaying the login prompt :/ <rekado>cuirass has a lot of neat things that I think would be good to see merged into fibers and squee <apteryx>rekado: did you mean that for #guile? <rekado>the āfiberizedā web server that doesnāt run ārun-fibersā itself and the database connection pool come to mind <rekado>well, Cuirass is a Guix project, so I might as well ask here :) <apteryx>ok, I thought it may have been a mistake because fibers were just mentioned in #guile <rekado>I feel the same about Guix records <rekado>having all of the tricky stuff only in Guix (rather than the upstream packages) makes it harder to use these packages <andreas-e>cbaines: There are a few suspicious "old" packages being built on QA, kio from elogin-updates on bayfront and rustc from rust-team of harbourfront. But maybe these are just the same in master. Are the ARM machines building? "No allocated builds" sounds suspicious. <andreas-e>cbaines: The suspicious builds are gone now. <cbaines>ngz, it's not processed yet, but the data service has started processing it, so that shouldn't cause a problem with tex-team <cbaines>andreas-e, you can see the "Plan size" on the activity page, and for the ARM machines it's quite low (the max is 256) <cbaines>I think there's just not many waiting builds for ARM at the moment. There were some QA bugs getting in the way that I've just fixed though, so maybe there will be some builds shortly. <cbaines>andreas-e, the build coordinator plans what builds should be allocated to each agent, so the plan size is the ordered list of builds to be allocated to that agent next <andreas-e>Okay. So when it is smaller, things are more agile. <cbaines>the plan is recomputed very frequently, but yes, it's done this way mostly to ensure that handing out builds to agents is very quick and not dependent on whatever process you use to work out what should be built next <andreas-e>Hm, no, I misunderstood. It is usually 256, but if there are not enough packages, there are less. Like the 9 now for ARM. It is just suspicious that ARM should be finished and x86 still busy! <andreas-e>While there are also plenty of patches to be processed. <cbaines>with x86 there's all the cross builds to do as well <andreas-e>These are good news, the build farm has caught up. <apteryx>can't I declare a define-record-type* record and use it in the same module? <jackhill>cbaines: thans for pushing the dino an profanity updates! <apteryx>ah, it's caused by using make-regexp in the default value <RavenJoad>After the tex changes, is there a package that includes everything? The old "texlive" package does not seem to work for me. <unmatched-paren>anyone able to explain why some packages need to use non-native search-paths? <unmatched-paren>seems like they're only used in builds, but i can't figure out why that is. <unmatched-paren>hmm... native-search-paths are only set in the build environment when cross-compiling <andreas-e>apteryx: I experience a similar problem on my aarch machine, but I get only one instead of three errors. <andreas-e>RavenJoad: What is the problem with the texlive package? Otherwise a full package is currently in the tex-team branch: texlive-scheme-full. It should soon come to master. <RavenJoad>andreas-e: When guix tries to build my channel, I get "(exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (texlive)) (value #f))" <unmatched-paren>ACTION reads comment about TARGET-INPUTS in guix/build-system.scm and begins to bang head against wall <RavenJoad>I am pulling guix to 9f4b6bc right now, from 6a91d4b, if that changes anything. <ngz>RavenJoad: `texlive' variable was recently moved from (gnu packages tex) to (gnu packages texlive), if that matters. <andreas-e>RavenJoad: It moved from (gnu packages tex) to (gnu packages texlive). You will just need to update the module import. <unmatched-paren>(1) why does cross-libc need to be built natively in the first place? <ngz>RavenJoad: Also, for your previous question, the `texlive-scheme-full' package contains everything. It currently being built by the CI, and will hopefully appear soon in master. <unmatched-paren>(2) why is it necessary to distinguish between search paths applied to native inputs and those applied to target inputs? why not just apply all search paths to all inputs? <ngz>RavenJoad: Meanwhile, `texlive' is expected to work, tho. <RavenJoad>Are texlive and texlive-scheme-* and texlive-biber incompatible with each other? I am getting "builder for `/gnu/store/...-guix-package-cache.drv' failed to produce output path `/gnu/store/...-guix-package-cache'" <ngz>They shouldn't be, although it is pointless to have both `texlive' and `texlive-scheme-*' in a profile. <RavenJoad>I was having an issue about a month ago where texlive needed texlive-scheme-basic to generate a cache of some kind. <ngz>RavenJoad: You may want to guix pull. Some bugs wrt TeX Live packages were fixed recently. <RavenJoad>I am trying to pull right now, and that is where I get that failed to produce output message. <ngz>RavenJoad: Basically, if you want to use modular TeX Live (i.e., using anything with "texlive-" prefix), you need to have a "collection" or "scheme" somehow in your profile. Otherwise, you'll not get the necessary files to use your "texlive-" stuff. <ngz>Any collection or scheme is fine, because they all pull texlive-scheme-minimal anyway. <ngz>err texlive-collection-basic <RavenJoad>I want all of texlive, because I am lazy, so the texlive package is what I want, for now. <ngz>Great, you'll have a dozen of packages simulating coffee stains on your documents then ;) <RavenJoad>Exactly. But do I need to remove the texlive-scheme-* package to get the pull's build to go through? <ngz>Anyway, did the change from (gnu packages tex) to (gnu packages texlive) help? <ngz>You can remove everything with "texlive-" prefix, but this shouldn't be a source of error, IMO. <RavenJoad>Changing the import did not change the problem; it changed when it showed up though. If I do not use (gnu packages texlive), then I get an error immediately after pulling. If I do use it, then I get an error during the build of the guix package cache after pulling. <RavenJoad>After pulling meaning after the git pulls are run, but before the guix pull command finishes. <ngz>Even after removing all "texlive-"? <ngz>Maybe you're stuck with a "guix" command that did strange things with profiles when "texlive-" packages were incomplete (per above). <andreas-e>I did have a problem to execute "guix pull" with a channel that tried to include texlive from (gnu packages tex). This was repaired by changing the import *in the channel*. <andreas-e>By which I mean, for one of the package .scm files coming from the channel. <RavenJoad>I removed (gnu packages tex) and all texlive-* packages from my channel, and I still get the same unbound variable issue when building the package cache. <andreas-e>RavenJoad: But did you add the #:use-module (gnu packages texlive) in the files using texlive? <vagrantc>cbaines: it seems you merged the wrong librecast version ... i guess i left out v2 in the patches? <RavenJoad>andreas-e: Ah ha! Found it. It was a package that used texlive, not a system. <RavenJoad>I should read these stack traces more closely. <nikolar>would it be possible for guix to clone with --depth=1 or something like that <apteryx>I think savannah doesn't support it at this time <vagrantc>ACTION went ahead and pushed the updated librecast package <vagrantc>heh. i finally have the secret unsubmitted patches for capabilities #61462 on a machine where i can actually test them <apteryx>jpoiret: I've got some help2man error in my checkout unless I revert "build: Add dependency on guix script for help2man targets." (commit ca8acad3). Any idea what I could do? <apteryx>seems $< would get scripts/guix now instead of guix/scripts/%.scm <apteryx>not sure why 'guix pull' is unaffected <apteryx>ACTION tries moving the new scripts/guix prerequisite to the end <apteryx>ah, it's due to an record-abi-mismatch-error thrown when running: ./pre-inst-env guix deploy --help <nikolar>unmatched-paren: i didn't mean for working with it, but guix pull clones the full repo which currently takes about 500 megs and it's only going to get worse <nikolar>especially since packages are stored there too <nikolar>it's fair enough when you are working on it, but it's really wastefull to have to do a full clone just to guix pull <apteryx>nikolar: isn't a full clone necessary to authenticate every new commits? <apteryx>my help2man problem was resolved by running: grep --include='*.go' -rl user-account | xargs rm <nikolar>but something should probably be done about it eventually <apteryx>nikolar: it only does a full clone the first time you run it <nikolar>but it will only take up more and more space <nikolar>linux git repo takes up about 3gb if i am not mistaken <acrow>vagrantc: Thank you. Works perfectly here. <graywolf>I guess every guix configuration (the (operating-system ...) thing) is under GPL right? There is no way to have it under another license? <PotentialUser-25>havent used IRC in a while so Ill need to setup an account. but i had a question about the scope/capability of the project. <PotentialUser-25>I often experiment with different languages for frontend/backend. getting dependencies to work between different build systems can be a hassle, and mostly results in a shell script or picking a topmost build tool and writing a plugin for the other languages. <PotentialUser-25>is this something guix can help solve? for example, if i have a repo with an elixir app (using mix) that depends on an ocaml app (using dune). <nikolar>if both tools are packaged, then yes <nikolar>that's just the basics though, you should probably look at what packages with similar build systems are duing <apteryx>what's the default emacs-like editor in guix? <Sleep_Walker>Hi folks! long time no see. Is this still the main channel or it has been moved to Matrix? It's a bit confusing when checking via Matrix... <vagrantc>nckx: i know you are probably not surprised, but your capabilities patches work for me :) <Sleep_Walker>I'm trying to fix my system configuration in a way that generated grub.cfg doesn't contain section with crypto partitions (I believe it should search only for the one with grub.cfg and the one with /gnu/store, right? But I have more of them and grub opens them even though it doesn't need it) and it doesn't set locale section (I'm using own grub and this prevents me from sourcing grub.cfg). I found that `grub-configuration-file` function <Sleep_Walker>is used but I'm getting lost with expressing myself in system configuration. Can you help me, please? <nckx>vagrantc: I'm happy with not being surprised :) Thanks for testing. <nckx>Sleep_Walker: There is *no* official Guix presence on Matrix, nor is there any bridge AFAIK. <nckx>Some people got stranded there when the bridge was shut down, unfortunately. <vagrantc>nckx: and my main interest in it just got merged ... so should i nudge the bug about it? <nckx>vagrantc: Sure. Was there still something missing? <nckx>Or did I send those patches only to you? I don't even remember. <nckx>āSome Web serverā pf. <vagrantc>nckx: but i do not think all the patches landed in the bug itself <nckx>That will not aid review indeed. <nckx>Sleep_Walker: What is the āsection with crypto partitionsā? Can you share your grub.cfg so I know what to search for? <vagrantc>nckx: i can comment and say that nckx is keeping the good stuff secret but it worked for me once i got access to it :) <nckx>That makes it sound remotely deliberate and competent so fine by me. <nckx>(But nah, don't bother :) <vagrantc>nckx: but i like your patches very much and think the world would be a better place to share them :) <nckx>Sleep_Walker: So I'm on a 'phone now, but that generated .cfg does look off. I don't think it's supposed to consider all 5(!) cryptomounts as prerequisite store-crypto-devices. <nckx>Is it an option for you to share your system configuration? <nckx>Also, I don't understand the question/problem in āit doesn't set locale sectionā. Can you expand on that? What do you expect differently? <nckx>ACTION curses propagation, againā¦ āguixā propagates ālibx11ā (through ātkā, ābecause headersā :3ā). I mean really. <apteryx>I'm trying to understand how guix-gc.service comes to be included our guix-binary.%.tar.xz Makefile.am targets <apteryx>so basically it takes it from the resulting 'guix build guix' package <apteryx>I'm guessing this: nodist_systemdservice_DATA <rekado>sneek: later tell andreas-e hdf5@1.8 is used by the old java-cisd-jhdf5, which is an input to fastqc. I donāt know if itās possible to upgrade it, because thereās no newer version of java-cisd-jhdf5. <apteryx>it could be just a network error, according to a bug from Maxime on our tracker <Sleep_Walker>nckx: I can show you most of the configuration if it helps - it shows combination of partitioning, LUKS, LVM, LUKS on LVM - mmnt. Problem with locale section is that I have locales installed on the system (and that is correct) but I'd like to not have this section in `grub.cfg` - because I use own grub installation from the other distribution - loading localisation doesn't work. My grub install is just #t. <apteryx>what target should I use to build just the Guix binary distribution tarball? <apteryx>'make guix-binary.aarch64-linux.tar.xz' seems to be the one <mirai>apteryx: idk, its very consistent, every offload craps out like that <mirai>ngz: what provides the bold-extra for texlive? <mirai>bold-extra.sty to be precise <ngz>mirai: texlive-bold-extra <ngz>mirai: Unfortunately, it is not yet in master. It is still in the "tex-team" branch. <mirai>I thought I somehow missed it while guix search'ing <RavenJoad>I just created a cuirass instance and the postgres instance fails to start because /var/lib/postgresql/data/PG_VERSION has incorrect permissions. It has 600 for user 986 and group postgres. As this is a brand new cuirass VM, this should not happen, right? <RavenJoad>The postgres user is uid 983 and the postgres group is 981. <mirai>ngz: what about footnote.sty? texlive-footnote?