<podiki[m]>could be good to have in the contributing section of the docs frequent steps needed? like when a make clean or go-clean is needed, or a reset? or what to do when getting a translation file error? <podiki[m]>(I'm always guessing too, mostly just "make" is fine, but sometimes needs more) <ngz>It did work better after a make clean-go. ***eepbooptheoryb is now known as beepbooptheory
<ngz>So, thanks for the help, and sorry for the noise! :) ***lukedashjr is now known as luke-jr
<drakonis>why in the heck does guix need to pull in ruby to build sbcl <vagrantc>guix doesn't generally hide them like many distros effectively <drakonis>this is some pretty big spaghetti though <drakonis>i looked into the dependency chain for sbcl in nix and it has significantly less components <drakonis>alas i can see how they're not pulling in as many deps <drakonis>but they still don't pull in all of ruby and texinfo <vagrantc>well, if the bootstrap is a binary, chances are there's something in the bootstrap process that pulls in ruby ... <vagrantc>unless the bootstrap was done with a minimal set ... which guix could maybe adopt ... <drakonis>texlive is responsible for much of this messiness <pranavats>jpoiret: Your patches to grub worked. Thank you. <jpoiret>pranavats: great! i'm kinda happy these do work, hope they'll be applied to GRUB for the next released <jpoiret>other distros have the same issue as well <sughosha>Hi Guix, I would like to know how does Guix handles updates of packages. Is every package should be updated manually by the respective maintainers, is there any automated process of handling them via `guix refresh` or something, or does Guix developers handle them in bulk at once? I'm asking this because I tried with `guix refresh gtk` and it says it can be updated to 4.6.1 while the current version in Guix is 4.4.1. <abrenon>AFAIK packages don't have specific maintainers, although in practice of course some people have more interest in such or such package and will tend to follow its development more closely <sughosha>I tried packaging many GNOME World's apps but many of them need gtk4 >= 4.5.0, but Guix has only 4.4.1 as of now. <abrenon>I think many update patches we see are merely generated by their developer with guix refresh, performing certain checks to make sure the software still works as expected, or checking a new feature announced upstream <abrenon>that's understandable, because, and that was my last point, there's possibly a lot of intrication with huge, central packages like GTK <abrenon>I suppose you can just refresh it, but then I expect the amount of work required to ensure it hasn't broken all the existing gtk apps will be colossal <abrenon>plus, when a patch impacts too many package I think I remember there's a specific process required to avoid triggering too many rebuilds at once on the CI <abrenon>I expect such an update to be typically the case <abrenon>have you checked if there's a branch for it ? <sughosha>abrenon: Branch of what, of a package or of Guix? <sughosha>I'm trying to package some GNOME applications, like Tangram and Telegrand. I'm just trying with latest release of them. <sughosha>I will check if they have specific branch like stable or something. Currently I am referring to the release tags (don't know if they themselves are branches or part of a branch). <sughosha>When I `guix pull`, it pulls from the master branch, right? <mbakke>there are only 25 users of GTK4 in Guix, so it should be safe to update on 'master' <mbakke>the_tubular: guix refresh -l gtk <abrenon>so I take it this is "users" as in "packages that use", not as in "humans who use" ? <user_oreloznog>sughosha: I have done 'guix pull --branch=master' to pass from stable to master. <sughosha>user_oreloznog: It seems by default master is pulled, right? <user_oreloznog>sughosha: hmm... I though it was stable by default... Not an expert <abrenon>I've never even noticed there was a stable branch : ) <paul_j>I am continuing to work with guix home, and have a quick question about shepherd services. I created a service for syncthing, but I think I used some code I found elsewhere. Anyway, I have now tried to create a service for gpg-connect, but I am getting an error "gpg-agent: unbound variable". I have the relevant code for the shepherd services here: https://paste.debian.net/1232206 <paul_j>I am not sure where I am creating a variable, or at least where it differs from the syncthing definition. I don't think it is in the provision line, so I am guessing I am doing something wrong with the start and/or the stop fields. <paul_j>I do have a use-modules line for (gnu packages gnupg). <akonai>there's no gpg-agent package, you need to call /bin/gpg-agent from the gnupg package <akonai>or /bin/gpgconf and /bin/gpg-connect-agent in this case <akonai>i.e. I believe #$(file-append gnupg "/bin/gpgconf") should work <paul_j>akonai: did you have a look at the code in the pastebin? I call gpg-connect-agent to start it, and gpgconf to kill it. The only reference to gpg-agent is in the provision field, and in the file-append sections of the start and stop gexps. I could have formed the file-append section incorrectly of course! <akonai>You have #$(file-append gpg-agent "gpgconf"), which tries to get the store name of the package gpg-agent, which doesn't exist <paul_j>So my mis-understanding - let me try again! <paul_j>I need to go and read the documentation for file-append again... <ngz>attila_lendvai: It's probably that no one tested it and confirmed it was ok, I guess. *attila_lendvai is applying it locally <paul_j>akonai: Ok - so just to confirm my understanding: #$(file-append gnupg "/bin/gpgconf") actually returns "/gnu/store/<hash>gnupg/bin/gpgconf". In other words, it finds and dereferences the store location for the package in order to identify the path of gpgconf, so that can be called when shepherd (in this case) stops the service. <nckx>attila_lendvai: Which manual? Guix doesn't have that text. <nckx>attila_lendvai: If you're referring to some Web version, those are rather harder to grep & I'll need some help 😉 <reycoseb>j'aurais besoin d'un peu d'aide post install sur une marchine du marché public Dell / Latitude, je ne sais si d'autres sont dans le même cas. <abrenon>reycoseb: ça rappelle des souvenirs… problèmes de carte wifi par hasard ? <reycoseb>- et j'ai mon ventilateur qui tourne a fond sans process qui chauffe <reycoseb>pas encore testé, je suis en filaire :) <abrenon>ah, le ventilo j'ai pas eu, ça c'est vraiment embêtant <attila_lendvai>nckx, the string "Debbugs User Guide" is present in both the online html and in the contributing.texi file. <nckx>Ah, it shows up as *Note (debbugs-ug)Top:: here <nckx>which is… hm, simple transposition bug? *nckx doesn't know Texinfo good. <reycoseb>so i translate my problem. I use a Dell Latitude 7410 bought with public market at University. This Dell run well with Ubuntu actually. <reycoseb>I try an install of Guix, lot of thinks works, but ... there are problems with : <reycoseb>- fan run at medium speed without any reason (few process) ... <attila_lendvai>reycoseb, guix only has the linux-libre kernel, which only contain drivers that are free software. <paul_j>reycoseb: For the bluetooth and thunderbolt, this could be a result of binary blobs being present in the ubuntu distribution, which are not licensed in a way acceptable to the guix project. <paul_j>Not sure about the fan speed, but probably the same issue. <nckx>attila_lendvai: That link works, though. <nckx>attila_lendvai: You might be missing the emacs-debbugs package. <abrenon>the problems don't occur under ubuntu ? <abrenon>then attila_lendvai 's drivers lead sounds like a good one unfortunately <nckx>(Hence why I asked if you were talking about some Web copy…) <attila_lendvai>nckx, sorry, i'm reading the manual online usually, and wrongly assumed others, too <nckx>I'll take a wild stab at adding it to htmlxref.cnf, thanks. ***OJ[m] is now known as allilm[m]
<nckx>I'm out of my depth: doc/contributing.texi:1380: warning: no htmlxref.cnf entry found for `debbugs-ug' <nckx>(I'm aware that some of those subdirectories might be bogus, but wanted to make sure it wasn't due to any ‘missing’.) <allilm[m]>Hello there! I'm having trouble building an ARM image for my RockPro64, Pinebook Pro or even just the example in the Guix manual. Fails on building efivar. <sughosha>I am trying to `./pre-inst-env guix refresh -ru gtk`. For every package it is asking "Would you like to add this key to keyring ...?". I don't know what to answer. How can I get this passed? ***allilm[m] is now known as OJ[m]
***roptat is now known as Guest8046
<apteryx>it probably wants to save the PGP key used to sign some release archive <apteryx>this way it'll automatically validate the signature of the release archive with it ***form_feed is now known as \f
<sughosha>Hi again! I am facing difficulty in packaging some applications which use meson build system but have cargo inputs. In build phase, it says "Updating crates.io index" and then "warning: spurious network error", and then "failed to get ... as a dependency of package ...". A help is appreciated. <podiki[m]>I don't know the specifics, but there is no network access in the build environment, so probably you need to have those sources already (from a package in guix) or patch/unbundle them <podiki[m]>someone with rust experience will know better <podiki[m]>maybe there is a similar package already in guix you can look to see how it was handled? <sughosha>I already added the needed dependencies in native-inputs, but still I'm getting this error. <podiki[m]>right, but it might not see them; e.g. meson can have submodules it will fetch and build, that you'd need to modify meson.build to do <podiki[m]>to do meaning "to find the package inputs instead" <sughosha>Hm, I only know to use meson-build-system, not familier about meson itself. <sughosha>I am also not aware, if there is any argument like #:cargo-inputs. <SeerLite[m]>Is it all Rust? Maybe you'll have to use cargo-build-system instead <podiki[m]>I only know a little about meson, from my own packaging hacks :) <sughosha>All of the package upstreams recommend meson in their README. I never tried cargo-build-system, I will try one now (have to learn first). <balbi_>hi folks. What's the trick to get `guix' (well, gnupg under `guix') to recognize my nitrokey? same config works on arch, doesn't work on `guix'. I'm assuming I'm missing some service, but no idea what it is :-p <sneek>balbi_, lilyp says: Guile-based graphics libraries are still on the experimental side, but you do have curses, sdl, and gtk in some capacity. <alMalsamo>is there any way yet to download all source tarballs for a system definition to pull all code necessary for compiling every package later offline pulling from local storage where all the source code hsa previously downloaded to? <acrow>alMalsamo: When you ask, "is there any way", I think, are you asking if this is possible? To that, I think, yes; but I don't think that is what you really meant. I think you meant to ask if caching of source was a guix feature. To that I would say, not that I am aware of. However, source code caching for subsequent builds is sorta already there. You just want to postpone the phases 'unpack and beyond for later offline execution. <balbi_>reza[m]: I'll give it a shot, thank you :) <balbi_>reza[m]: worked like a charm, thank you :) <alMalsamo>acrow: Do you know where in the source of Guix the feature for caching for subsequent builds is so I can try to study it and see how the fuck I can postpone for offline use? <acrow>alMalsamo: It would require some digging around. I don't understand exactly what your motivation is but might it be easier to make your machine it's own substitute server and leverage local substitutes offline rather than caching and then building from source? Guix substitutes are verifiably reproducible. <cbaines>alMalsamo, it sounds like you might be looking for guix build --sources=... <cbaines>in particular, the --sources=transitive option is documented as: " This can be used e.g. to prefetch package source for later offline building." <acrow>alMalsamo: cbaines has your answer. I didn't recall the --sources build option. <alMalsamo>cbaines: Wow cool... kind of confusing to be a switch to the "build" command since it seems not to build anything, but it looks like it applies patches, but that is not the same as building really... <alMalsamo>guix build --sources=transitive looks to be exactly what I need, but I would like to do this for an entire system not just one package at a time <unmatched-paren>how would i inherit from a package, then modify its arguments to add a new field? <unmatched-paren>i noticed that my neovim package in my channel had -DPREFER_LUA:BOOL=YES in its #:configure-flags, which forces it to link to lua instead of luajit <unmatched-paren>that's good for architectural compatibility, but (1) it's faster and (2) it contains some exclusive features that many neovim plugins depend on <unmatched-paren>so i want to create a neovim/no-luajit package which is exactly the same, but adds that configure flag <jackhill>hmmm, `guix gc --verify=repair,contents` doesn't seem to be sucessfully reparing files (it tries to repair the same store items on a second run). Is this likely to be a hardware problem? https://paste.debian.net/1232259/ <jackhill>alMalsamo: I haven't checked, but I wonder if `guix system build` would accept the --sources=transitive option. Otherwise, you could probably get `guix build` to do your set of needed packages by passing it a manifest, but if `guix system` will do it, then it will save you the trouble of figuring out which packages your system needs :) <jackhill>unmatched-paren: for you specific thing, we could use different options per-archetecture. I thought there was already something in the patch tracker for that… <jackhill>alMalsamo: oh, darn. Sorry I should have checked first, I was just hoping! <alMalsamo>Hmm well this would be an amazing feature for offline installation <nckx>‘OPTIONS can contain any of the common build options […] In addition […]’ <alMalsamo>nckx: Hmm okay this appears a lot further down on the doc page than the section describing guix system build, it is kind of confusing order, does this apply? Are you saying I can use --sources=transitive switch to guix system build and it will download source code + patches for every single package in guis system definition? <nckx>Alas, ‘--sources=’ is under ‘The command-line options presented below are specific to ‘guix build’. <nckx>Alas, my big-brained scheme to abuse ‘guix build --sources=transitive $(guix system build -d /etc/guix/system.scm)’ went nowhere in a hurry. <djeis>Does anyone know if something's blocking an update of guile-netlink to 1.1.2, and if nothing is could someone point me towards the simplest way to offer the updated package I just threw together? (all I did was update the package's version/hash and check if it builds) <nckx>djeis: Assuming you have git set up and it's the top commit, it can be as easy as ‘git send-email --to=guix-patches [at] gnu.org -1’. <nckx>That's the minimum, but it would be nice to rebuild all dependent packages (guix refresh -l guix-netlink) and run the system tests (make check-system, although I'm not sure they all pass as-is). <djeis>I don't have a setup for changes in-tree yet, so to test I just copied the package out to my private channel. I'll try to do that this weekend though, I think it'd be a good first contribution and it's directly related to some work of mine. <nckx>Thank you, and feel free to ask for help here or on help-guix [at] gnu.org if you hit any snags! <alMalsamo>nckx: So you think this is currently impossile with Guix? It would be a damn nice feature...