<Guest42>guix pull: error: some substitutes for the outputs of derivation `/gnu/store/mvf88n2v90jjxg9n8b315p22r6jrkbyb-libx11-1.6.A.drv' failed (usually happens due to networking issues); try `--fallback' to build derivation from source
<Guest42>guix/ui.scm:2117:12: In procedure run-guix-command:
<daviid>flatwhatson: how about commenting what you have (temporarily) - related to launching the xserverimean - and taking exactly those lines of g-golf package, which differs in a number of ways ... and do not add +extension GLX ? not sure
<daviid>flatwhatson: also, double check with guix gtk-3 with that respect, because very likely gtk-3 also needs a server ...
<daviid>very likely gdk-3/gtk-3 also need a server for their test-suite ...
<flatwhatson>good thinking! firing off a gtk3 build now as a "control" case
<bricewge>soheilkhanalipur: If it's PPPOE connection was working before, your friend could rollback to a previous working system "guix system list-generation" and "guix system switch-generation $generation-id"
<florosGPL>hello, I installed nginx with guix. The binary is looking under /gnu/store/.../nginx/ for the log directory and the config files. That directory is read only and I can't find anywhere an option to point nginx to a different log directory and configuration file
<leoprikler>are you using Guix System? In that case, there's an nginx-service-type
<leoprikler>if not, you'll have to fake what it does on your foreign distro
<florosGPL>I am using Guix on some embedded board running Yocto. The problem is that I can't give nginx the config file
<leoprikler>why not? nginx has a "-c" switch as far as I can see
<florosGPL>I might've missed that. checking it right now
<muradm>leoprikler: looks too complex, i use only 2 packages from guix, rest come with straight.el, which are mu (with mu4e) and pdftools, basically it is not critical to have them precompiled, and these come from gnu-build-system, not emacs-build-system
<florosGPL>I fixed the error with nginx, I copied everything to a different folder and set -p pointing to the new "share" folder. nginx runs flawlessly, but it can't run with guix under any circumstances due to the read-only filesystem
<muradm>faltwatson: native-compile-target-directory didn't work, still same, looking closer to its explanation it is not for deffered compilation
<muradm>so basically now as far as i understand it just tries to write .eln next to .elc
<clone>Is there a way to download additional files in a package definition? I'm trying to package a program with a set of patches but some of the patches rely on additional source files. I can add patches to the definition's source, but i don't see anyway to add the source files
<flatwhatson>muradm: right, that is where async native compilation will try write files when doing "deferred" compilation (regardless of source location)
<muradm>flatwatson: this error: /home/muradm/.cache/guix-extra-profiles/desktop/share/emacs/site-lisp/mu4e.el: Error: File error Opening output file
<muradm>might be something else to do with mu4e it self
<muradm>i checked other things from site-lisp getting loaded, some of them are compiled correctly
<flatwhatson>yes, i think so, try triggering it after M-x toggle-debug-on-error
<ngz>clone: package inputs can include full (origin ...) sexp.
<muradm>flatwatson: toggle-debug-on-error does nothing for it
<soheilkhanalipur>leoprikler: I do not know how to work with ethtool. Please help me. What command should I enter?
<thorwil>does ardour as packaged in guix support VST3? i see nothing in the packaged definition that would explicitly enable or disable that. Preferences have a VST page, but so far no luck getting a VST plugin to work.
<muradm>soheilkhanalipur: what do you want ethtool for?
<apteryx>civodul: hello! Is it possible to use the returned value of gexp->derivation as the input of another gexp?
<apteryx>As part of the debian-archive generator, I'd like to simply call self-contained-tarball, then gexp-unquote its result into the builder, but that currently gives a gexp-input error.
<civodul>apteryx: no, gexp->derivation is a monadic procedure, so you can't do that
<civodul>however, you can use computed-file, which is the non-monadic equivalent
<apteryx>In the G-Expression section of the manual, it says: "When a high-level object such as a package or derivation is unquoted inside a gexp, the result is as if its output file name had been introduced." Is the output of gexp->derivation not the same kind of derivation mentioned there?
<apteryx>could I rewrite self-contained-tarball in terms of computed-file, so that it can be composed into other g-exps (e.g., the builder of debian-archive)? Would that entail to adjust something else in the (guix scripts pack) code?
<apteryx>hmm, probably easier to factorize out the builder from self-contained-tarball and reuse just that bit
<apteryx>do we still have tar versions that do not support --sort in our bootstrap binaries?
<efraim>yes. it spits out a warning and continues on
<tschilptschilp23>Hi! I'm rather new to writing package definition, and do have problems debugging. The package I'm just trying to define is a C-library for number theory (http://flintlib.org) that I see my collegues using on Debian and CentOS. If I enter an environment with gcc-toolchain, gmp and mpfr it compiles just fine. But once I go with writing definitions things fail at configuration phase. The program just answers with the configure --help
<tschilptschilp23>output. I think it can't really take the default configure-flags passed by gnu-build-system, because out of the ones passed there's certainly not a single one available in the program's configure-script. I already understood, how to ~add~ flags to the default one, but I would't find anything to remove the default ones (and kind of badly feel, that this is not the masterplan). Am I missing something, or does this tell me to go with
<dstolfa>solene: (define-module (gnu packages networking) ...) for example
<dstolfa>so all the things in there that are marked as (define-public ...) should already be accessible
<dstolfa>it's just that i'm not 100% sure how to write the guile code to actually list everything out
<dstolfa>tschilptschilp23: might be worth sharing your package definition so others can see it maybe?
<mbakke>tschilptschilp23: that problem is common with "hand-written" configure scripts that bail on unknown flags ... you have to override the 'configure' phase to only pass your #:configure-flags, i.e. (replace 'configure (lambda* configure-flags #:allow-other-keys) (apply invoke "./configure" configure-flags)))
<tschilptschilp23>dstolfa: this code is from yesterday or so, I just understood by today, that for my needs ```use-modules``` (instead of defining the whole flintlib module) and ```package flintlib``` (without defining it public) would be smarter and less complex. Also quite some of the ```#:use-module``` parts are superflous yet!
<dstolfa>tschilptschilp23: outside of what mbakke said, one minor nitpick would be that it doesn't need the "maintained by..." in the description :). looking forward to it building & working!
<ngz>efraim: Yes, I grabbed the file from guix build -K (regular build fails, obviously). This is were I saw the Cargo.toml to patch. But apparently, my patch-fu is weak, because the patch I generated isn't accepted. If you have a few minutes to share, I'd like to know what you remember about that process.
<apteryx>oh, progress: /gnu/store/qq8kvlmbi7v2r9m3fdzd5sigmc4maign-deb-pack.deb: Debian binary package (format 2.0), with control.tar.gz, data compression gz/
<apteryx>installation failed because: package architecture () does not match system (i386). Probably the magic value in the ar archive mentioned in 'man deb'
<dstolfa>well it's not all that terrible (it's a result of freebsd moving from svn to git), but i'll spare you the details :D
<iskarian>ah, efraim: would you be interested in reviewing my gccgo patches, since you were involved in this before?
<tricon>Are there any known libre Bluetooth 5.0 adapters?
<nckx>dstolfa: Orly? It's been too long since I've used FreeBSD.
<nckx>This wasn't something many users were expected to do, surely?
<dstolfa>nckx: the user transition was relatively straightforward, the tools just switched to git from svn and continued working as usual. however, we've forked the original github `master` branch that was a mirror back in 2015 or so and continued working on it quite extensively. after the migration to git happened, `master` was frozen and a new branch `main` was created which had completely different hashes
<dstolfa>so in order to merge the new code, i had to deal with reconciling old hashes on a fork from `master` and new hashes from `main`. the reason a force push was needed IIRC is because something in the mirroring didn't preserve a couple of important things on the freebsd repo, so a fully new conversion was needed