IRC channel logs


back to list of logs

<lispmacs>when making a package definition, how to do I pass in additional CFLAGS to the build operation? e.g., where I would normally do "CFLAGS=-wblabla ./configure" if building manually?
<cbaines>Depends on the build system, but there are often arguments to do this kind of thing
<lispmacs>gnu build system
<lispmacs>looks like there is a #:configure-flags argument. A list...?
<lafrenierejm>lispmacs: (arguments `(#:configure-flags (list "CFLAGS=-foo"))) should work.
<lispmacs>lafrenierejm: thx
<leth>Is there a way to add a file to the initramfs image?
<ryanprior>When I write Clojure I often find use cases where the thread macro eg (-> value func1 func2) is more readable than the equivalent (func2 (func1 value)). Do any of yall use a threading macro in Guile? Because I miss it.
<ryanprior>Just submitted my patches to add ruby 2.7 🙌
<lafrenierejm>Why would %standard-phases be unbound in gnu/packages/sqlite.scm?
***catonano_ is now known as catonano
<lafrenierejm>So I can use %standard-phases just fine when defining a package with `package', but not when using `package/inherit'...
<lafrenierejm>Or maybe it's unavailable only when inside `substitute-keyword-arguments'.
<drainful->I've seen a few examples online of running icecat in a guix container along the lines of "guix environment --ad-hoc icecat -CN --expose=/tmp/.X11-unix", but I find that icecat will not load fonts in this case. Is there any particular file I should "--expose" in order to rectify this?
<tho1efx>Should I expect an acknowledgement from debbugs when I submit a patch?
<ryanprior> yes probably in 15-30 minutes if the system is slow, sometimes faster.
<tho1efx>Good to know, thanks again Ryan
<tho1efx>Has there been any work on a PKGBUILD importer?
<raghavgururajan>Hello Guix!
<ryanprior>Hi raghavgururajan!
<raghavgururajan>ryanprior o/
<ryanprior>drainful-: FYI I tried getting Icecat working in a container for the last ~30 minutes and no progress so far X.X
<ryanprior>raghavgururajan: I don't mean to pressure you but since you've brought it up a couple times, here's my mkcert package in progress:
<ryanprior>I wrote down the go deps (1 level deep, some could have transitive deps) as a comment in there
<ryanprior>If you wanna fork my repo and use that as a starting point you're welcome to use that to collab :)
<raghavgururajan>ryanprior No worries. I'll have a look and get back to you :-)
<lafrenierejm>Can anyone help debug ? I'm getting "error: %standard-phases: unbound variable"
<guix-vits>janneke: do you've any instructions for installing Guix with hurd on hardware?
<raghavgururajan>I get configure: error: Compiler GCC >= 4.7 or Clang >= 3.3 is required for C compilation
<raghavgururajan>But I am using gnu-build-system
***amiloradovsky1 is now known as amiloradovsky
<guix-vits>raghav-gururajan: what project it is?
<raghavgururajan>guix-vits webkitgtk
<raghavgururajan>I am packaging a older version of it. 2.4.5a. Which is the last version to support WebKit1.
<guix-vits>raghavgururajan: ("pkg-config" ,pkg-config) ?
<raghavgururajan>Tried that too.
<raghavgururajan>I also tried adding ("gcc" ,gcc)
<wxie>hi, guix
<wxie>I find that the guix 1.1.0 installation package cannot ABORT once you start installation.
<guix-vits>raghav-gururajan: (setenv CC (which gcc)) or such? Alternatively, maybe cmake-build-system will work.
<guix-vits>$(CC) used at least there:
<guix-vits>janneke:, so far; fails.
<janneke>guix-vits: oh my, you're waay ahead of me
<janneke>no, i have no instructions for guix with hurd on hardware, that's pioneering
<janneke>for example, i don't believe we have a file-systems service that works
<guix-vits>anyway, if this modular and work somehow in VM, then, logically..
<raghavgururajan>guix-vits Thanks!
<raghavgururajan>I tried a version without "a" suffix. Now I don't get that error.
<raghavgururajan>But now, | Source/WebCore/css/ | failed: No such file or directory at Source/WebCore/bindings/scripts/ line 90. |
<guix-vits>raghav-gururajan: Is changing version on current webkitgtk definition doesn't work, without "a" suffix (by chance)?
<raghavgururajan>guix-vits I just found out that older versions of webkitgtk has security issues.
<raghavgururajan>No I dropped packaging it.
<devtexa>Has anyone written services for wireguard? I would like to learn by reference.
<dissoc3>devtexa: you could probably take a look at other similar services and use them as a reference
<devtexa>Ok, I've seen some examples, but I still don't know how to write too, if anyone has wireguard examples. Can you show me?
<dissoc3>there was someone here the other day talking about wireguard service. you might want to search the logs
<devtexa>Does abuse restrictions? I wrote a shell script to download all irc logs.
<guix-vits>/query janneke
<devtexa>Looks like there are no restrictions, I'm almost done downloading.
<janneke>guix-vits: i find it encouraging that you're trying new things that are almost "expected" not to work
<janneke>but i'm working to get the most basic version of: "guix system vm-image" done, and merged
<guix-vits>janneke: thanks
<raghavgururajan>Folks! What is error: unknown type name ‘bool’; did you mean ‘_Bool’?
<guix-vits>raghav-gururajan: strange. Isn't 'bool' a built-in type for C, and C++ ?
<raghavgururajan>It is.
<raghavgururajan>The build system is cmake
<guix-vits>FWIW, i'm ran into 'error: EXIT_SUCCESS undeclared', just now. Now i'm update my box, to see if this persist.
<janneke>oh my, store-lift, lower-object
<janneke>are those related?
<janneke>it would be so great if geiser worked for me
*janneke goes to read some code
<janneke>okay, so system-derivation-for-action is already broken
<janneke>yeah, fold-services ...hmm
<raghav-gururajan>guix-vits A different version worked.
<mroh>which package has `tput`?
<iyzsong>mroh: ncurses
<mroh>iyzsong: ty!
<efraim>janneke: I'm looking at creating a qemu-self package for use in creating VMs and such, i take it qemu doesn't support i586-gnu?
<efraim>as an architecture to build qemu on that is
<pinoaffe>is the substitute* macro documented anywhere?
<janneke>efraim: no, i don't think so
<janneke>debian does not package it, anyway
<janneke>and the qemu website is deafening silent about the hurd
<janneke>okay, so how to i ignore "guix system: error: no target of type"
<efraim>you might need to add it somewhere
<efraim>about hurd + qemu, it falls through the configure script to 'unsupported'
<janneke>efraim: that's a nice error
<efraim>I found the code for creating VMs/images to be scattered around build and system
<janneke>i'm arm-deep into that too
*efraim found the github mirror before the official source repo
<janneke>i don't want to add a service, i want to remove services; and continue with an incomplete graph
<NieDzejkob>pinoaffe: it has a docstring, see guix/build/utils.scm
<NieDzejkob>raghav-gururajan: the bool type is only available when <stdbool.h> got included
<olivuser>hello #guix!
<olivuser>when I want to produce a disk-image for another machine, how do I cope with the filesystems form? Because in my current configuration, which is derived from the "profile.scm" produced during the installation with the official image, the filesystems are identified via uuid (which, iirc, is the recommended way of doing things). Now, is it a problem to use the same uuid? If yes, what would be an alternative?
<efraim>I normally use disk labels instead of uuids
<TZander>it doesn't really matter. In both cases your label/uuid will not be globally unique but only machine-local unique. To fstab this doesn't matter.
<TZander>as long as you don't start moving hard drives between machines, it will never have any side-effects
<olivuser>efraim, thanks
<raghav-gururajan>NieDzejkob Thanks!
<efraim>cbaines: do we need libcacard support on qemu-minimal? if not can you add it to the list of removed packages there
<cbaines>efraim, I doubt it, I'd imagine you'd have a graphical interface if you were using a smartcard
<cbaines>I'll add it to the list
***Kimapr_ is now known as Kimapr
<olivuser>is anyone else experiencing problems with custom channels hosted on gitlab? for some reason the configuration I used previously doesnt work anymore. If I 'git pull <gitlab repository>' I seem to be redirected to the signin and nothing happens
<NieDzejkob>olivuser: is that 'git pull' or 'guix pull'? Anyway, consider using an ssh key and repo url
<olivuser>NieDzejkob, well first I had a channels.scm file with said channel, but then guix pull wouldnt work "too many authentication redirects". I have then been advised to try a "git pull" which gave the abovementioned result.
<olivuser>sorry but what do you mean by "using an ssh key and repo url"?
<olivuser>I mean I generally know what an ssh key is, but is it possible (or necessary) to generate such a key in order to access a public gitlab repo?
<cbaines>Does anyone have any thoughts on Ruby versions before I merge ?
<olivuser>efraim, can I ask you something in private chat?
<NieDzejkob>oh, a *public* gitlab repo
<NieDzejkob>I happen to also use a certain gitlab-hosted channel, and guix pull is not complaining for me
<NieDzejkob>maybe you made a typo in the URL?
<NieDzejkob>cbaines: What's the motivation behind the graft?
<raghavgururajan>Hello Guix!
*raghavgururajan added G729 and ZRTP support for Twinkle. (#41046). \o/
<cbaines>NieDzejkob, assuming this relates to ruby, it's grafted to prevent rebuilding lots of packages, which allows merging the change directly in to master
<NieDzejkob>yeah, that's what grafts are for in general, but we usually only use those for urgent updates, I thought?
<TZander>guix (the tool) uses them all the time
<cbaines>well, the 2.5.4 to 2.5.8 releases are mostly related to security fixes
<NieDzejkob>Ah, you might want to include the CVEs in the commit message, then
<PotentialUser-64>hello, does native-inputs also progagate propagated-inputs ?
<sammich>with guix environment --container is there a way to expose specific ports as with docker?
<PotentialUser-64>sammich i believe you'd still be sharing the "host" networking namespace, so i guess it doesn't apply
<PotentialUser-64>i'm trying to remove python from `guix pack` generated tarball, it comes from my understanding due to the `wrap-python3` setting up python as propagated-inputs
<cbaines>sammich, not currently, the only networking option is to use a different network namespace, or not
<PotentialUser-64>could it be an oversight of wrap-python3 ? from my understanding, if a package needs python as input (or as native-input), then its dependers also get it, which i find strange (given how many packages rely on python to build)
<cbaines>PotentialUser-64, I'm not sure I know what "dependers" means?
<cbaines>Are you talking about store items referencing python?
<PotentialUser-64>let's say i have packageA that need python to build, so packageA's native-input contains python, then any package having packageA as input also gets python
<cbaines>I don't think that's the case
<cbaines>python would need to be a propagated input I think for that to be available
<cbaines>I think there are three circumstances: python as a (native) input, but not referenced by the outputs, python used as an (native) input and referenced by the outputs, and python as a propagated input.
<PotentialUser-64>actually, i meaned python-wrapper
<edxsa>How to solve this error?
<PotentialUser-64>that package sets python as propagated-inputs, i'm wondering what is the reasoning there
<cbaines>PotentialUser-64, have you checked Git?
<NieDzejkob>edxsa: `ssh guix describe' -> what's the output?
<cbaines>PotentialUser-64, I just saw that as well, but I think a reason is given in the Git history.
<TZander>PotentialUser-64: in most systems you have dependencies always forward. If B depends on A and C depends on B, it implicitly also depends on A. In Guix this is not automatic. Only inputs that are 'propagated' will do this.
<PotentialUser-64>propagated-inputs only propagate one-level, right?
<TZander>likely it is, unless its also a propagated input.
<cbaines>Going back to guix pack PotentialUser-64, do you know what's using python-wrapper, or python-minimal-wrapper
<cbaines>(going to make some food...)
<edxsa>NieDzejkob, Oh, it reminds me that I may have forgotten to run guix pull on the build user
<cbaines>PotentialUser-64, ok, maybe building vlc with the non-wrapped python would help.
<edxsa>I ran guix pull and it still looks like this:
<NieDzejkob>edxsa: when you actually ssh into the build user and run guix describe in a login shell, is the result any different?
<edxsa>Same as above
<PotentialUser-64>cbaines: good idea i'll try. i've actually been able to build a vlc that doesn't depend on X with quite a lot of package overrides and input rewriting, now python is the next big things i'd like to remove from the finaly product (yeah docker as well here...)
<NieDzejkob>edxsa: my build user has the guix package in the main profile. This is usually a bad idea, but it might be necessary for offloading
<PotentialUser-64>by the way, it there a way to globally disable #:tests ?
<edxsa>I have an issue, ssh build@machine -- guix can only search the content of /usr/bin /bin, for example ~ /.config/guix/current/bin will not search, where should I modify to fix it
<NieDzejkob>is that Guix System, or a foreign distro?
<edxsa>Alpine Linux run Guix
<NieDzejkob>hmm, on my Debian build machine I added `source /etc/profile.d/' at the very top of my .bashrc
<edxsa>I run guix package -r guix and then guix describe ^^^^
<NieDzejkob>hmm, the describe part wasn't actually important, it was just to make sure guix is available from the commandline
<NieDzejkob>but make sure it's in the same profile as guile, such that you can import guix modules from the guile repl
<efraim>is there a way to ungzip a patch as part of a patch input or do I need to do it manually
<edxsa>Ok, I fixed the protocol error. This error was caused by my zsh and there was no way to find the correct guix.
<edxsa>thank you, NieDzejkob
<edxsa>Okay, another error occurred. vvv
<edxsa>My sftp works fine, where can I view this wrong backtrace?
<NieDzejkob>what does `ssh build@machine guix package -I` say?
<edxsa>It shows the packages I installed from guix
<jayspeer>hello #guix! gnu/system/hurd.scm on wip-hurd-vm doesn't seem to be working :/ -- when running "./pre-inst-env guix build -f gnu/system/hurd.scm" I get "gnu/system/hurd.scm:146:2: error: grub-minimal-bootloader: unbound variable". My local branch is up to date. Any ideas why is this happening?
<jojoz[m]>How does one set / what's the alternative to setting the LD_LIBRARY_PATH after installing a package to include a .so produced by that package, such that another package can load it at runtime?
<jojoz[m]>I suppose one would have to make the first package a propagated input of the second to start with, but after that I'm lost.
<edxsa>I think I still have to give up guix offload. I will use it again after it has developed for a while.
<NieDzejkob>edxsa: My point is that it should list guix itself
<NieDzejkob>as well as guile
<cbaines>jojoz[m], what's the context?
<jojoz[m]>cbaines: I'm writing a JIT compiler, and at runtime it needs to load my runtime library, which is provided as a .so.
<cbaines>I'm not very familiar with linking, but Guix generally links against absolute filenames
<cbaines>ldd /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2/lib/ for example
<cbaines>It shows things like: => /gnu/store/zg126cjicrpm2p6zc08ra5vh4ddag7ww-libgc-8.0.4/lib/
<cbaines>What language is your JIT compiler?
<cbaines>(written in I should say)
<jojoz[m]>The compiler is written in Haskell, and the runtime library is written in Rust.
<jojoz[m]>Currently, the .so of the runtime library is loaded by the compiler at runtime with a function that just scans the LD_LIBRARY_PATH for the name.
<jojoz[m]>Can I do something like a pass with sed that patched the name to the absolute path?
<cbaines>So, following the principle of the behaviour of something in the store being fixed at build time
<cbaines>Guix packages often just load the library by the full filename, like this example from guile-sqlite3: (define libsqlite3 (dynamic-link "/gnu/store/807c6g9xqrxdjyhm8wm1r6jjjmc8q4vs-sqlite-3.31.1/lib/libsqlite3"))
<cbaines>I think guile-sqlite3 does this as part of the build, but other Guix package definitions use substitute* to replace the bit of code with a full filename
<cbaines>I'd perhaps try that approach for your Haskell program
<guix-vits>jayspeer: janneke currently working on merging hurd-on-vm
<jojoz[m]>cbaines: I don't see the `dynamic-link` part when I look as guile-sqlite3 in guile.scm in my guix cache
<janneke>jayspeer: oh, oops? i'll have a look
<jojoz[m]>What does `substitute*` do? Where can I read about it in the docs?
<guix-vits>jojoz[m]: substitute* is "a sed analog"
<janneke>jayspeer: i have been working towards: ./pre-inst-env guix system vm-image --target=i586-pc-gnu gnu/system/examples/bare-hurd.tmpl
<jojoz[m]>guix-vits: Ok thanks. I suppose I'll try going with something like that then.
<janneke>i'm afraid i pushed some very work-in-progress commits
<janneke>jayspeer: pushed a typo fix, thanks for reaching out!
<guix-vits>rekado: please, can the linux-libre-4.19 be excluded (on ci.guix) from `gc`?
<guix-vits>rekado_: ^
<cbaines>guix-vits, why do you ask about the garbage collection configuration?
<jayspeer>janneke: I've pulled but I still get the same error. How should I build the image on this branch?
<guix-vits>cbaines: i'm build linux-libre-4.19 for 3 hours, no other reasons.
<civodul>mbakke: i'm reporting a successful system upgrade to core-updates with GNOME and all!
<cbaines>guix-vits, substitutes are provided on a best effort basis, given it seems you didn't get a substitute for it, I'm not sure it's possible to exclude it from garbage collection (as it doesn't exist)
<cbaines>guix-vits, Looking at Cuirass, I believe it hasn't been built yet on
<guix-vits>cbaines: FUUU.jpg :)
<olivuser>hello guix! Has the icecat "numbers not shown" bug resurfaced? Because when it initially came up, it was "font-gnu-unifont" and "font-gnu-freefont" that needed to be installed which seemed to work fine. but now it doesnt work anymore. has anything changed, is anything else required to make it work?
<civodul>olivuser: i haven't experienced it, but perhaps you need to run "fc-cache -fv"?
<olivuser>civodul, thanks, but the problem still persists
<civodul>after restarting icecat?
*guix-vits "weee! 'install phase, finally."
<str1ngs>guix-vits: I have a substitute server if you have something extremely intensive you need built. the public key is in nomads work tree.
<bricewge>How can I get the current Guix version from guix?
<PotentialUser-64>is there any plan or consensus of splitting-off headers from (define-module (thsi packages video)
<PotentialUser-64> #:use-module (guix build-system gnu)
<PotentialUser-64> #:use-module (guix utils)
<PotentialUser-64> #:use-module (guix packages)
<PotentialUser-64> #:use-module (gnu packages fontutils)
<PotentialUser-64> #:use-module (gnu packages gtk)
<bricewge>I need this to infer the location of the guix binary. (gnu machine digital-ocean) is still using 1.0.1
<PotentialUser-71>oh my god.. sorry about that :(
<PotentialUser-71> conflicts with line 348
<str1ngs>bricewge: guix describe is probably the best option
<str1ngs>bricewge: is this for the guix-daemon ?
<bricewge>str1ngs: Will it only return the last stable version? Not like %guix-version?
<bricewge>No guix deploy
<bricewge>Specificaly the infect script for DO's droplet.
<str1ngs>guix deploy uses the first guix instance in PATH. normally you want that to be ~/.config/guix/current/bin/guix
<str1ngs>but I'm not familiar with using this on digital ocean so maybe someone else can help.
<cbaines>PotentialUser-71, don't worry, I think you got kicked after just 6 lines
<cbaines>PotentialUser-71, anyway, regarding #:disallowed-references, it looks like an issue with the package definition to specify #:disallowed-references twice in the arguments
<bricewge>str1ngs: Me neither but I'm trying to fix it
<bricewge>str1ngs: See
<pinoaffe>could someone take a look at v2 of ?
<bricewge>str1ngs: It contains a hard reference to 1.0.1, and I would like to be replaced it by the latest stable version number: 1.1.0 ATM.
<cbaines>bricewge, I'm not sure having it automatically update is necessarily the best option
<cbaines>At least with the whole URL hardcoded, it's not likely to break
<bricewge>cbaines: I think it broke, because the current guix deploy doesn't seems to be compatible with that guix version
<cbaines>bricewge, right, well that could be another different issue, depending on the intended compatability of guix deploy
<bricewge>If it's not to be automated, then where should the information for the release manager to update it manually before the release?
<cbaines>I'm not saying it shouldn't be automated, I'm just unsure
<bricewge>cbaines: I don't know the compatibility of guix deploy, I never managed to used it but oh boy did I tried
<bricewge>There are no test for it too.
<cbaines>The (guix config) module seems to be the place to get %guix-version
<bricewge>Jakob wrote some test but they didn't made it in master and I'm afraid they are stale now
<bricewge>cbaines: I tried before asking and unfortunately it returns a git commit in my case "06fc1a51427f5af0e337e16602cb4920865d54fb".
<guix-vits>str1ngs: thanks
<cbaines>bricewge, hmm, I'm not familiar with the code here. I guess the behaviour might differ between a Guix checkout, the Guix package for Guix, and what guix pull does
<lafrenierejm>Any ideas why is resolving `(which "gcc")` to #f during `guix build`?
<guix-vits>what does it mean: "guix system: error: exception caught while executing 'eval' on service 'root':
<guix-vits>Unrecognized keyword: #:file-creation-mask"
<pinoaffe>no clue, but I had something similar yesterday and rebooting did the trick
<cbaines>lafrenierejm, In that context, which is running before the build
<cbaines>lafrenierejm, in cases like that, I think "CC=gcc" might do the trick
<guix-vits>pinoaffe: ok.
<lafrenierejm>cbaines: "CC=gcc" fixed it. Thanks for always being here to help. :)
<cbaines>You're welcome :)
<bricewge>guix-vits, pinoaffe : I just had it too. Your new shepherd support this new-keyword, but your current one doesn't. Just reboot
<lafrenierejm>cbaines: Would it be at all desirable to use (which "gcc") over "gcc"? If so, how would one go about delaying that evaluation?
<bricewge>guix-vits, pinoaffe : And it'll be fine, I guess. It may be a good idea to report it as a bug
<cbaines>lafrenierejm, Not really, because the $PATH is controlled in the build environment.
<cbaines>lafrenierejm, You can use %build-inputs for things like #:make-flags, which might work in some cases
<guix-vits>bricewge: aha, fresh shepherd on our pasture :)
*raghav-gururajan got wrist pain. Probably, CTS. :-/
<bricewge>guix-vits: It come from this commit 4c0cc7bed3de2c0e2d3a6e95b88693941e839eec
<lafrenierejm>cbaines: Alright. I see some places where that's being used. If it's not significant here, though, I'll just leave as "CC=gcc".
<raghav-gururajan>olivuser Try install font-google-noto. I'd also recommend to have this font installed system-wide. Most GUI applications will fall-back to this font, when specified fonts are not available.
<refpga>Hello, how can I edit /etc/fstab from outside GuixSD and login without it getting overwritten at startup? UUID of my home partition changed and I can't login anymore.
<Guixguy1>Hello all, can someone share a method of getting emacs/quicklisp to see /gnu/store/r7ialnn9ad4hv81d3gq89sp0yq0xvl5q-sdl2-2.0.12/lib/
<Guixguy1>quicklisp can not find it when I use (ql:quickload:sdl2)
<turquoise>Hello everyone, I recently installed guix system and have a issue with hugo. I could not find a package via guix search hugo, so I tried to use the prebuilt binary. The extended binary does not find the needed libraries.
<TZander>turquoise: just last week someone was here stating he started packaging hugo. Not sure if that happened yet.
<refpga>Guixguy1: If you are using cffi then you can set the variable *foreign-library-directories* with the path to the library (maybe your guix profile).
<refpga>Set it in your startup file if you will.
<Guixguy1>Is there an emacs or guix page that can help me with that? I am not familiar with setting paths
<refpga>Guixguy1: emacs has nothing to do with it. You should probably tell us the exact error. Search for documentation for the variable name in CFFI manual, or use a search engine. The path should just be a string, cons a string to the *foreign-library-directories* list.
<Guixguy1>refpga: Thank you
<Guixguy1>refpga: The error is "Unable to load any of the alternatives:
<Guixguy1> ("" "" "libSDL2")
<Guixguy1> [Condition of type CFFI:LOAD-FOREIGN-LIBRARY-ERROR]"
<starcrATI[m]>Guixguy1: Have a look at my answer on a Reddit pist the other day:
<civodul>mbakke: i've added glibc-2.29 to 'locale-libcs' to hopefully reduce the amount of locale discussion when people upgrade
<philipper905>Hello, I've been trying to add a package written in Go (hugo), and I've run into some trouble with dependencies that seem to depend on each other. A specific example is the module requires the module which itself requires
<philipper905>Is there any way to make this work with go-build-system
<rekado_>only 3.3T left on ci.guix.gnu.rg
*rekado_ becomes a bot
<cbaines>rekado_, are you using the 5 day old? test in cleanup-cuirass-roots ?
<cbaines>maybe that could be reduced
<lfam>philipper905: It will present some problems for Guix in general, not just the go-build-system
<lfam>I think you have two options. You can make a union of the source code of the two packages, and then build that. Or, you can try bootstrapping the packages with earlier versions of themselves, that may not yet depend on each other circularly
<jojoz[m]>I get an error, `In procedure mkstemp!: Permission denied`, when trying to `substitute*` in an added build phase. What am I doing wrong?
<lfam>jojoz[m]: It sounds like you don't have permission to do that. What file(s) did you try changing?
<jojoz[m]>Part of the package being built
<lfam>jojoz[m]: You'll need to chmod the file to give yourself permission
<efraim>especially if its a git checkout
<lfam>If you grep for 'chmod' in the packages, you'll find examples
<jojoz[m]>Hmm ok. I see other packages doing `substitute*` in `haskell-apps.scm`, but none doing `chmod`. But I'll look somewhere else.
<lafrenierejm>What module do I need to add to gnu/packages/c.scm to use `substitute*` in that file?
<jojoz[m]>efraim: It's a `file-union` of a bunch of `local-file`
<efraim>there's aso make-file-writable
<Guixguy1>starcrATI[m]: (user-homedir-pathname) <- Does this need to be changed or left as is?
<alextee[m]>lafrenierejm: guix-utils iirc
<lafrenierejm>alextee[m]: No luck. :/
<lafrenierejm>alextee[m]: Though that does indeed seem to be where it's defined...
<alextee[m]>#:use-module (guix utils) ?
<lafrenierejm>alextee[m]: Yeah, that's what I'm doing.
<jojoz[m]>lfam, efraim: make-file-writable just produces a permission error as well
<lfam>jojoz[m]: I recommend using chmod
<lfam>You might also check the file ownership
<lafrenierejm>alextee[m]: Though my build output also has "warning: possibly unbound variable `%outputs'", so that might be what's causing the issue.
<lfam>jojoz[m]: Also, make sure you are using the correct path / filename. "Permission denied" might mean you aren't
<jojoz[m]>lfam: Same error with chmod
<jojoz[m]>It's a relative, path, just like all other examples I've seen of `substitute*` are using
<lfam>Okay. What are the permissions of the file? And who owns it?
<lfam>Oh wait
<lfam>"other examples of `substitute*`...
<lfam>Have you successfully substituted anything in your package definition yet?
<jojoz[m]>This is the only occasion I've tried
<lfam>It's possible you are using the wrong filename. Try doing `ls` or `pwd` in your package to make sure
<lfam>You'll get "Permission denied" for all sorts of wacky things in Linux
<jojoz[m]>What do you mean?
<jojoz[m]>I can build the package without my custom patch phase, but the result is not quite correct
<lfam>It can cover up other issues, like the file not existing
<lfam>Just, make sure you are using the right filename
<lfam>If you've done that, and it still doesn't work, check what the permissions actually are
<jojoz[m]>In my local tree? It's `-rw-r--r-- 1 jojo users 7046 May 3 18:37 src/Compile.hs`
<jojoz[m]>In the store it's all owned by root and just r r r
<lfam>In the build environment
<starcrATI[m]>Guixguy1: as is, but change your username in the path string
<lfam>jojoz[m]: In your package definition, before your substitute line, add (invoke "ls" "-la" "/path/to/the/file")
<jojoz[m]>lfam: It prints `-r--r--r-- 2 0 0 7047 Jan 1 1970 src/Compile.hs`
<lfam>jojoz[m]: It's weird that it doesn't show the names of the users that own the file
<lfam>How did you install Guix?
<Guixguy1>starcrATI[m]: I have it like this :(let ((guix-lib-dir (merge-pathnames "/home/guix/.guix-profile/lib/"(user-homedir-pathname))))
<anadon>I'm getting back to my django overhaul and getting individual packages to work and then submit patches for. I've run into the following, and I don't see a hint as to where the actual error is --
<jojoz[m]>lfam: With the install script in the manual
<lfam>jojoz[m]: Check that the build users were created with `grep guixbuild /etc/passwd`. And make sure guix-daemon is running as root
<jojoz[m]>I suspect it has something to do with `local-file`. I'll try uploading to github and see what happens when the source is a git reference.
*jojoz[m] sent a long message: < >
<jojoz[m]>I believe the daemon is running as root, but I'm not sure how to tell
<anadon>Here's the diff I'm working with:
<ryanprior><philipper905 "Hello, I've been trying to add a"> I'm also working on a Hugo package, want right team up on this?
<lfam>jojoz[m]: What OS are you using?
<jojoz[m]>lfam: Arch
<lfam>jojoz[m]: Also, you should add to your package definition this line: (invoke "cat" "/etc/passwd") and make sure it shows the nixbld user. Yes, nixbld
<lfam>jojoz[m]: Can you share the file '/etc/systemd/system/guix-daemon.service' from your OS?
<jojoz[m]>lfam: It does show `nixbld:x:972:972:Nix build user:/:/noshell`
<lfam>Alright, it's fishy that it doesn't match the ownership of the file in question
*jojoz[m] sent a long message: < >
<lfam>Maybe it's a bug in local-file, I don't know
<lfam>I can't stay and help debug it but something isn't right
<lfam>Either somebody will help you here, or please send a message to <>
<anadon>I've simplified the problem setup to the following --
<anadon>There has to be something obvious I'm missing here.
<jojoz[m]>lfam: Ok, thanks for your help
<lfam>anadon: You need to install guile-gcrypt
<anadon>lfam Isn't that handled by `guix environment guix` or the like?
<lfam>anadon: I don't know if it's supposed to be but, in this case, it isn't
<lfam>anadon: Can you file a bug by sending a message to <>?
<anadon>lfam: Sure, one second here.
<anadon>lfam: Sent. It bugs me that I still can't really debug in this system. Errors are so opaque.
<jojoz[m]>lfam: Fyi, I tried with a git origin now, and it works. No permission errors, and the patch applied as expected (I have made other errors though, but completely unrelated to this issue).
<starcrATI[m]>Guixguy1: Just copy it as it is in my post and exchange "your_username" with your username ... thats all you have to do :D
<katco>if i'm using guix on an alien distro, what's the idiomatic way to install/use shepherd services from guix?
<lafrenierejm>I'm getting an error "guix/import/snix.scm:191:9: Throw to key `parser-error' with args `(#<input: #{read pipe}# 16> "XML [22], unexpected EOF")'" when running `guix import nix` on latest master. Can anyone else check whether they're getting the same?
<janneke>jayspeer: weird, i'm pretty sure that worked for me; i'm validating that right now
<janneke>jayspeer: can you try 4 commits down: 2ecc9a525e159e89a68945e00ab9c4334aa14a37; the commit message has some instructions
<pkill9>katco: i don't think there is any
<pkill9>katco: you can run shepherd as a user though
<Guixguy1>starcrATI[m]: Still no go. Thank you for your help though. I am going to look into Chickadee.
<janneke>jayspeer: further down starts the migration from guix build -f gnu/system/hurd.scm to the new "guix system ..." setup, around this commit: 8d01114f22 * DRAFT system: examples: Add bare-hurd.tmpl.
<janneke>(see commit message)
<katco>pkill9: yeah, i have been successfully doing that with services i have defined
<katco>i found a recommendation to do a `(use-modules (gnu services foo))` at the top of `${XDG_CONFIG}/shepherd/`. would that work to load guix-defined services?
<janneke>i am thinking to reset this branch to rebuild it later
<janneke>jayspeer: grub-minimal-bootloader is defined in gnu/bootloader/grub.scm; not sure what's going on
<anadon>I must be going mad
<anadon>On origin/master, this is happening:
<reepca>ya sure there weren't any merge conflicts when you pulled?
<anadon>I just checked again, and a `git stash pop` which said failed apparently still made changes.
<anadon>A few more minutes and then I'll need to walk away from this for a bit.
<bricewge>Who successfully use “guix deploy“?
<bricewge>I can't manage to get it working, it keep hanging at “sending 0 store items (0 MiB) to $myip”
<civodul>bricewge: i do!
<civodul>does netstat or strace or whatever gives clues about what's going on?
<bricewge>civodul: I didn't tried but this process is using most of the CPU and kep runing after kill guix deploy
<civodul>403 for me, could you try for instance?
<TZander>its http, not https. Works here
<civodul>(over Tor)
<sirmacik>hm, guix reconfigure tells me that /dev/mapper/cryptroot is not found :o
<sirmacik>in fact there is no /dev/mapper/cryptroot on my currently booted guix system
<bricewge>civodul: Here is the process
<bricewge>The strace is too big for
<sirmacik>that error fixed itself after reboot o.O
<bricewge>civodul: The end of the strace, it hangs on poll
<civodul>bricewge: so that's on the target machine right? did you try running that command by hand?
<civodul>conversely this strace is that of "guix deploy", right?
<bricewge>Yes the process is on the target and the strace from deploy
<civodul>did you try running that process by hand on the target machine?
<civodul>just to see if there's something obviously wrong, like a load path issue
<bricewge>I get syntax error near unexpected token `('
<bricewge>From bash
<bricewge>SIngle quoting the all which is following “-c” get it running, but it hangs there
<bricewge>Starting “guix deploy“ after the command don't change anything
<bricewge>The full strace
<bricewge>civodul: I don't know what to do with netstat though. Seems that I have 2 ssh connection open, ssh and guix deploy?
<ryanprior>How do you find out what packages would get upgraded if you ran `guix package -u`
<bricewge>Looking around in maintenance.git my machine is similar, except “simple-service 'guile-load-path-in-global-env” and “PermitRootLogin yes“
<vagrantc>ryanprior: --dry-run ... although it's not great at guessing
<ryanprior>No kidding. `guix package -un` did nothing; `guix package -u` upgraded Emacs.
<vagrantc>don't know why there are discrepancies
<cbaines>I'm still struggling with how exactly to represent the data, but this is a product of this afternoon
<bricewge>cbaines: That's nice!
<ryanprior>y'all know if anybody has tried packaging .NET core in Guix?
<ryanprior>I don't see any .NET stuff in here, and I wonder if it's because of low interest or if there's a blocking issue?
<sammich>theres discussion about .net core here, i dont now if its status has changed
<ryanprior>Okay yeah I'll have to look into the bootstrapping issue.
<civodul>bricewge: so apparently it's the code on the target machine that hangs, so that's the one we should trace
<bricewge>civodul: How can I do that? Just run the command from the shell?
<bricewge>In the mean time I tried deploying from root and setting the environment like in maintenance,git but to no avail.
<anadon>Back from walking away from this. Contrary to the manual, a successfully built guix has `./pre-inst-env guix` fail due to missing package "guile-gcrypt". Am I missing something?
<bricewge>civodul: BTW that process is spwaned 4 times (the machine has 4 cores), here is the fulll ps
<cbaines>anadon, if you run guile and try something like (use-modules (gcrypt hash)), does that work?
<anadon>Guile is not in my base environment. I'm trying to keep very closely to the instructions since every time I venture from them I get lost in the proverbial woods.
<bricewge>anadon: “guix environment --ad-hoc guix -- ./pre-inst-env guix” should work, if you already have guix in some form
<anadon>ERROR: In procedure scm-error:no code for module (gcrypt hash)
<cbaines>anadon, just to check, which instructions are you closely following?
<rekado_>anadon: do you have something in your ~/.bashrc that would override variables set by guix environment?
<cbaines>So that says to run guix environment guix --pure to get a new shell
<bricewge>anadon: Without --ad-hoc, sorry
<cbaines>That shell should have guile and guile-gcrypt available
<bricewge>anadon: “guix environment -- ./pre-inst-env guix”
<bricewge>anadon: “guix environment guix -- ./pre-inst-env guix”
<bricewge>It's too late for me to do something productive...
*rekado_ builds icedove after replacing all visible mentions of “Thunderbird”
<anadon>bricewge: cbaines: the latter suggestion with guix env guix go further, then at the daemon it got a connection refused. Am I missing a `./configure` argument?
<cbaines>I'm not sure what you mean by "then at the daemon"
<cbaines>did guix environment guix --pure work, as in give you a shell?
<bricewge>anadon: Yes probably “--localstatedir=/var”
<cbaines>or was it a command you ran in that shell that didn't work?
<anadon>cbaines: "guix build: error: failed to connect to `/usr/local/var/guix/daemon-socket/socket': Connection refused"
<cbaines>Ah, right, then as bricewge said, this bit of the documentation is probably applicable: Then, run ./configure as usual. Make sure to pass --localstatedir=directory where directory is the localstatedir value used by your current installation (see The Store, for information about this). We recommend to use the value /var.
<jonsger>rekado_: nicre
<anadon>cbaines: It keeps getting me that it isn't a default or a fail because of missing argument.
<cbaines>are you having problems running ./configure --localstatedir=/var ?
<anadon> No, it ran. But that it is not a default or fail is counter-intuitive.
<cbaines>Ah, right, I understand
<anadon>For all I like about guix, the initiation is one of the harshest for any piece of software I
<anadon>I've come across.
<ecbrown>when i use the iptables rules in the guix manual, it seems that outbound is blocked. seems like that configuration should allow outbound
<ecbrown>i'm not an iptables expert, so i thought i'd ask if anyone could confirm
<cbaines>anadon, unfortunately improving the setup is mostly a lot of comprimises. I'm not saying it can't get better, just that it's not straight forward.
<rekado_>anadon: the localstatedir argument is not mandatory. All GNU software defaults to /usr/local for the prefix, and localstatedir is defined in terms of the prefix.
<rekado_>it’s a gotcha, but the manual does mention it. Perhaps it can be made clearer?
<rekado_>jonsger: 18m for building icedove. These new servers are neat.
<jonsger>heh :)
*rekado_ sends the final™ version of the icedove patch to
<anadon>rekado_: Then I would suggest having the provided install script use that default directory.
<bricewge>rekado_: Having it as a code example instead of in a textual paragraph would probably help.
<rekado_>anadon: the installer script does the right thing. But for setting up a build environment we don’t use the installer script.
<rekado_>bricewge: yes, that’s a good idea
<anadon>I try to keep to the manual, and I think I make a greater effort than most of the computing world does. But having a "it is technically somewhere in the manual" isn't enough for most. It needs to be somehow more intuitive.
*janneke reproduces Value out of range 0 to 4294967295: -1 in the hurd
<cbaines>maybe it would be useful to have a "installer" for local development
<anadon>I just want all the installers and builders to be consistent, really.
<bricewge>civodul: I straced the process on the target
<bricewge>There is definitely an issue with futex. BTW this process and it childs eat 100% cpu over 400% doing nothing.
<rekado_>anadon: sadly, we chose to not override localstatedir for consistency with the rest of GNU
<rekado_>it’s not an oversight
***pretzel_ is now known as pretzel
<ryanprior>I've been considering whether, because of its approach, guix is perhaps a lower level tool then what's useful for many users and a more opinionated, task oriented tool that manages guix and provides an interface to it could gain traction.