<nouun>Is there a way to package a local file relatively? I.e. I have ./packages.scm and ./some-package and want to use some-package as the package source. <cwebber>a package trying to wget a dependency during its build step <cwebber>hey what's an example of a package with multiple input tarballs I can look at, because I have completely forgotten how to do this and can't find another example <cwebber>or is the right way to do that native-inputs <attila_lendvai>i have an example like that, but it has the sources as inputs, not native-inputs. is the latter better/preferred? ***jfred is now known as jfred-server
***jfred-cloud is now known as jfred
***PotentialUser-52 is now known as Helmebe
***Helmebe is now known as helmebe
<helmebe>Hi Guix, I am a beginner and think I have identified an improvement to one of the packages. What should I do next? <sneek>vagrantc, you have 1 message! <sneek>vagrantc, apteryx says: w.r.t. to a .deb guix pack available for install, it'd actually be possible via a postinst script <vagrantc>apteryx: didn't know guix pack had supports for maintainer scripts ... interesting :) <helmebe>vagrantc: I would like to add a missing entry to the native-inputs of a package definition. Looking at the Contributing section, I am unsure whether this should be a bug report or a patch? <vagrantc>helmebe: if you've got a patch, send it as a patch :) <vagrantc>helmebe: if you're not sure of the fix, maybe file it as a bug report <vagrantc>does it fail to build without it, or just misses some features? <helmebe>vagrantc: No, I do not (yet) have a patch :) ...let's say I'd like to go that route (also to learn how to do that), what should I do? For example, which command(s) should I use to get the package definition to my machine where I can edit it? The package works without the entry, but some features are missing. <vagrantc>helmebe: the "building from git" section mentioned in the link i mentioned earlier <vagrantc>helmebe: and then the following section "running guix before it is installed" <vagrantc>basically, it's checking out the git repository for guix, and setting it up to build packages from your local copy of guix git, and then you can edit the packages (mostly in gnu/packages/*.scm) and build using ./pre-inst-env <vagrantc>also useful is ./pre-inst-env guix edit SOMEPACKAGE <vagrantc>oh, this is the nss-certs dance. basically you need nss-certs (or maybe le-certs?) installed, and then export SSL_CERT_FILE and SSL_CERT_DIR appropriately... think there's a section in the manual for that too ... i usually have it in my system configuration and those variables get set up automatically <helmebe>vagrantc: I am currently using Guix package manager on top of Ubuntu, so I'm unsure whether I could add something equivalent to my config... would be nice to have that as a default though, as SSL certificates seem to be something rather basic... anyway, one problem at a time. <vagrantc>helmebe: that link above describes adding the variables to your user's configuration too <helmebe>vagrantc: This did the trick, at least for git clone: <helmebe>export SSL_CERT_DIR="$HOME/.guix-profile/etc/ssl/certs" <helmebe>export SSL_CERT_FILE="$HOME/.guix-profile/etc/ssl/certs/ca-certificates.crt" <helmebe>export GIT_SSL_CAINFO="$SSL_CERT_FILE" <helmebe>vagrantc: Now I am wondering where that ./pre-inst-env script lives... <helmebe>...or is that specific to me running a GuixSD? <vagrantc>pre-inst-env is generated by "building guix from git" section in the manual <vagrantc>it's a little trickier on a foreign distro ... i usually have to run it inside a "guix shell --develop guix guix git ..." <vagrantc>i forget all the packages off the top of my head <vagrantc>helmebe: gotta head out soon, but good luck! <vagrantc>it's all in the manual, even if it is a bit verbose at times ... there might also be some good intro to packaging in the guix cookbook <helmebe>As a beginner, I find it sometimes hard to find which parts of the manual are applicable/relevant/necessary to my specific circumstances/questions... for example, in the above, I wasn't sure whether cloning guix was necessary just to create a patch for a specific package. <vagrantc>yeah, that's why i said verbose ... the cookbook stuff is aimed at being more about how to do things, the manual is more about how everything works <vagrantc>i just stumble through it all and sometimes make things work :) <Nooblet>Hello, gents. Has anyone on here used Guix for very minimal or granular control similar to Gentoo? I've got an ARM board, and I want to keep it very light weight. <Nooblet>Worst case scenario, I'll just use Gentoo and maybe make a build server external to the ARM board, but I was hoping to keep most of my ecosystem in Guix for the glorious reproducibility. <AwesomeAdam54321>Nooblet: I haven't used it that way myself, but it's definitely possible <Nooblet>Aye, it looked more than possible, but I was going to see if I had to invent the wheel or not. <AwesomeAdam54321>If you're installing the Guix System, then you can pick a DE like XFCE or MATE <Nooblet>Ah, I was thinking lighter than that. <Nooblet>I've made a couple configurations that were "stripped down," but this would need to be moreso. In the interest of battery life, I don't want a lot of services running, and Guix has a lot of things I don't want in %desktop-services. <Nooblet>Oh! That's another good question. Is there a place where I can look at what services are in %desktop-services and %base-services? <Nooblet>Because some things like PAM might be beyond the scope of my project. <iyzsong-w>Nooblet: %desktop-services is defined in gnu/services/desktop.scm <iyzsong-w>well, read the code is the fastest way i known :) <helmebe>OK, I have now applied the change to the guix/gnu/packages/*.scm file and rebuilt with ./pre-inst-env guix build PACKAGENAME <Aurora_v_kosmose>What package contains gfortran ? I'm getting: ld: cannot find -lgfortran <helmebe>What's the easiest way to install the re-built package to my local profile to verify the change was effective? I read about Guix channels, is there a simpler way? ***lukedashjr is now known as luke-jr
***Xenguy_ is now known as Xenguy
<helmebe>AwesomeAdam54321: That worked, thanks! <unmatched-paren>so i'm going to try to bootstrap ocaml 4.13 with the 4.07 built using camlboot <unmatched-paren>i managed to get menhir working with ocaml 4.07's dune, and it provides an easy way to bootstrap from ocamllex <unmatched-paren>but i do have a question: i have a dune file patch that i need to apply. is it possible to apply it in one of the build phases instead of the source? <abrenon>unmatched-paren: there are examples of packages where patches are applied as a build phase, not in source, yes (see gnu/packages/docbook.scm l.558 for instance) <abrenon>you're welcome ! (out of curiosity, why choose to apply patches in the source or in the build ? I never had to apply any patch in a package declaration) <abrenon>this was the first example I found, maybe there are others with an actual patch file ? <unmatched-paren>i'll try `rg patch`, but it'll probably come up with a lot of results.. <unmatched-paren>the reason i'd like to do it in build phases is so that i can inherit from the ocaml-menhir package for my ocaml4.07-menhir package without duplicating its (source (origin ...)) just to add a patch <unmatched-paren>i think i've found a package that inherits from another's source in gnu/packages/tex.scm though... <unmatched-paren>oh, that's pretty simple: (source (origin (inherit (package-source foobar)) ...)) <abrenon>ok, and then you can add your patches there <abrenon>I've kept searching but the more I do, the more I'm convinced build-phases patches are just about running regexps, not applying patch files, I think you're right <AIM[m]>Anyone know how to add a keyfile for luks in guix? <AIM[m]>I don't wanna type the same password twice for luks <AIM[m]>Like it asks for grub and then for initramfs <tschilptschilp23>iamaravindi: I've tried this weekend, but not very successfully. I just reached the point where my computer wouldn't boot anymore without the sd-card inserted holding the keyfiles (without actually unlocking my luks drive). So the way with manually creating an ~/etc/crypttab~ isn't very fruitful (at least for me). I was told to custom-patch ~gnu/build/linux-config.scm~ (or very similar) on a local checkout and use the guix built by <civodul>is it me or did committers all go on vacation this month? :-) <tribals>Hello there! I'm trying to use Guix for packaging my own project written in Python. As I understood, I need to define a "package" and choose "build-system". There is build system for Python packages. So everything looks pretty straightforward. Except one thing: as I'm building from local directory which contanins source code I don't need to pull it from Internet. So how to specify package's source that way? <tribals>I also tried to import it using PyPI importer, but unfortunately it could import only published packages, always downloading them from Internet <abrenon>yes, you can of course specify a local source for a package <abrenon>the function for this is (local-file …) it returns a value that can be used as value for the 'source' field <abrenon>and it expects the path to the source directory <abrenon>there are filter keywords to tell it to crawl the directory recursively or to select files based on their being versioned in git (but you can pass any selector really, it could be a convention in your file names) <abrenon>I have to go now sorry but I'll be back in the afternoon if the usage is still unclear or no one else has helped you <tribals>But I want to use same package definition everywhere: in CI, in local environment, etc. So, I don't want to edit it each time in order to adapt for current environment. Is there any way to specify actual source code repository, but build from local directory instead? ***alMalsamo is now known as lumberjack123
<tschilptschilp23>tribals: If I get abrenons advice right, this would mean, you can just adapt the guix.scm-file to your needs, and then install it through ~guix package -f guix.scm~. This should make it available in your 'whole' environment! <tribals>The thing you just described is exactly what i'm striving to achieve <tschilptschilp23>That seems to be a python-package not yet in Guix, but ought to be installed through the posted file itself. I hope I'm not pushing into the wrong direction though... <tschilptschilp23>(or better -- with the python source code in the same directory as the guix.scm file, some guessing involved though) <tribals>I'm trying to invent my own "workflow" (sort of) for any project i'm developing. So i decided to put Guile files in proper modules from the start. This imposes some constraints to files layout. I don't want to put everything related to guix in single top-level guix directory inside project. The reason for that is not everything packages I'm writing is meant to be shared - some need to be private. I stick to some kind of "naming scheme" borrowed from Guix <tribals>itself: I put packages in "(vendor packages)" namespace, and in vendor/packages.scm file. This approach, on the other hand, isn't very understandable by teammates involved. <tschilptschilp23>I'm not really developing software -- I mainly use software that is already packaged. So I cannot give a serious advice on that. I do have a few packages packaged locally, but they rely on an existing upstream source like github, like how you describe. That's why I find the link very helpful (will try like that, once I wrote some source code). I think https://gitlab.liris.cnrs.fr/geode/EDdA-Classification/-/tree/master (just one <tschilptschilp23>directory up) shows the context nicely! So one would just have to add a guix.scm to the source-code top-level and do ~guix install -f /PATH/TO/SOURCE/guix.scm~ from any directory to get it installed, and not do a major messup of the layout. <tschilptschilp23>One can also use guix channels pointing to github or other places. I do not know though, if channels support ssh, which would allow for private github repos. <tribals>The reason why I decided to put everything in proper modules is as follows: If you want to use -f command line switch of `guix` command, it requires you to write it the way that whole file evaluates to package definition. I found that very restrictive because it forces you to mess everything in one big file. Personally I strive to "put everything in place" - so later I can share it: among projects, vendors, whatever it will be useful <tribals>The ultimate goal of sharing is to contribute back to upstream, so inevitably things end up in `guix/packages/foo.scm` or the like. <tribals>This is another reason why I don't want to use `guix`-y names of everything. <zimoun>civodul: about hardened and ssp, do you know benchmark? Because, AFAIK, Gentoo, Arch Linux, RedHat, Fedora, OpenBSD are using -fstack-protector-strong by default. <tschilptschilp23>Honestly I did a ~GUIX_PROFILE="/home/me/.guix-profile"~ and ~. "$GUIX_PROFILE/etc/profile"~ in between, but that's mainly because I have everything in guix-home, I think! <zimoun>civodul: so in HPC context, the performance lost is probably an issue but for general distribution, it appears to me worth to have it. <jpoiret>tribals: you can use `guix build -e "any guile expression"` to build an arbitrary value <jpoiret>iiuc, you want to have some packages that build from local sources and others from online repos, or do you want to build a specific package either with local source or an online repo? <jpoiret>that's going to be a bit annoying then. But you can definitely have something like (source (if should-build-local? (local-file ...) (origin ...))) <tribals>I want to build my project as Guix package everywhere: on my localhost while developing it, in CI, in production - everywhere. In the end, it is all about delivering the right code to right server. <tribals>To me, Guix solves this kind of a problem very well. So, I want to stick with it for every code I need to put on some server <jpoiret>i don't think anyone would recommend incrementally developing something with guix as the builder <jpoiret>well, you miss out incremental compilation, and guix's build times are not suuuuper fast <jpoiret>it needs to do a whole lot beyond just using the python build system <jpoiret>personally, i'd suggest using a manifest to setup a development environment, and just using python directly from there <jpoiret>but then, if you're developing interconnected components it might get complicated <jpoiret>that doesn't prevent you from also using guix for packaging, deployment and CI, it's just that for local dev it might be too unwieldy <jpoiret>of course, the above snippet might Just Work For You™ and that's great :) <tribals>Actually, I want to push "reproducibility" to the limit :) If a cant (with Guix) to reproduce deployable code, and there is some integration points like guix home and manifest files, then coldn't I reproduce the whole development envirenment as well? Unfortunately, the answer is "No" for now. Reproducing environment means more than just software distributions with right versions. It includes managing dependencies of a project in more high level, like if <tribals>you need a database, then you need not only a python library for interfacing with DB, but *actual* DB as well, no matter of which environment. You need it in local development, CI, staging, pre-prod and production - everywhere. So idea is like that: we already have reproducible software distributions, we have notion of services, we have a guix home and guix shell with maniferst support. Could we, for example, write manifest which brings up DB server of <tribals>needed version, known access control set up, and pre-populated data? <tribals>We can bring up a server for sure - it could be just a service in project's manifest. But could we define custom profile in that manifest? <tribals>Custom profile could include shepherd service extended with our project's "high-level" dependencies like DB, and even could be run as user, not root. So we currently even supervising of long-runnig processes. <jpoiret>what you're describing is something that is on the wishlist, but hasn't been attempted yet <jpoiret>there's definitely a need for it too <singpolyma>Pretty sure a service can run any commands. So it could run command to set up db and push in schema and seeds etc <allana>tribals: Have you found a solution that works for you in regards to developing Python on locally defined packages/dependencies? I may be doing something similar with a guix.scm, "guix shell" and sometimes "guix pack". Perhaps I don't have the quickest development cycle but I'm working mostly with Docker containers produced by guix pack. abrenon is possibly the one who helped me before with the %source-dir suggestion. <abrenon>zimoun: thanks for your answer, I didn't thank you by email because gmail seems to reject mail from our mail server but I saw it : ) <tribals>allana: No, I'm still searching for one :) Mine workflow is very similar to you - Python application which need to be distributed to production, dependencies mostly as Docker Containers. I need a way to do that in less tedious way )) I came here exactly in `guix pack` in mind. If we already have reproducibility of software "for granted", which is one of key features of Docker too, then could we skip whole `docker build` and replace it with `guix pack`? <tribals>Definitely, we can. But this is only a half of the story. Docker is not only "reproducibility", but "orchestration and tooling" too. Which I prefer to call just "integration". If we could replace `docker bulid` with `guix pack`, could we replace Docker Compose (a plenty of useful features like isolated networking) too? <jpoiret>Docker doesn't have reproducibility as a feature though <jpoiret>99% of dockerfiles start with RUN apt update <tribals>Exactly! It is advertised but still not achieved :) <singpolyma>jpoiret: with docker it's the image that provides reproducibility not the dockerfile <jpoiret>tbh advertising docker as a reproducibility tool is just like saying "ohhhh linux namespaces give you reproducibility" <jpoiret>singpolyma: would you call a pre-compiled binary on GitHub reproducible? <jpoiret>cause that's what docker images are, along with docker repositories <singpolyma>jpoiret: it's bit for bit the same every time I download it, so yes :) <tribals>So, if Docker fails here, may be Guix qualifies? <jpoiret>the one thing docker definitely does is isolation <tribals>So, for now we need to deal with next thing - "integration" )) <jpoiret>it's just a more manageable layer over linux namespaces <singpolyma>For sure, people say docker and they just mean OCI. Run it under firecracker for real isolation or whatever. Docker/dockerfile isn't really an interesting part <jpoiret>guix also has packs and isolation :) but yeah, we're missing a "portable guix system" like docker-compose <singpolyma>Well, guix has guix system vm which is pretty close <jpoiret>it's definitely something that, when adressed, would be a HUGE leap forward, compared to every other piece of software imho <singpolyma>Always happy for things to become more flexible ^_^ <abrenon>I don't follow you (possibly because I'm not familiar with docker compose): why don't you deem the output of guix to be "portable" ? <abrenon>you can pack it to tar archives, you can create docker containers with it, you can create a vm like singpolyma suggested <jpoiret>it's not the output of guix that's portable, what i meant was that you can't use guix system services outside of a guix system instantiation <jpoiret>it's not that the output of guix is not portable * <jpoiret>so you can't e.g. do something à la docker-compose <allana>So, I haven't actually ever used docker-compose, and I'm not familiar with what it does, but I am building docker containers via "guix pack", and importing them into my local docker store, and in some cases running multiple containers on a local docker network. Without looking up much about docker-compose, this sounds like what I should be using to avoid some tedium. <allana>But my target deployment environment happens to be Kubernetes, and usually I don't need to bring up multiple containers on my development machine <jpoiret>yes, basically docker-compose orchestrates multiple containers by configuring them all through a single file <jpoiret>you could also use k8s locally, but i've never tried to do that <tschilptschilp23>jpoiret: but to be able to docker-compose, people also have to install docker ;) <jpoiret>you'd need to have guix installed to use guix system services though? <allana>I happen to have a test cluster available off of my workstation, but I also want to run it locally via "Kind". Also I wanted to package kubernetes for guix but that is a big endeavor and I am too busy at present <allana>And it is not a small undertaking <ekaitz>hi guix did you guys tried recently to compile gcc-4.7? it doesn't build... <ekaitz>civodul: the problem we discussed yesterday is worse than I thought <ekaitz>it is a hidden package but anyway it should be able to compile <ekaitz>i run guix build -m manifest.scm, being the manifest (packages->manifest (list gcc-4.7)) and it fails <ekaitz>at least it's failing on my x64 machine <abrenon>how quickly does it fail / how long is the whole process supposed to take ? <tschilptschilp23>jpoiret: totally, what I meant is -- who likes to use guix, has to install guix, who likes to use docker, has to use install, who likes to use both, is mainly good with guix only. But I haven't yet tried to run guix on a foreign distro (except for within virtual machines)... <ekaitz>abrenon: it's a pretty long process... in my machine is like several minutes <abrenon>ekaitz: does that look familiar ? ./md-unwind-support.h:60:47: error: dereferencing pointer to incomplete type <zimoun>abrenon: yw! Ah ens-lyon folks. ;-) <ekaitz>abrenon: that's exactly the error I got <abrenon>and what's that supposed to mean ? ^^' <abrenon>yeah, I had understood that much, which is why my snarky answer was aimed at my other interlocutor : ) <abrenon>it was very confusing, hence my other message right after <abrenon>but so it means that the error you have is reproducible \o/ good news <abrenon>I suppose that doesn't mean that gcc's source for that version fails to compile in itself, so what ? some tooling's missing from the compilation environment ? <ekaitz>I've been trying to compile several gcc versions during this week and I'm basically out of ideas <abrenon>is there a flag required be able to dereference a pointer "to incomplete type" ? (I have no idea what an incomplete type is in C) <ekaitz>it looks like there's some library missing or something like that because incomplete types are those that are defined like `extern` if i'm not mistaken <ekaitz>it's like something is not being completely defined <ekaitz>btw 4.8 is also failing to compile so it might be related <ekaitz>I'm compiling gcc-5 now and it looks like it's working <attila_lendvai>the C compiler can happily deal with a pointer to an undefined type (only the name is known, but not its shape), as long as no one is trying to dereference the pointer <zimoun>civodul: as I said, I am not convinced another subcommand is useful. I am in favour for “guix shell --export-manifest”. :-) <civodul>zimoun: i was asking for *more* feedback ;-) <jpoiret>at the risk of derailing the discussion a bit more, i think the main discoverability argument could be applied to the manual instead: there isn't a section on manifest, even though they're pretty powerful <jpoiret>but i don't create manifests every other day, so your colleagues may have a more relevant opinion on this :) <civodul>jpoiret: good point; like i wrote there, i was going to write a section on writing a manifest when i realized i didn't feel like recommending "guix package -p $GUIX_ENVIRONMENT --export-manifest" as an interface to get started <jpoiret>what i'm not fond of is that --export-manifest uses specifications everywhere, but i guess that's a guile limitation <ekaitz>abrenon: GCC 5.5 compiles correctly, the problem is only on 4.7 and 4.8 <ekaitz>should I open an issue with this? <civodul>(can be discussed/addressed separately) <jpoiret>overall it seems okay to me, moving --export-manifest to its own subcommand is cool, it always seemed silly to be using guix package for that <civodul>(though adding -p as lilyp suggested would make it equivalent in that case) <jpoiret>how so? the end goal would be to make it equivalent <civodul>"guix manifest x y z" would be independent of any existing profile <ekaitz>opened a bug report, if you want to take a look: #54626 <peterpolidoro>hi. is it possible to specify a specific version number when using guix refresh? <peterpolidoro>if you want to update a package to a version that is not the version found when simply running guix refresh PKG <abrenon>civodul: re: #54393 yeah manifests are a bit intimidating, at least I know I probably don't use them as often as they could help me <abrenon>but I'm not sure the concept of "manifest" which can be a bit obscure and scary to newcomers would become clearer by having a subcommand <vagrantc>a manifest can be as simple as a list of packages, more-or-less ? <abrenon>I'm wary about subcommands which purpose isn't clear and immediately obvious <abrenon>vagrantc: at least in my current understanding, that's what they amount to <vagrantc>i mean, it's guile, so you can do fancier things probably :) <abrenon>I'm sure they encompass more subtle concepts, yeah, but that's how I view them <abrenon>but it took me quite some time to become sure that I could see them as just that, in part because of the name (at first, the various --manifest options themselves were a bit scary) <vagrantc>yeah, i still don't consistently use manifests, and just deal with the repercussions when they come up ***lukedashjr is now known as luke-jr
<abrenon>also, it's a bit weird that manifest would take the -m option too, IIUC that would merely concatenate the various files passed that way ? (and be a pretty-print when only one is passed ?) <unmatched-paren>this is unrelated to guix, but i'm not sure where else to ask (i have two general free software licensing questions): (1) if i fork a project that's under a non-copyleft license, can i change my fork to use the GPl, and (2) if said project has a license notice in every file, can i remove those notices and replace them with one in the README so that I don't have to keep updating them all? <unmatched-paren>well, i guess it is _kind of_ guix-related, since the thing i'm forking will hopefully assist in growing the bootstrap chain <apteryx>but perhaps you already see a myriad of options it could support in the future that would be ackward to use with 'guix shell --export-manifest' ? <vagrantc>unmatched-paren: you could add changes under a new license, if it was compatible with the old license, but unless the old license allows it, generally you can't remove the old license <unmatched-paren>the old license is BSD-3-clause, which is compatible with GPL-3, but i'm not sure whether it would allow changing the entire thing <vagrantc>it explicitly requires you keep the license terms <vagrantc>explicitly stated in the very short bsd-3-clause terms :) <unmatched-paren>yeah... i wasn't sure whether 'keep the license notice' meant 'keep every license notice in the original place' or 'keep the license notice somewhere' <tschilptschilp23>is there a way to let ~guix weather~ tell me about which package is not yet substituted, if I, say, pass a manifest to it? <tschilptschilp23>and -- does anyone know the reason, why I have to put eg 'icedtea-8' into my home-configuration, but ~guix weather~ will not recognize 'icedtea-8' but only 'icedtea'? <tschilptschilp23>and one more question -- any long-term risks using ~"package"~ instead of ~package~ into a home-configuration? <unmatched-paren>when you do "foo" in guile or `foo` in a guix package subcommand, that's a package specification <unmatched-paren>when you do just `foo` in guile, you're just accessing a variable containing the package <unmatched-paren>if you were to `guix edit icedtea@8`, you'd see that the `icedtea-8` variable contains a package whose name is simply `icedtea` <tschilptschilp23>oh, thanks. I've been wondering about this a while already... practically this means my attempt to use manifests as a 'pre-checker' using weather before reconfiguring, needs a little more handwork then... <unmatched-paren>so, specifications are just shorthand strings that can be used to reference packages, package versions, and outputs (`package:output@version`), but the package variables are literally just guile variables :) <unmatched-paren>tschilptschilp23: note that you could use the (specification->package) procedure in your config to allow the use of specification strings instead of package variables <tschilptschilp23>Yeah, that's what I have in my system-config! But in my home-configuration I just have ~...(packages (list ...))~. So there's more work to be done (quite some ~"~ ;)). <tschilptschilp23>I wanted to make quick package-manifests from both, and then noticed the difference, hence my question regarding ~"~ in home. Mhm, maybe home also takes ~(map (specification->package) ... )~, then I would have things somewhat more congruent... <unmatched-paren>tschilptschilp23: (map (specification->package) <specification list>) will work anywhere that <package list> works... <unmatched-paren>(map <PROC> <LIST>) takes a procedure and applies it to every element of the list <unmatched-paren>so (map specification->package (list "foo" "bar")) is equivalent to (list (specification->package "foo") (specification->package "bar")) <unmatched-paren>afaik guix does not automatically convert between package lists and string lists <unmatched-paren>it would actually be quite neat if it did... would save us all a bit of typing <unmatched-paren>(btw, i said above that it was `(map (specification->package) ...)`, but it's actually `(map specification->package ...)`) <civodul>apteryx: not really; "guix shell --export-manifest" would also work i guess <unmatched-paren>if you don't put parens around a procedure, you have a procedure object, not the result of calling that procedure; this is how `map` works <tschilptschilp23>I'm just wondering if the ~(packages (map specification->package (list "foo" "bar")))~ way would also be applicable in the ~(home-environment (packages (list foo bar)))~ section. But I start doubting, and don't really start complaining about the few quotes now ;) <unmatched-paren>(as long as the package named `foo` corresponds to the variable named `foo`, which it should) <unmatched-paren>the reason why package variables sometimes deviate from specs is if the package has multiple major versions <unmatched-paren>so, some packages might not work with say, openjdk@16, and require openjdk@8, then it can use the openjdk-8 variable in the package definition <tschilptschilp23>so I'd finally get rid of the ~-8~ on the ~icedtea-8~ variable, because I then call for the package... <unmatched-paren>well, you'd need to specify "icedtea@8", because afaik the latest version of icedtea is v17, not v8 <unmatched-paren>tschilptschilp23: are you doing java development with icedtea-8? if so, you might actually want openjdk <tschilptschilp23>Oh, good to know. The openjdk-versions don't install on my setup due to some conflicts, that's why I found icedtea. No, I just needed an jre for a small java-game! <unmatched-paren>tschilptschilp23: i presume you haven't done functional programming before you started using guix? because map is a very common idiom in functional programming <unmatched-paren>basically, what it does is destructure the list into the first item and the rest, then calls the procedure you gave it on the first item, then recursively calls itself on the rest like this (map the-proc-you-gave-it every-item-in-the-list-except-the-first) <tschilptschilp23>the concept strongly reminds me of ~sapply~ in R, but I'm pretty much of a Lisp/scheme noob, yes! <unmatched-paren>if you give it an empty list, though, it doesn't do that (the 'base case'), which allows it to eventually stop recursing <unmatched-paren>(cons foo bar) prepends the item `foo` to the list `bar`, and lisp lists are actually entirely composed of so-called 'cons cells', like this: (cons first-item (cons second-item (cons third-item '()))) <unmatched-paren>so the above `map` call is equivalent to (cons (foo "bar") (cons (foo "baz") '())) *unmatched-paren looks up 'sapply in R' to see why tschilptschilp23 is reminded of it <tschilptschilp23>I guess somehow, yes! Still have to try out if ~home-environment~ is happy with these construtions, I'll make a copy first ^^ <tschilptschilp23>unmatched-paren: one of the ~apply~s (there's a few variants of it, if I recall properly) <unmatched-paren>if you have some foo-<NUMBER> packages, you'll probably need to replace them with "foo@<NUMBER>" <unmatched-paren>but the R one probably is implemented with iteration instead of recursion, which is inherently less beautiful ;) <unmatched-paren>let me put together a haskell one, that would probably make more sense since haskell has better pattern-matching... <tschilptschilp23>thanks, in the meantime bordeaux seems to have ungoogled-chromium ready, so I can check if my refactoring worked ;) <tschilptschilp23>looks good, just that ~icedtea-8~ has to become ~"icedtea@3.19.0"~ or the (right now) equivalent ~"icedtea"~ (which for sure I'm using). Thanks unmatched-paren for taking this stress regarding ~map~ from me ;)! <unmatched-paren>oh, icedtea v3 is the icedtea that's compatible with the official (and at the time proprietary) jdk v8 <unmatched-paren>i guess they used to use different versioning schemes before they effectively merged <tschilptschilp23>well I guess the java program I have here would run with any, but for some reason openjdk did not install for me last friday, that's how this whole icedtea came up here! <unmatched-paren>ugh, this ancient C code i'm trying to refactor uses tons of `extern` statements instead of just using headers... <tschilptschilp23><unmatched-paren> "not sure which one makes how..." <- I guess for me from now on it's guile ;) <unmatched-paren>tschilptschilp23: heh... well, the ocaml and haskell ones are certainly terser, since they have pattern matching built in <tsmish[m]>Mainly useful for people who fork guix monorepo <alethkit>Is home-generic-service still supported, or is it deprecated in favour of home-files-service-type? <AIM[m]><tschilptschilp23> "iamaravindi: I've tried this..." <- Ohh ***sneek_ is now known as sneek
<yewscion>Hi Guix. I'm currently wondering, is there a way to turn off the controls on the web interface in Cuirass? Or at least require authentication before their use? I am running it on a personal server to provide substitutes for a few personal packages, and I'm worried about the possibility of a bad actor coming around and taking my server down with a <nckx>Must be, since this is how ci. works. You could check out Guix's 'maintenance' repository to check it out. <nckx>It uses client certificates. <yewscion>Awesome, thanks, nckx! I wasn't aware such a repository existed. <AIM[m]>Can someone add xidlehook to guix repo? <unmatched-paren>AIM[m]: it's pretty easy to add it to the repo yourself. i'll help you if you wish :) <AIM[m]><unmatched-paren> "AIM: it's pretty easy to add..." <- Please do... <unmatched-paren>you'll probably want to add it to the (gnu packages rust-apps) module; once you have the guix repo, open gnu/packages/rust-apps.scm and scroll to the bottom <attila_lendvai>what is the [m] suffix in IRC nicks? i can't seem to search the answer for this question... <atuin>hi! anyone experiencing problems with ath9k and latest kernels (> 5.16.15)? <atuin>`Qualcomm Atheros AR9462 Wireless Network Adapter` <atuin>but since the upgrade > 5.15.14 it keeps disconnecting (wpa_supplicant) <unmatched-paren>ah, ok, 'Network Adaptor' confused me slightly because you said that it wasn't a dongle :) <atuin>this seems to be the problem <atuin>'The revert is queued for 5.17.2'' <AIM[m]><unmatched-paren> "you'll probably want to add it..." <- Ohh <AIM[m]><unmatched-paren> "AIM: do you have the guix.git..." <- I haven't... So I'll have to do this then... <AIM[m]><attila_lendvai> "what is the [m] suffix in IRC..." <- I'm from Matrix <atuin>unmatched-paren: any doc i can read about how to pin the kernel, i'm fine waiting for it <atuin>waiting for the wip-kernel i mean :D <unmatched-paren>atuin: i can't find a doc, but i had to pin it once, and i was told here on this channel how to do it... <atuin>I can use 5.16.14 until then <unmatched-paren>atuin: i think you might want to search for information on profiles; you'll want to construct a profile that pulls from the last guix with a working linux-libre, then access its linux-libre package, and use that for the (operating-system)'s (kernel) field <vagrantc>5.17 is already available in guix, it's just not the default "linux-libre" <atuin>I'm reading about inferiors now <atuin>the inferiors seems to be related, yes <vagrantc>atuin: i forget the exact invocation ... something *like* (kernel-package linux-libre-5.17) in your operating system definition <vagrantc>unmatched-paren: it was not as of yesterday <atuin>ahhh, then i should see the package definition in a repl <vagrantc>5.17.1 is the most recent, don't know if guix has it yet <vagrantc>you could manually apply the revert patch and build it yourself... <atuin>#<package linux-libre@5.17.1 <atuin>I would avoid if possible to build teh kernel now in this machine :D <atuin>I will try inferiors and keep 5.16.14 untile 5.17.2 is available i guess <attila_lendvai>do the substitute servers build every commit in succession, or do they skip some commits when multiple commits are pushed in a short period of time, and they invalidate the same packages? <attila_lendvai>IOW, are they trying to keep HEAD built in a best effort manner, or are they churning through every commit pushed? <vagrantc>pretty sure it doesn't build every commit pushed <vagrantc>although ... bordeaux might be a bit different <attila_lendvai>hrm. maybe that's why i'm looking at an unjustified number of packages being built locally... <nckx>attila_lendvai: Yes. They poll every n minutes and build whatever new derivations appeared. Not each commit. <attila_lendvai>so, if i catch an inbetween state (e.g. picking an unfortunate base commit for my local forks), then i'll suffer more numberous local rebuilds, right? <nckx> Oh cool, was that an incompetent phish earlier? <nckx>attila_lendvai: That is indeed quite possible. <unmatched-paren>nckx: "phish" <- you mean the guy who pasted a random cloudflare html document on matrix...? <vagrantc>most commits don't introduce a large number of rebuilds, but your luck may vary :) <nckx>I guess? I'm (this is a sad refrain by now) not at a PC. I'm not going to interact with it further. I saw the PHP. That was enough gore. <jgart>unmatched-paren, to the keyring branch <jgart>unmatched-paren, could you send a patch to add your OpenPGP fingerprint to the .guix-authorizations file to the master branch of Guix 'R Us <anadon>unmatched-paren: Are you here by chance? <anadon>Whelp. Almost got the working package I needed. <anadon>unmatched-paren: How do I augment a package to `git submodule update` in order to pull code from linked git repos? <anadon>Otherwise, it looks like `utfcpp` v3 is a trivial cmake package. <anadon>Building from git is failing for me again. `configure.ac:92: error: possibly undefined macro: GUILE_MODULE_AVAILABLE` <lfam>anadon: How are you setting up the build environment? <anadon>lfam: `guix shell --pure guix guile pkg-config` <lfam>In order to set up a development environment, you should use `guix shell --development guix` <lfam>Well, you can also use the older command, `guix environment --pure guix`, which the manual does suggest <lfam>The command that you had tried is not equivalent <anadon>I've been getting distinctly different messages. <anadon>Documentation is split, and what I read here isn't in sync. <lfam>My advice doesn't contradict the documentation <lfam>These two commands will both work: <lfam>`guix environment --pure guix` <Kolev>Does `guix pull` just update package listings, or does it update the actual software too? <lfam>`guix shell --development guix` <lfam>With `guix environment`, you get a development environment by default <lfam>With `guix shell`, you do not get a development environment by default <lfam>Kolev: Just the package listings and Guix command itself <lfam>I know that the opposite behaviour of `guix environment` and `guix shell` is a source of confusion... <anadon>lfam: If you have time, in the `./pre-inst-env` step where I want to test my package, I'm getting the following, whihc looks unrelated -- my change is exclusively in textutils.scm. <lfam>My guess is a mistake in the modified code <lfam>On Git commit 1d62b15dc1f84b (latest), I can successfully do `./pre-inst-env guix build --no-grafts dos2unix` <lfam>That package is from the textutils module <lfam>anadon: I applied your patch and successfully built utfcpp 3.2.1 <lfam>Aurora_v_kosmose: Either gfortran (`guix search gfortran`) or maybe pkg-config? <anadon>lfam: I'm just going to throw it into the ML then. <lfam>anadon: When you use pre-inst-env, you might need to be in the development environment <lfam>I actually just installed the most common dev dependencies into my profile to avoid that, but it still may be necessary <anadon>I thought I was. I'm tired. Work was stressful. <lfam>But anyways, your patch works <lfam>No need to keep banging your head against it :) <anadon>Thing is, after this, I have two Antlr4 sub-packages to work on. <Kolev>Trying to get RDE running on a foreign distro. <anadon>And THEN I can actually work on the side coding project I've been wanting to all along without horrible, horrible hacks. <anadon>I hope there isn't some other thing I did wrong. I want a normal day, without everything I try being deemed wrong or insufficient.