<awb999>perhaps this is related to the symlink tht the artefact has? <awb999> --root=./artefacts/docker-pinkgorilla.tar.gz \ <dftxbs3e>Build succeeded for me with GNU Guix commit: b4c6b9eb83f96b980ee1e3a4e45c5b3cf8c0a5c5 <dftxbs3e>With simply: guix system docker-image file.scm <dftxbs3e>AIUI it would ensure the image does not get garbage collected from the store and creates a symlink to it in some place <lfam>That place will be in /var/guix/gcroots <dftxbs3e>awb999, I don't think all the options you give are useful since you are building an image <dftxbs3e>--share or --network seems only useful for use with "guix system container" <awb999>I thought it modifies the container also <awb999>It is still not building for me with wget <awb999>could it be that there is a conflic between nonfree and free channel? <lf94>Question: how do you store secrets when usin guix deploy? <dftxbs3e>awb999, I also used your exact commit with time-machine and it worked too <dftxbs3e>awb999, try running GNU Guix on another machine? <awb999>could it be it is related to the setup of guix ? <awb999>I have just a few packages in the docker-build, and it takes a long time. (5-10 minutes) Can I track in some way whst is causing me this time? <vagrantc_>it's a bit rough as the substitutes for aarch64 are often out of date so you have to build a lot locally, and it isn't a very fast machine for that <marusich>dftxbs3e, my pleasure! By the way, I just committed the changes you made, to wip-ppc64le. I made minor additions (a comment, and copyright lines); you can see with "git diff" from your own repo, if you're curious. Other than that, it all looked good. You don't need to put things like #f in quotation marks in commit messages, but it seems different people quote things differently in the git logs anyway, so there is little precedent... <sneek>Welcome back marusich, you have 4 messages! <sneek>marusich, dftxbs3e says: the "guix" package failure is weird, certainly looks like a bug in the test suite. It may be because powerpc64le-linux isnt a "supported" one (needs --with-courage) <sneek>marusich, dftxbs3e says: it looks like guile-static-stripped does not work (in the bootstrap binaries), there's an erased glibc reference showing with ldd <sneek>marusich, dftxbs3e says: so efraim built cmake-minimal successfully with the glibc ldd patch, so good news! <marusich>In other words: 1) Make changes to guix.m4 etc. so we "officially" support powerpc64le. 2) Run make update-guix-package (and commit any changes). 3) Run make guix-binary.powerpc64le-linux.tar.xz <marusich>Awesome that we were able to build guix in that way! Hopefully soon we can get the "make guix-binary.powerpc64le-linux.tar.xz" command to work, since I believe that is the standard way a release binary is made. <marusich>I noticed a test failure in Guix, but I haven't investigated it yet. tests/containers.scm, I believe it was. Something about the procedure that should run something in a container, always returning #f. <marusich>Regarding guile-static-stripped, that's unfortunate. Do you have more details? Could you open a bug report? <marusich>vagrantc_, the name "powerpc64le-linux" is the "guix system" name, which is basically an arbitrary string, but by convention in Guix (and Nix, I think) we try to make it sound like the GNU triplet. <marusich>It is not the same as the GNU triplet. I believe the actual triplet used in gnu-build-system builds is generally powerpc64le-unknown-linux-gnu. <marusich>vagrantc_, my understanding is that ultimately the powerpc64le part of the name comes from an arbitrary decision on how to name it in the GNU toolchain, perhaps glibc like you suggest. <marusich>In any case it's the same architecture as for Debian's ppc64le port. Debian's gcc reports "powerpc64le-linux-gnu" for -dumpmachine. <vagrantc_>marusich: ah, it is part of the gnu triplet, it's debian which chose a different name <marusich>They use powerpc64le, but call it ppc64le <marusich>In the code I believe it is not referred to as ppc64le. <marusich>(but I haven't seen Debian's packages so I don't know.) <marusich>The branch on which we are doing this porting work is called wip-ppc64le, so... <marusich>but in guix the name ppc64le is generally not being used. <marusich>we are using the name powerpc64le instead. <vagrantc_>i suspect the maintainers picked a shorter name to type less :) <vagrantc_>keeping in sync with a major toolchain (e.g. gcc) seems reasonable. <marusich>personally, i rather like using the same name as appears at the start of the triplet and the nix system name. <vagrantc_>which, ends up with architectures like aarch64 ... <marusich>but it took me a while to understand that the choice of nix system name is arbitrary, and that we could call it anything, really. So if we ever built a powerpc64 port that used a different abi, I guess we'd have to give it a different name, like ppc64wtf-linux <marusich>I still find the triplets to be a bit confusing, but i have come to learn and accept that many different packages and bits of code are all participating in loose coordination, and that they are not generally referring to some single list of authoritative names. <marusich>i thought at first that these names were defined somewhere clearly <marusich>it seems like that is not true, although I'm sure there are places in glibc or elsewhere that happen to list parts of these names <marusich>they aren't even totally consistent with one another. rust has its own names for some of these things, which is why nix-system->gnu-triplet-for-rust exists i guess <wleslie>is there a resource on search paths somewhere? I want to add a subdirectory in my libc to the cross ld path in my toolchain <awb999>can I redefine a module definition so it would just use another dependency? <awb999>I am trying to compile a module that gets build with java 9 with java 13 <wleslie>there's a function `package-with-c-toolchain` there might be something similar for java <lfam>wleslie: Do you mean search-paths in Guix package definitions? <wleslie>probably I should just figure out how to remove the target triple from the newlib install path <lfam>I do think it's somewhat underdocumented <lfam>Hm... maybe there is a build log there <awb99>I cannot find documentation on how modules that are compiled with java select the java Version. <lf94>Question: how do you store secrets when using guix deploy? <efraim>marusich, dftxbs3e: the glibc powerpc64le patch also fixed building glibc-2.31+ for me on 32-bit powerpc <dftxbs3e>marusich, git rebase was able to detect all patches that you took upstream, wonderful! <dftxbs3e>mothacehe, hello! :-D Thanks a lot for work on Cuirass, it has shown really helpful so far! <dftxbs3e>cbaines, it seems things broke again with narinfo reference undefined errors on powerpc64le-linux workers today <cbaines>hmm, that doesn't sound good. I'm not sure anything has changed recently though? <dftxbs3e>cbaines, powerpc64le-linux workers use GNU Guix master from 14 days ago <dftxbs3e>I can try rebasing on latest master but it's a delicate process git-wise <cbaines>uhh, maybe it would be useful to know what revision of Guix, and what version/commit of the Guix Build Coordinator you're seeing the issue with <dftxbs3e>cbaines, This revision: 85243d0d63e2219d0d376a541fa67efc24e6e2c8 - building guix-build-coordinator package from there <dftxbs3e>all other changes are related to PowerPC <brendyyn>Has anyone tried updating python-sip to 5 or 6? <cbaines>dftxbs3e, OK, so in that revision of Guix, things are broken unfortunately as the guix-build-coordinator doesn't have the code to work with the breaking changes in Guix <dftxbs3e>cbaines, okay! well I'll use package transformations as a workaround I guess! <cbaines>things will be better once there's a testsuite to spot these kinds of problems at package build time <cbaines>although I'm still dreading trying to write a test suite in Guile, I don't get on well with the Guix or Guix Data Service ones... :( <dftxbs3e>Aaaa :-s - Is there a framework or it's just simple Scheme files? <cbaines>but I've found things like running individual tests, and getting backtraces on failure to be an uphill struggle <sneek>Welcome back hapster, you have 1 message! <sneek>hapster, nckx says: hapster: I'm afraid the Nix importer is prone to bitrot, and might require a running & configured nix-service-type to even work. In short it's probably the most temperamental of the mainline importers. <hapster>nckx: thanks, good to know about the nix importer, always thought I was miserably failing at some point ;-) <hapster>when I create a package, there need be a license thing in the beginning (in which I insert "my" copyright). Is there an emacs "M-x guix-" command for this? <efraim>I went down a package upgrade rabbit hole, turns out I'm the last person to touch jrnl, back in march 2016 <efraim>I don't know if that counts as stable or abandoned <pkill9>does anyone know of a wayland compositor that is closer to an emacs interface? basically somethign as close as exwm for wayland *raghavgururajan screams "Hello Guix!" <pinoaffe>pkill9: close to an emacs interface in what respect? <pkill9>basically treating windows as buffers and with a command interface that's extendable <pkill9>and I don't know how, nor have the knowledge necessary to write my own <pinoaffe>you could integrate those with something like dmenu to have a "command prompt" and to eval whatever you input into the command prompt <pkill9>looks like ulubis doesn't use wlroots :/ <pkill9>maybe i should just stick with my simpler sway setup, and create a script that manages windows <pkill9>that would function like the command input in emacs <pkill9>actually you could probably make that as a separate program <pkill9>that creates a bar in wlroots ocmpositors <esper>Hi, I installed Guix System with default installer. Chose my language but now LibreOffice and IceCat menus are still in English. They have dictionaries for my language but menus are still in English so I am confused. <pkill9>and I can write it in guile or common lisp or whatever <esper>Are nonenglish languages in UI supported? <pkill9>esper i don't think the installer changes the lanugage settings of individual programs <esper>That would be even more confusing because we choose locales for the system in installer. <leoprikler>esper: programs should come in translation, e.g. most of the gnome stack is German on my end <esper>Is IceCat and LibreOffice in German? <leoprikler>I haven't checked, but I suppose those programs run their own i18n <esper>So I think IceCat/LibreOffice is not installed with locales or GTK is not configured because ungoogled-chromium is in nonenlish. *pkill9 will make this launcher <esper>So XFCE works but somehow GTK does not pickup language setting? <esper>(Assuming IceCat/Libreoffice is GTK.) <leoprikler>try nautilus for example -- should be in your native language as well <esper>I have plain, default installation so that issue should affect any nonenglish system I think. Am I the first user reporting that? <esper>Let me check and probably install nautilus. <leoprikler>looking at the output of Icecat, I suppose translations really are missing <leoprikler>trying to set another one raises an interesting warning <esper>I dont want Nautilus to mess up my desktop though. Maybe there is better application to check, Evince? <esper>Guix is European so I hoped nonenglish experience is good out of the box. Do French folks use English GUI? ;) <dftxbs3e>I currently lack data, or I don't feel like writing so many commit messages. <leoprikler>the biggest "no export for you" in Guix System is Emacs, sadly ._. <leoprikler>libreoffice seems to build with *some* i18n, but none for its interface? <leoprikler>either way, you're supposed to change it through its own settings, it seems <esper>Evince works, so it must be something specific to Libreoffice and Icecat, the biggest one. <leoprikler>`guix edit icecat` brings you exactly to the package definition <efraim>dftxbs3e: I'm trying to package openconnect-sso, so I managed to get python-pyxdg <esper>(locale (string-drop (basename locale-dir) (+ 32 ; length of hash (string-length "-mozilla-locale-") ok, so maybe there is a bug somewhere there <esper>It is chromium it directly supports Google monopoly. It's ungoogled, but the web keeps optimized for it even when you use it because it is still Chromium. <dftxbs3e>is there a way to run system tests using GNU Guix offload facility you think? <dftxbs3e>seems running: "./pre-inst-env guix build -m etc/system-tests.scm" directly works <dftxbs3e>sneek later tell marusich I would like to try and rebase the branch on master ASAP <cage_>Hi! I am trying using guix for a common lisp software that uses asdf and autotools to build and install the package, i am using gnu-build-system and the process fails the phase when building the executable with sbcl the compiler says that can not find asdf (the CL building system), any idea? <cage_>raghavgururajan, thank you but i already had asdf as native-input, while switching to asdf-build-system breaks the gnu phases for binding, thanks anyway! <cage_> please can you tell me how to do so? <cage_>i started using guix a few days ago :) <dftxbs3e>cage_, try exploring existing packages in GNU Guix repo, I don't know how to do that. <cage_>dftxbs3e, thank you! i tried chacking stumpwm and pgloader, in fact this was very useful to write the package definition file but i am just stuck with this issue that i believe is the last one :) <bdju>where's the torrc file on guix? or how can I specify a specific country code somewhere? <dftxbs3e>bdju, look at the tor-configuration parameter of the tor-service-type <brown121407>How do you guys test a new system service you added somewhere in gnu/services/... ? I'm not having any luck with the -L option for `guix system reconfigure' or doing a reconfigure from ./pre-inst-env, but maybe I'm doing it wrong... <lf94>ryanprior: mailing list time. <ss2>Is anyone having problems with emacs-elpy? It doesn't build here. I'm considering to make a bug report. <cage_>raghavgururajan, thank you i just checking :) <kondor>Yesterday tried building it and it failed <ss2>I had it installed on one machine, then had to remove it after pulling and upgrading. <ss2>I haven't figured why though. <kondor>How to get rid of all the qcow2 images from the store without performing a GC overkill? <dftxbs3e>kondor, list paths of store items that contain qcow2 images using "find" then use guix gc -D <path> for each of them <dftxbs3e>kondor, probably (untested): find /gnu/store -name '*.qcow2' | while read line; do guix gc -D "$line"; done <cage_>(guix build asdf-build-system) has a function that is not exported by the module how can i call it from another module? <leoprikler>cage_: you might get it through @@ but that's dangerous <avalenn>How can I `guix download` a specific commit on some arbitrary git repository? <lf94>Question: should I be expected to memorize how to create packages by memory, or is it reasonable to have to copy a sample from the documentation to start? <kondor>lf94 i always look up sources in guix repo <kondor>finding the closest match to what i want to package <dissoc`>no shame in copying another package to use a template. do that until you can write one without it <lf94>I guess because there are subtleties you'd normally miss? <dissoc`>get familiar with the stages and opening the log to see why a build will fail <yoctocell>Hi, I am trying to build sed from source on a foreign distro (nixos). <yoctocell>The package builds fine, but the test are failing due to some SELinux <yoctocell>I have tried `guix install --disable-test=sed` but it doesn't seem to <lf94>There appears to be no tests specified in the package <lf94>Actually it looks super basic. <lf94>Oh nevermind: "for tests" <lf94>So I guess there are some internal tests which run <lf94>Maybe you can pass an argument to stop them in the package specification. <yoctocell>And did a guix build, but the tests are still run <lf94>Ah yes, something like that should do it <cage_>leoprikler, thanks why dangerous? Because i am using an unexported symbol (so non user API)? <lf94>yoctocell: you're on the right track <ngz>#f (or #false) and #t (or #true) are the booleans <lf94>I suppose f evals to true <ngz>It is an unbound variable, so it should raise an error. <lf94>surprised then they didn't see it <ngz>Ah, no, it's inside a quote <ngz>So yes, it should be 'f <ngz>I mean, it becomes 't (but should really be #f) <ngz>Are you sure this is your package that is being built <yoctocell>I don't see how it would be the correct package, I am specifying the file with --file in `guix build` <lf94>yoctocell: type garbage into the file <lf94>if it doesn't error, surely it's not <ngz>yoctocell: I tried copying your paste above in a file and running guix build --file=... I get an unbound f variable error. <ngz>I know about the typo, but, despite this typo, you didn't encounter the same error as me <ngz>So, something is fishy :) <ngz>When I change t to #t, tests are not run. <kondor>How to log build results (when it's successful). I am running `guix system vm-image ...` <lf94>The documentation literally says #f <kondor>I want to display some diagnostics <ngz>Yes I meant #f sorry. <lf94>yoctocell: maybe outdated guix ? <yoctocell>substitutes aren't working, so I am forced to build from source <ngz>You didn't authorize substitutes <ngz>guix archive --authorize < PREFIX/share/guix/ci.guix.gnu.org.pub per manual <ngz>where PREFIX is the Guix installation prefix. <ngz>Of course, authorizing substitutes is not mandatory. <ngz>Could you paste the build log of you attempt to disable tests somewhere? <yoctocell>When trying to authorize it complains about read-only filesystem (I am on nixos) <ngz>hmmmm, what does return "which guix"? <yoctocell>readlink $(which guix) returns /nix/store/yv88d33achgb66izi9dbh3c96jpfjfbp-guix/bin/guix <ngz>Something is wrong then. <cbaines>guix being in the nix store isn't necessarily wrong <ngz> $HOME/.config/guix/current/bin/guix <cbaines>what's the exact error you get when trying to authorize substitutes? <yoctocell>cbaines: guix archive: error: mkdir: Read-only file system <cbaines>yoctocell, and what's the command you ran? <yoctocell>cbaines: guix archive --authorize < /nix/store/bxmjnpyz3zd101p06wvv6qigxzs0vbcz-guix-1.2.0/share/guix/ci.guix.gnu.org.pub <cbaines>that looks right, are you running it as root? <cbaines>I'd hope it's trying to write to /etc/guix/acl <cbaines>so I'd check if /etc/guix/acl exists <yoctocell>But it still returns the same error with root <cbaines>so, what does /etc/guix/acl look like on your filesystem? ***leoprikler_ is now known as leoprikler
<cbaines>does it exist, and if not, can it be created? <cbaines>OK, and can /etc/ be written to by root? <cbaines>Ok, maybe try creating the /etc/guix directory, and then try running the command again? <cbaines>hmm, I'm not sure what directory guix archive is trying to create... <mdevos>yoctocell: could you run "guix archive ..." under strace? <mdevos>to check where it is trying to create a directory <ss2>kondor: I testet it on a clean user; emacs-elpy can be installed there. <ss2>It seams something else is reventing it to be installed. <yoctocell>mdevos: sorry, what do you mean by "under strace"? <mdevos>Run "strace guix archive --authorize < the-key". Are you familiar with strace? <ngz>I think there is a Nix conspiracy going on <mdevos>it's a tool on Linux that runs a program P and prints information about each syscall P makes <yoctocell>Ok, I ran it with strace and got a lot output. Basically it was trying to write to /nix/store <mdevos>yoctocell: could you run "guix repl", and evaluate (@ (guix config) %config-directory) there? I wonder if nix configures guix incorrectly <mdevos>(btw. apparently the configuration directory can be overriden by setting the GUIX_CONFIGURATION_DIRECTORY environment variable) <yoctocell>It returns $1 = "/nix/store/yw2sys7vwaj3zd3v23bajyh4h896p903-guix-1.2.0/etc/guix" <mdevos>if you wish to investigate further, I would look in the nix definition what configuration flags are passed to configure *mdevos not familiar with nix <mdevos>yoctocell: think I know whats's going on. --sysconfdir defaults to --sysconfigdir=PREFIX/etc, and nix presumably sets --prefix. Maybe add --sysconfdir=/etc to configureFlags in default.nix? <yoctocell>Ok, it is going to take while to compile. I will report back when its done. <wdkrnls>Does anyone use a color printer with Guix? I'm trying to figure out what is a good model for printing photos. <mdevos>wdrknls: I've a colour printer, but I haven't tested it with Guix. Will do now <mdevos>the printer is booting. I also have access to a non-colour printer. In case the colour printer doesn't work, would a non-colour printer be ok? <wdkrnls>For my intended usage I need to print photos. I saw that Ricardo Wurmus was using a Brother laser printer quite successfully and I used to be able to use a Samsung SCX-4200 laser printer with Guix, but that broke down. <wdkrnls>If I were going to get a non-color printer it would probably be the Brother HL-2370. <mdevos>I need to reconfigure the system for some drivers, you'll have to wait a little <bqv>yoctocell: mdevos: I think I did use GUIX_CONFIGURATION_DIRECTORY to override it at runtime, fyi <wdkrnls>I don't want to inconvenience you, mdevos. I appreciate your reply already. <yoctocell>bqv: I set GUIX_CONFIGURATION_DIRECTORY to /etc/guix, but "guix archive --authorize ..." still complains about read-only directory <yoctocell>Sorry, it's dinner time, will come back soon. <bqv>Yeah, thats because 'guix' is a wrapper <bqv>Oh actually, the wrapper just sets the others <mdevos>Any idea how to resolve this: ‘Printer ‘HP-Photosmart-Wireless-B109n-z' requires the '/gnu/store/[snip]-cups-2.3.3/lib/cups/filter/hpcups' program but it is not curently installed. Please install it before using this printer.'? I have added (extensions <mdevos> (list cups-filters escpr hplip brlaser) to cups-service-type <mdevos>the certificate of logs.guix.gnu.org expired today! <yoctocell>mdevos: Compilation failed since it's in a sandboxed envrionment, I should have thought about this earlier... <sneek>Welcome back yoctocell, you have 1 message! <yoctocell>mdevos: I think you meant to send this message to wdkrnls <wdkrnls>so does that mean hpcups isn't supported by guix? <wdkrnls>The HP support page suggests that your b109n printer should have worked out of box with hplip 3.9.10 and above :( <wdkrnls>One thing I'm confused about is "driverless" printers. It seems like it should be possible to use "modern printers" without installing drivers by communicating using a protocol called IPP and that this is supported by CUPS. <wdkrnls>What are the foomatic-filters and should they be included into your extensions list? I was reading that they were used to automatically generate PPD files for some printers. <wdkrnls>I don't know why that would have anything to do with hpcups, though which looks like it has a lot to do with borderless printing which would be essential for printing photos. <wdkrnls>but anyway, thanks again for looking into this mdevos :) <cage_>leoprikler, i see thank you! <bdju>to whoever packaged bpytop: thank you, but where are the themes?! there is only 1 instead of 14 like on my other machines. I thought they were part of the main package. the guix bashtop package also has the themes <lf94>bdju: sometimes package definitions have multiple outputs, maybe it's in another package? <lf94>(Search for bpytop brought up nothing for me!) <lf94>Can someone tell me if this line of thinking is sound? I have a "project" I want to package: it's a wiki. This project just consists of the actual content and the index generator which is a shell script. Would I just use the gnu-build-system? So I would just create a Makefile for my project just to run the index generator? <mroh>bdju: I haven't packaged bpytop (but bashtop). The package doesn't have themes inside, so I think that's a bug. I will try to take a look, if you don't mind, please make a bug report. <lf94>I would then want to "deploy" this project to my VPS - certainly I *wouldnt* use guix deploy for this, but probably a custom channel?... <lf94>(Or maybe something simpler like guix copy IIRC, whatever the command is to install a package on another system which is local) <bdju>mroh: what are you saying exactly? file a bug because the bashtop themes are there and they shouldn't be..? not gonna do that. I have both bashtop and bpytop installed, fyi, so if you didn't package bpytop, someone else did. was a recently added (last few days) package. <bdju>or maybe you're saying in your bashtop you don't see the other themes <bdju>looks like I have 10 themes in bashtop on guix <bdju>I don't think I added them myself <Noisytoot>lf94: If the content is included in the source, you'll have to rebuild every time you change something <lf94>Noisytoot: that's basically the idea. <lf94>Noisytoot: how else would I do it in "guix world"? :) <Noisytoot>lf94: If it's a wiki (designed to be edited) it would have to trigger a rebuild every time someone changes it <lf94>ok it's more like just a hierarchy of files. <lf94>I trigger an index rebuild manually and rsync everything over <lf94>That's my current process <lf94>I want to get away using Ansible. <mroh>bdju: I'm working on a patch. Thank you for reporting! <bdju>still confused about the situation, haha. but sure, you're welcome I guess <dftxbs3e>lfam, hey, the postgresql-13 package contains CVE fixes, so it may be best pushed to master, how to proceed? grafts? <lfam>dftxbs3e: Ah, a good thing to mention :) <dftxbs3e>lfam, I think most postgresql releases contain security fixes in fact <lfam>If the update is ABI compatible, then we can graft it. Otherwise we'll have to cherry-pick the relevant bug fixes and graft them onto the old version <lfam>I think we can consider most software updates to be security updates, at least for significant programs <lfam>But, it's a matter of judgement as to whether we rush to deploy them or not <lfam>But anyways, does my advice about grafting make sense? <dftxbs3e>lfam, how do we check ABI? I think these fixes are not in ABI-sensitive areas, only in the postgresql server software <lfam>Do you know how "big" the update is? Is it easy to review manually? Like, only a few patches? <dftxbs3e>hmm server software has ABI because of plugins right <lfam>Yeah, if they are not part of the postgresql-13 package <lfam>It's probably okay. Are you able to create a patch that uses a graft and run those system tests again? <lfam>The tests should exercise a fair amount of the database server <dftxbs3e>lfam, 303 changed files with 16,658 additions and 11,034 deletions <lfam>Then we'll just have to do our best and cross our fingers. We'll hear if something is not working <dftxbs3e>I think some of it might be 2020 to 2021 copyright markings <lfam>I do think these vulnerabilities are not a huge deal. For both of them, attackers need to be able to use the database in order to exploit them. <lfam>Yes, I would try that, and run the system tests based on the graft <dftxbs3e>lfam, so I create another package then graft? <dftxbs3e>How did the previous upgrade happen? Did it go through core-updates or staging first? <lfam>Based on the number of rebuilds, it qualifies for staging <lfam>The grafting workflow is like this: in a single commit, create a new variable postgresql-13.2 that inherits from postgresql-13 but changes the version and source. Add a replacement field to postgresql-13 that uses postgresql-13.2 <lfam>There isn't a schedule for staging at this point. We just finished the last staging cycle <lfam>I would guess it will be a few months at least. Maybe we'll combine it with core-updates. It kind of depends on the state of the build farm and how many people want to work on it <lfam>The build farm was in a bad state but has improved a lot lately, and the improvements are continuing. So, I would want to wait at least another month to take advantage of continued improvments <dftxbs3e>also we didnt put CVE numbers in commit subject, is that OK or..? <lfam>I always put them in, but it's a matter of taste. Like I said, most updates are really security updates <lfam>It's a good way to scare people into updating ;) <lfam>A graft is a serious thing, so the commit should definitely say why we are using a graft <lfam>If you had mentioned the security fixes, I wouldn't have just pushed the patch to staging and closed the bug :) <dftxbs3e>lfam, okay well I'll try next time, the CVE thing was one click away in my email, I posted link to release page <lfam>I know, but there's a lot of emails in my Guix mailbox. It's important to be explicit <lfam>Tbh, I'm rarely going to click a link to a release announcement unless there's a note saying that I should for some reason <dftxbs3e>lfam, do I define-public the thing I am grafting from? <lfam>Yeah. That way `guix show postgresql` will display the new version <lfam>The recent commit a18492118cc73bee9a2e6424363e3e072572f52e is a good example to compare to <dftxbs3e>lfam, is it possible to re-open the bug? <lfam>Yes. You can send a message to <control@debbugs.gnu.org> that says "reopen $bugnumber" <dftxbs3e>lfam, thanks! sent another patch to the bug <dftxbs3e>lfam, I ran tests again as well, success, still not cuirass though because I don't want to recompile all of GNU Guix, takes a while <lfam>Sure, I can take care of that <dftxbs3e>ah well, I removed the cuirass.go file only and it worked. <dftxbs3e>oops I kept your signed-off line when amending.. <lfam>Rather convenient for me <dftxbs3e>What counts is the commit signature I believe <lfam>Signed-off is just an easily readable note about who committed the patch, but it can say anything. And it's also always there, but hidden, in `git log format=full` <lfam>Signed-off is just a user interface "affordance" for people reading the git log <lfam>I moved the replacement field between the name and version fields. It's just an aesthetic preference I have. That's where it usually goes <bdju>anyone around that's used qmk on guix? I'm having issues building the default keymap for my keyboard. I've only used the web configurator before now so my qmk-related stuff isn't all working right yet, I guess. <bdju>mroh: ah, very cool! thank you <fnstudio>hi, i was able to generate a small guile CLI app; basically a hello world with a autotools setup along the lines of guile-haunt and guile-hall <fnstudio>the dirs where .go and .scm files get saved in need to be adjusted before the package can be installed system wide <fnstudio>(not sure why i linked to that website instead of the official guix channel, but anyway) <fnstudio>i think i understand why the executables need to be wrapped but i'm not sure i follow all the steps in that section and i was wondering if there could be any more standard, slightly simpler way of doing all this <fnstudio>where "all this" = creating a guile library, make it a CLI app, package everything in a autotools project, make it installable via guix <fnstudio>the problem is (if i understand it correctly) that .go files get installed in /usr/local/lib/guile/3.0/site-ccache <fnstudio>and .scm files in /usr/local/lib/guile/3.0 <fnstudio>which, by default, are not in the GUILE_LOAD_COMPILED_PATH and GUILE_LOAD_PATH