IRC channel logs
2024-06-27.log
back to list of logs
<ieure>JetpackJackson, There's a bunch of Go stuff packaged already, you can look at those for prior art. Specific reason for the failure is likely in the build log, but it can be hard to see. <redacted>JetpackJackson, you won't be stuck with the name <redacted>JetpackJackson: the second pastebin link should be the right package <redacted>JetpackJackson `guix import go -r github.com/emersion/hydroxide` <JetpackJackson>Git error: remote rejected authentication: Failed getting response <redacted>Next thing I'd try is checking the network traffic generated by the command with wireshark or tcpdump or something. I don't know how to do that off the top of my head. <redacted>might be a wild goose chase, though. I'm not sure what the right move is. <redacted>I would definitely try updating before doing the networking stuff <imadnyc_>Hey, so I'm a little confused on the entire `use-modules` thing <imadnyc_>do I need to import each module that my packages are from each time (say for vim I need gnu packages vim) or can I just import everything all at once so I don't need to worry about it? <imadnyc_>in Nix everything is accessible by the `pkgs` attribute so this is a ltitle offputting <imadnyc_>also how do I discover which package goes where? I want to install `magic-wormhole`, and while for some package it tells me what I need to import, it's just telling me that I need a "use-modules form", but what module do I use? <redacted>to find which module you need, use `guix search <package name>`. Look for the line that starts with "location:". The module name you need will be similar to the file path, so gnu/packages/magic-wormhole.scm will mean you need to import (gnu packages magic-wormhole) <redacted>you can search for services with `guix system search` and home services with `guix home search` <redacted>I'm not sure if importing all the modules is possible in Guile Scheme, since I've never tried. <imadnyc_>thanks, but doesn't that only work because of how guix is structured? if say i had another channel that had a diff file name than the module name, is the only way to `guix edit <package name>` and look manually? <imadnyc_>like `guix shell <package>` works and it seems to know where it is, how do i tell it to tell me? <redacted>I've been looking over the source code of guix shell and I'm not sure. <imadnyc_>especially since the default home.scm that's part of the latest install doesn't use the speicifcation but rather expects the package name (not as string) <juli>you can get the module for a package the same way whether it's from Guix proper or a third-party channel <juli>assuming you build your Guix with it (that is, it's one of the channels used when you `guix pull') <juli>unlike Nix, Guile is a general-purpose programming language so it works more like a regular programming language than Nix <juli>as for converting package specifications to packages, there's `specification->package' for individual packages, and `specifications->packages' for lists thereof <juli>if you want a specific output of a package without needing to use a specification (which is more ambiguous at the code level), you use a list like so: (list <package> "<output>") <juli>the shorthand form of which is `(,<package> "<output>") <juli>(you'd use this in, for example,`packages->manifest', or a package definition) <juli>(strictly speaking the quasiquote form - the one starting with ` - is more about manipulating whether you're referring to the code as code or as data, but that's not something you necessarily need to know; it does explain some disparities between quasiquoting and using the list procedure, though) <juli>` is an alias for quasiquote; , is an alias for unquote <ieure>Is there some command that'll show me the dependency path between two packages? I would like to understand why `guix build librewolf' is compiling a shit-ton of texlive packages. <ieure>Okay, I see, it's because I had to update nss and flippin' everything depends on it. <noobly>is there a guide for setting up a java development environment on guix? <bigbookofbug>apologies if this is a basic question, but how would i figure out the license type when building a package if it doesnt appear explicitly stated? <bigbookofbug>im packaging some chicken eggs, and it doesnt seem as if the license is stated in the license doc itself <juli>do you mean that the license text does not state the name of the license? <juli>and no other documentation gives the name of the license, either? <bigbookofbug>the license seems like expat i think ? but licensing is a weakpoint of mine when packaging so i still struggle to sort them out unless its explicitly states <juli>I don't know of any good tools except a web search tbh <peanuts>"GitHub - spdx/spdx-license-matcher: A tool to match license text with SPDX license list using a an algorithm with finds close matches. It follows SPDX Matching guidelines to keep the substantial text as well as ignore the replaceable text for matching purposes." https://github.com/spdx/spdx-license-matcher <juli>guix could benefit from such a tool <bigbookofbug>like i cant speak for others of course, but something like a guix get-license as a CLI tool would be immensly helpful. een if it still needed to be manually checked by the packager, it at least would provide a point-of-reference <juli>i may have nerdsniped myself <juli>because i frequently run into this problem <PuercoPop>How do I customize a package to f/e pass a new argument. In this case I want to pass the #:ruby and #:gem-arguments to the ruby-byebug from my guix channel. <PuercoPop>f/e I want to pass pristin to the gem invocation of the ruby-build-sistem to see what happens. <juli>most kinds of package transformations are effectuated by making a variant, yet. there are lots of helpers to facilitate this process, though <PuercoPop>juli: Thanks! I was just about to mention that I had seen that online but I couldn't find it on the manual <juli>let me find an example as well for ya <juli>just need to gather the link <juli>(although you can probably also grep the guix source to find more examples) <juli>hmm... someone should probably document that macro... <juli>in fact, the entirety of (guix utils) probably deserves documentation <juli>i can't tell you how often i bang my head against a problem for ages only to realize later there was a helper procedure floating around the codebase somewhere <PuercoPop>can I use any non whitespace character as part of a symbol-name in guile? Emacs highlithing seems to suggest that I can't use prime(′) as part of the symbol name <juli>idr the exact characters off the top of my head but ' ` , are off the table so i assume comparable characters are as well <juli>I believe Guile's naming conventions match either r6rs or r5rs, though i suspect they are the same <Guest16>Does anyone know how often GNOME gets updated? In the main repo GNOME is still on version 44.10. Which isn't "old" or anything, but I was using 45 since the monent it was available on Gentoo and I don't know how long I can tolerate using an older version. <bigbookofbug>im having a bit of trouble getting an executable installed via the chicken-build-system. the program is an egg, but installs as a binary as well since its meant to be executed (its an i3bar written in scheme). the issue is that, when it attempts to install the bin after building, chicken-install runs into an error where it doesnt have the permissions necessary to install the binary <bigbookofbug>i wonder if, since it is supposed to produce an executable binary, it needs to be installed via a different build system. but at the same time the repo states to cd into the repository and run "chicken-install" to install it, so i'm unsure of an alternative there <bigbookofbug>if its of any help, the error i get is `install: cannot create regular file '/gnu/store/p4035pd4ly3qzip4gqm5dw971miq3100-chicken-5.3.0/bin/tarme': Permission denied` <attila_lendvai>the linux kernel was updated 30 hours ago, and i'm building it locally. something is probably stuck somewhere. <ngz>attila_lendvai: I agree we're experiencing an overall slowness in CI an QA recently. <attila_lendvai>well, stuck could be unstuck, but slowness is understandable and cannot easily be fixed. but it was time for me to learn about `guix pull --commit=[hash] --allow-downgrades` anyway <sepeth>One thing I did different than the post above was to pass --target=aarch64-linux-gnu to the `guix system init` command, and without that I saw a grub related error and the file it was trying to look had i386 in the name. Hence, I added that. <ngz>cbaines: x86_64 and i686 <cbaines>the guix-packages-base builds can often lead to low loads because they get stuck and just take up RAM <ngz>It's slightly better now (there are still 3 machines under 70% though), but at one point, only geidi was working, apparently. <cbaines>that page has been broken for a while, it just needs removing <cbaines>there's so many derivations now that counting them takes too long <cbaines>in other news, I'm part way through rebasing core-updates, so I should be able to push this morning <ngz>OK. Do you need any help? <efraim>is it libfaketime that fails on core-updates on 32-bit architectures? <cbaines>I've already added #68828 but if you have any thoughts on the changes there, that would be great <efraim>so off the top of my head its libfaketime for 32-bit architectures and libclc into mesa for aarch64 are some big problems I know of <ngz>#71785 is uncontroversial, too, isn't it? <cbaines>(or the data service is getting confused) <efraim>uh, it might be actually. I have some not checked-in code around libfaketime on my core-updates branch <ehmry>juli: I am in a #tvl channel and there has been light discussion on the protocol topic <efraim>cbaines: after you finish your rebasing I'll put my thoughts and code together for fixing mesa on aarch64 and send a patch <ehmry>I did some work on absracting and proxy the worker protocol but moved onto working with a frontend protocol <ngz>I think we should reconsider copyright lines at the top of the files. They introduce too many merge conflicts (e.g., 70496). Would it be possible to move them in a single COPYRIGHT file, where each module has its own hall of fame? <ngz>err, listing copyright per author, not module, to prevent the same kind of issue in that file. <ngz>Or force sorting copyright lines alphabetically in each module to reduce the conflicts. <efraim>IMO there's too much potential for bikeshedding, between the FSF approved 15-line minimum, what counts as non-obvious, removing copyright if no code remains, all of it is fair game if we move the copyright to a separate file <efraim>alphabetically (as I understand it) is less common than by date, but I suppose could reduce merge conflicts. At least after an initial conversion <efraim>then again, one package per module also makes it a lot easier to reduce merge conflicts, but feel free to ignore that bikeshed <efraim>ACTION once again feels like a repository of random knowledge <ngz>Let's write packages in a padlet <ngz>In any case, merge issues for such trivial topics are annoying. <efraim>new plan! we improve 'guix import' to create ready-to-build packages and then we can remove "obvious" packages from guix because they can just be re-created by guix import at build time. it also decreases the size of the guix binary! <efraim>ACTION hopes everyone knows to ignore that idea too <civodul>efraim: i’ve long thought that we could use importers at run time, without writing down package definitions <civodul>‘--with-latest’ is actually one step in that direction <civodul>but we could do “guix install cran:whatever”, say <efraim>I halfway think it might be the way out of the cargo mess <civodul>except that the “cargo mess” is now touching the core of the system <efraim>we package some specific crates which need special touches and rely on the importer for others <efraim>indeed. but if we choose to rely on the author's Cargo.lock file then we have a list of crates and their versions which should work <efraim>and which will return the same exact list of crates each time <cbaines>efraim, do you know what the state of rust on x86_64-linux on core-updates is? <efraim>cbaines: no idea, but I can test it locally or on berlin <cbaines>I think the data service says rust@1.69.0 fails to build <efraim>my computer suggests berlin has a substitute for librsvg for x86_64 on core-updates <cbaines>ah, and it does have a substitute for the thing I linked to, so I guess it doesn't fail all the time... <cbaines>On core-updates, I've now pushed core-updates-new. This is core-updates, rebased on the lisp-team and other big changes that landed on master (subversion update, ...). <cbaines>Plus a few new patches, and the changes on tex-team. <cbaines>The bordeaux build farm is still catching up with the master branch, but maybe tomorrow we can delete core-updates, push core-updates-new to core-updates, then delete core-updates-new. <cbaines>I've just killed the stuck jobs on data.qa. so it should process core-updates-new to at least see if that works <civodul>cbaines: what’s new in ‘core-updates-new’? :-) <cbaines>as I say, it's rebased on the big changes on master (lisp-team, subversion update, ...), includes two or three new patches, and includes all the tex-team changes <cbaines>I think we needed to rebase due to the changes on master, so I think it makes sense to at least try changes that shouldn't be problomatic <cbaines>if we do spot new problems, hopefully we can just remove those changes from the branch <civodul>cbaines: yeah well, they’re good for x86_64; for aarch64, we’re virtually not getting much for aarch64 because most builders are stuck (waiting for support from the MDC) <civodul>so it won’t get better, but bordeaux.guix has good figures there <cbaines>I wanted to push it as core-updates-new in case there were fixes/changes other people wanted to make <cbaines>to try and avoid multiple changes in quick succession <efraim>I want civodul's fix for clang-15 on i686-linux <cbaines>since it looks like the changes from master have almost finished being built, we can switch core-updates-new to core-updates tomorrow maybe <civodul>the downside of rebasing is that it’s quite opaque: it’s hard to tell what has changed <civodul>but i guess that’ll be better for the next ‘core-updates’, when we really keep it focused <civodul>efraim: re missing files, i can upload whatever is need on your behalf, just lemme know :-) <cbaines>yeah, I'm hoping that if we can move towards building branches out of patch series, then that can make things clearer <cbaines>efraim, is that clang-15 fix a thing for core-updates? <jpoiret>tracking changes to individual patch series is quite annoying too though, we don't have good tools for this <efraim>yeah, it touches guix/elf or something <jpoiret>sorry i'm weighing in even though i haven't done anything in a while but i've been thinking about the workflow for branches <jpoiret>ideally we could rebuild branches from sets of patchseries, but when rebasing you have to send updated patches to the corresponding mail threads, and that could be quite time-consuming <civodul>efraim: oh wait, the thing to avoid OOMs in gremlin? <jpoiret>there's topgit that can potentially track patchsets and their evolution through time using git but it seems quite heavy to use <civodul>it was really a hack, and i think we shouldn’t do a mass rebuild at this point <civodul>so i’d just #:validate-runpath? (not (32bit-system?)) <civodul>(a bit of a shame, but sometimes we need to cut corners) <efraim>I guess we can do that for llvm/clang. although it was really just i686-linux <cbaines>do we know what the blockers for i686-linux on core-updates are? The data service says libfaketime and gd <civodul>maybe we should just XFAIL_TESTS that one and be done with it <civodul>according to cuirass.log, its heap suddenly grew and then it wasn’t making any progress fetching from Git <civodul>looks like it was stuck somewhere in libgit2 <cbaines>savannah seems to be having problems at the moment <Guest91>Hey guys, I'm trying to setup early kms but I can't figure out what I'm missing. I've added (initrd-modules (cons "nouveau" %base-initrd-modules)) under operating-system. But when I boot, modesetting and GDM are broken. Thoughts? <ngz>Another idea for copyright lines: store them in a recutil database in the repo, and automatically add commit authors to that database through a server-site commit hook <irfus>Regarding my previous messages, I think it's possible I ran into bug #71065 <kks>What's holding back the adb version? <futurile>kks: someone updating it? (don't know this package personally) <jpoiret>newer versions of adb require a new build system iirc, which is not packaged in guix <ngz>cbaines: BTW, shall I delete the "tex-team" branch now you integrated it with "core-updates-new"? <graywolf>Is there a way to configure guix deploy to not produce any ansi escape sequences? <graywolf>Second question: Into where do the activation-service-type services log their output? <redacted>removing `extra-special-file` from my config and reconfiguring doesn't appear to remove those special files from the filesystem <Guest10>why does main guix channel has to be updated so often? <ieure>Guest10, Guix is a rolling release distro; that's how they work. <Guest10>I would be OK with updates like every 24 hours, but now basically every 20 minutes there're some new commits there <redacted>You don't have to pull every update! You can update as frequently or infrequently as you like. <Guest10>yes, I know. I am just trying to get guix to work in a "funny" environment and testing with $guix pull <vagrantc>you can pull to specific commits, too, if you want to reduce the churn <SomniusX>> You don't have to pull every update! You can update as frequently or infrequently as you like. <Guest10>is there a way to modify %default-guix-channel? <eikcaz>I don't think you should modify that variable, you should just have your environment use a different value <Guest10>also no functional-style modification ala (let ((x (copy %default-guix-channel)) (modify-commit x "blah")))? <bigbookofbug>a quick question: im building a package for warpd, which has the ability to disable wayland or x support respectively. when packaging this, what are the guidelines. would it be advsable to create two seperate packages (a warpd-wayland and warpd-x, for example), or is there a way to control the output by specifying multiple outputs <bigbookofbug>i ask because i only see specified outputs with things such as libs or docs, but haven't encountered an example regarding make flags <sepeth>Hi there, when I run ./pre-inst-env guix system init ..., I get guix: system: command not found, hint: Did you mean `system'? Is this normal under pre-inst-env? <eikcaz>bigbookofbug: the same repository produces two binaries? I would just put them in one output. The worry is that you would polute the user's PATH, but I don't think 1 binary -> 2 binaries for one package is worth the extra work to split outputs <bigbookofbug>eikcaz: that makes since. i think its a single binary, but the make flag allows the removal of uneccesary build inputs. for example, on wayland you don't need to pull in x depends, and vice-versa for x <bigbookofbug>its not a huge package so i might just be nitpicking it, but i'll build with both x and wayland enabled and see if that causes any conflicts (i dont think it should) <sepeth>FWIW, I see some failed tests, such as tests/{builders,build-utils,challenge,containers,debug-link}.scm. <sepeth>Oh, solved, I ran the ./pre-inst-env command in a new tab without guix shell. <huguix>hi! I'm having some trouble getting some kernel module options to be loaded. I can do it via the `kernel-arguments` field of my operating system declaration, so my question is not really crucial, but I'd like to figure out how to do it "via modprobe" too <huguix>for reference, I'm trying to follow this solution to a problem I'm having with my (non free) wireless card driver <huguix>if I set the options using kernel-arguments, the modprobe commands do list the options, so it's working fine <huguix>but not if I try to do it by making the config files as in the gist I sent <bigbookofbug>which guix package would package the "ft2build.h" header? i suspected freetype, but using it as an input, im still running into errors with the header not being found when trying to build warpd for x support <huguix>bigbookofbug maybe try guix locate ? <huguix>guix locate says it's indeed freetype <eikcaz>Guest10: I think pepole usually use (cons (my-channel...) %default-guix-channel), but it sounds like you just want to freeze your guix, in which case, use the output of guix describe --format=channels <eikcaz>as in, use the output of that guix invocation instead of %default-guix-channel <PotentialUser49>is anyone here familiar with setting up an authenticated channel? I've made one and I can see that "guix git authenticate" properly authenticates my introductory commit but then fails to authenticate subsequent commits claiming they are "not signed by an authorized key". The key it outputs in the error message matches what I see when I run "git <PotentialUser49>And just to be clear, there is only one commit after my introductory commit (so two commits total) so I know I'm looking at the right one <attila_lendvai>PotentialUser49, that's a bug that has wasted quite a lot of my time <attila_lendvai>PotentialUser49, in short: the guix git authenticate only checks the *second* commit. if the first one is not properly signed, or with the wrong key, then it's accepted as authenticated regardless. if it takes some time for you to record the second commit, then you stand there baffled why the second one has problems. <PotentialUser49>I'm quite confused now. I made a channels and manifest file and tried to use time-machine to set up a shell pulling from my channel and it succeeded. <PotentialUser49>I would think it would fail if one of my commits wasn't signed correctly <PotentialUser49>I've used "git verify-commit" on both of my commits and they're both signed with the same key <attila_lendvai>PotentialUser49, hrm. this could be a different, albeit similar issue. <attila_lendvai>IOW, the channel intro commit is accepted as authenticated, regardless of keys and/or signatures. <attila_lendvai>if you make an error with the setup, then it only fails once there are two commits in your channel. but i'm not sure this explains what you're seeing. <PotentialUser49>I'm just confused as to how to determine if I've actually got this working. My repo is hosted on a private Gitlab instance and I can see in the web UI all of the commits are signed and like I said I can see they're signed when using "git verify-commit", and "guix time-machine -C channels.scm -- shell -m manifest.scm" works with custom packages <PotentialUser49>defined in my channel. The only time I ever see a failure is if I clone the channel repo and try to run "guix git authenticate" <PotentialUser49>and in my channels.scm I do the whole make-channel-introduction thing so I would think it would be needing to authenticate <attila_lendvai>PotentialUser49, oh, so, do i read you right? guix pull works, even with two commits in your channel? and the only failure is running `guix git authenticate` in a local git checkout? <PotentialUser49>but when I use that same exact channels.scm file in guix time-machine -C channels.scm -- shell -m manifest.scm it succeeds <attila_lendvai>PotentialUser49, did you force push this repo? there may be some local caches that interfere... <PotentialUser49>For what it's worth, the machine I'm running this all on right now is not the same one I pushed the commits from <attila_lendvai>i think they are in ~/.cache/guix/checkouts/ and ~/.cache/guix/authentication/ <attila_lendvai>PotentialUser49, you would remember, because you need to run `git push -f` to rewrite git history. <attila_lendvai>PotentialUser49, and you have added your key to the `keyring` branch, right? <PotentialUser49>Is there some specific formatting to ensure that guix finds the key file in the keyring branch? I just named it my_first_name-AAAAAAAA where "AAAAAAAA" is the first 8 characters of the fingerprint <PotentialUser49>the only other thing I can think of is the fingerprint in my commits doesn't have spaces whereas in the .guix-authorizations file spaces separate every 4 characters, but I didn't think that mattered <attila_lendvai>PotentialUser49, i doubt that it would matter, and also silently cause an issue... but if you find that to be the source of your problem, then that'd be a welcome bug report. <PotentialUser49>I'd have to make a new repo to check, but I doubt it considering the formatting of keys in the official guix channel and commits matches mine <PotentialUser49>It's just odd to me that guix pull fails but guix time-machine succeeds when my understanding is that they both authenticate <PotentialUser49>At this point I think I'm just going to spin up a new machine with a clean install of guix and see if it fails in the same way. Like I've said, it's just weird that time-machine succeeds and pull fails on the same channels.scm