<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>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>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 :)
<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
<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
<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?
<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!
<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.
<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
<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?
<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
<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)...
<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
<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
<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...
<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>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)
<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") '()))
<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 ~"email@example.com"~ or the (right now) equivalent ~"icedtea"~ (which for sure I'm using). Thanks unmatched-paren for taking this stress regarding ~map~ from me ;)!
<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
<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
<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?