<dongcarl>Question: What would happen if I'm on a machine with no subversion derivations built, then do `guix build --no-substitutes --sources=transitive <package-with-subversion-source>`? Would that fail? <lispmacs[work]>okay, thanks. somebody must have been working on the build problem in these last few days <mbakke>dongcarl: it would try to build subversion locally <dongcarl>mbakke: Okay so it'll build subversion locally then use it to get the source of package-with-subversion-source? <mbakke>np :-) I haven't actually tried with --sources=transitive, but don't see why it would make a difference. <maxxcan>leoprikler: ok, I'll go to sleep. It's late here. I'll tell you tomorrow <jgart[m]>I think I will use Mobilizon going forward <cbaines>the system test for the Guix Data Service literally specifically changes the PostgreSQL configuration, because the service won't work with the current default configuration :( <cbaines>so now I'm running in to that issue on real systems <cbaines>why have a test if it doesn't catch issues? <rekado>maxxcan[m]: pigx just got a fix in <rekado>I already told my colleagues who maintain the two affected workflows (rnaseq and scrnaseq) <rekado>so all you need to do is run “guix pull” and then “guix install pigx” again <lfam>This is partially my fault <lfam>I noticed issues with this while working on staging, but I only papered over them <alextee[m]>are font dependencies? supposed to be propagated inputs? <pkill9>i think font dependencies just aren't added <pkill9>considering how many times people complain about icecat breaking, and it's because they need to install a font i think <leoprikler>if the application needs a particular font for reasons, then a font can be added <leoprikler>but for icecat in particular any font will do, which is why users are left with a choice ***ornxka_ is now known as ornxka
<ryanprior>I haven't had the issue recently where I go for days with no substitutes for some of my packages. <ryanprior>It used to be regular but in the last couple months I don't thin I've waited longer than a day, and usually when I pull all my substitutes are available immediately. ***Aurora_iz_kosmos is now known as Aurora_v_kosmose
***iyzsong-- is now known as iyzsong-w
<brown121407>Hi! Is there an easy way to respond to a thread from the mailing lists? When I click the "Reply via email to $NAME" it only fills in the address of the person who sent the mail, but not the thread address, which I'm more interested in. ***apteryx is now known as Guest40730
***apteryx_1 is now known as apteryx
<brown121407>It seems that the reply link I was searching for was on issues.guix.gnu.org. <sipa>seems that bootstrap build fails on zfs if you have utf8only=on, which seems the default on ubuntu <sipa>hmm, maybe only an older version <jlicht>the cuirass rss feed is a wonderful feature \o/ *mothacehe is fighting a Cuirass memory corruption with valgrind, fun. <allana>Hi guix! question, is anyone having certificate authority issues when dealing with microsoft sites? I upgraded my guix system yesterday and now I can't access microsoft services due to certificate issues. <allana>actually it seems like cert issues all over the net -- hmmm -- did anyhting change related ot how certs are handled in guix over the past week or so? I upgrade every week. <leoprikler>assuming you have the nss-certs installed on your system like any upstanding citizen, things *should* be fine <allana>leoprikler: thanks. I do have nss-certs and have been using this machine daily for years. I update at least once a week. Going to do some digging :-) <leoprikler>allana: the latest release seems to be 3.62 while we're stuck on 3.59 <leoprikler>can you check whether using 3.62 fixes the issue for you? <allana>I think that I have something else going on. Thanks for the help leoprikler . <leoprikler>for the record, it has 581 dependencies, so chances are it's alredy fixed on staging and we just don't have it yet <civodul>BTW, what about adding the last 10 lines of the build log to notification emails? (for build failures) <mothacehe>hey! I'm fighting a memory corruption on the "remote-server" so the CI health is not optimal right now. <mothacehe>the empty logs are caused by cuirass restarts I guess <mothacehe>I'm not sure, maybe it has always been there and it caused the integer overflows we observed. <leoprikler>"last 10 lines" is only helpful sometimes, particularly when the issue is in Guix itself <leoprikler>stuff that fails inside cmake-build-system for example has early compile errors that will be ignored until linking <civodul>mothacehe: IME, rr ("guix install rr") is super helpful when tracking down such issues <civodul>you would run that Guile process under "rr record -n" <civodul>and then do "rr replay", which allows you to replay the whole execution, including reverse stepping <pkill9>how do i ssh into a virtual machine managed with virt-manager? <pkill9>also to access it via port 80 for http <rekado_>civodul: this is a great reminder to try rr <rekado_>I’ll use it to see if I can track down the crash in guile-xapian <mothacehe>civodul: rr doesn't play nicely with Zen CPUs :( <mothacehe>"On Zen CPUs, rr will not work reliably unless you disable the hardware SpecLockMap optimization." <pkill9>or how do i just do it on commandline ***lovetolearn is now known as ltl2
<ltl2>hello, how do i get the iso out of a iso.xz file? <yoctocell>Running `xz --decompress iso.xz` should do the job <apteryx>suppose we'd have a library in Guix built statically; could it be used to build a package on a foreign distro, mixing in the foreign toolchain? <rekado_>in preparing the source code it copies things around in unexpected ways <rekado_>would someone here like to assist me? <pkill9>that looks really useful rekado_ <pkill9>I was looking into tag-based filesystems a while back <apteryx>rekado_: I've been educating myself about the Go build system so that I can better tackle the Docker update; perhaps we can share knowledge <pkill9>everything needs to be abstracted to a file system <atom`>Also, is there any ETA for Go 1.15 or 1.16? <apteryx>rekado_: that package looks like a 'legacy' GOPATH package (not a go module, e.g. lacking a go.mod file), so I reckon our build system should have no problem with it <ngz>atom`: I think you need to provide a nftables-configuration object with a ruleset property. E.g., (service nftables-service-type (nftables-configuration (ruleset (file "...whatever...")))) <rekado_>the problem I have is that it aborts right away because it doesn’t find any source files <rekado_>I tried providing import-path and unpack-path in different combinations, but I’m not sure what the semantics are <ngz>err plain-file not file <ngz>so... (service nftables-service-type (nftables-configuration (ruleset (plain-file "...whatever...")))) <atom`>ngz: Yes but I would like to modify the "content" field of %default-nftables-ruleset rather than create a new configuration "from scratch" (I was planning to just mash some strings into the middle of it). Would this not be possible? <pkill9>i like how you can create queries by making a directory using the name of the query <ngz>atom`: Ah. I misunderstood your request. You could simply copy copy the contents of %default-nftables-ruleset in your plain-file declaration. There might be a smarter solution, tho. <atom`>ngz: Which commands can be used to retrieve the contents of the contents field from the ruleset? I'm not experienced with Guile. <ngz>You can look at the source, or from a terminal, call guix repl, then (use-modules (gnu services networking)) and finally %default-nftables-ruleset <atom`>Ahh sorry if I was not clear. I would like to copy the text in the "content" field programatically (such that if it changes in the future, my code is still applicable), then modify that string by adding a few rules (text to the string), then create a new plain-file object with this updated string, which is used as the ruleset for the nftables-configuration. From a G-expr "object", how can I retrieve only the "content" field? Is there a <atom`>"get" function of some sort that is applicable? <ngz>atom`: I don't know, sorry. <atom`>ngz: No problem. Thanks for your tips! <apteryx>rekado_: hm that paster made life harder :-) (no raw view?) <apteryx>their makefile does: go build -o bin/tmsu github.com/oniony/TMSU <apteryx>rekado_: go-sqlite3 and go-fuse will need to be added first, unless I'm missing something <apteryx>you could try building in /tmp manually at first to get the hang of it <rekado_>the problem happens well before it can complain about missing dependencies <rekado_>mothacehe: today Madalin would like to reboot a few build nodes to apply firmware upgrades. Would it be okay to drain the queue on half of the nodes? <rekado_>apteryx: I don’t know what the corresponding work is that the go-build-system has to perform here. <rekado_>I cannot just run “go build” obviously. <rekado_>AFAIU I also need to build every module separately, so the first one I picked is the cli module. <rekado_>and that’s where my problems begin: I set import-path to "github.com/oniony/TMSU/cli" and the go-build-system doesn’t find any code. <rekado_>it says: can't load package: package github.com/oniony/TMSU/cli: no Go files in /tmp/guix-build-go-github-com-oniony-tmsu-cli-0.7.5.drv-0/src/github.com/oniony/TMSU/cli <rekado_>and indeed: there’s some weird nesting going on; here’s one of the target files that the go-build-system has copied: /tmp/guix-build-go-github-com-oniony-tmsu-cli-0.7.5.drv-0/src/github.com/oniony/TMSU/cli/src/github.com/oniony/TMSU/common/path/path_test.go <dftxbs3e>whew git history manipulations are so time-consuming/error-prone/stressful going back and forth rebasing ensuring everything is right before pushing. <rekado_>I get a later error (progress!) with #:import-path "github.com/oniony/TMSU/cli" and #:unpack-path ".." <apteryx>rekado_: the import path needs to match how the source code refer to the library internally, I think <rekado_>yay: successfully built /gnu/store/mpgrf2jz115ybmcwrx8jsxy3hkfl00wb-go-github-com-oniony-tmsu-cli-0.7.5.drv *roptat running time guix build -f camlboot.scm <roptat>apparently, build time is done to just a few hours <roptat>for those who didn't follow: camlboot is a bootstrap compiler for OCaml <roptat>it contains an OCaml interpreter written in a small subset of OCaml, miniml, and a compiler for miniml written in Guile. The interpreter can interpret the compiler compiling itself. We even managed to check that the resulting compiler is bit-to-bit identical to what is obtained from the binary bootstrap included in the sources after another pass of compilation <dftxbs3e>(can't use lint because of it, temporarily reverting I guess..?) <dftxbs3e>Not sure if both are related actually, let me check <rekado_>“compiler for miniml written in Guile” sounds fun! <rekado_>mothacehe: okay, I’ve disabled a bunch of nodes in /etc/guix/machines.scm. Will enable them one by one as Madalin makes progress. <roptat>rekado_, I didn't write it, but the lack of static typing apparently made things harder ^^' <fnstudio>hi, when i read a package definition, eg `(define hello (package (name "hello") ...))`, and i see the word `package`, what's that? it doesn't seem like a procedure? <fnstudio>(sorry this must be a very basic question and it might belong to guile more than it belongs here) <dftxbs3e>fnstudio, maybe it's a syntax-rules macro..? not sure <rekado_>apteryx: yeah, not sure I understand it, but I’m okay with that. <rekado_>loading a manifest now seems to require (use-modules (gnu packages)) before using specifications->manifest <rekado_>oof, I even get an exception when I add the missing module <pkill9>rekado_: what neat things have you been doing with tmsu? <rekado_>and maybe photos, because I’m disappointed with shotwell. <rekado_>can anyone confirm that “guix environment -l guix.scm” is broken? <rekado_>try this guix.scm: (specifications->manifest '("python-numpy")) <rekado_>but also a1b3c6be4cdc16986f879f4757c868dbd0fa5b6e <roptat>but that's a manifest, so you should use -m <roptat>I try to use guix.scm for package definitions and manifest.scm for manifests <roptat>that way it's less confusing I think <roptat>at least, I have less problems with muscle memory ^^ <zimoun>roptat: neat! OCaml bootstrapped :-) <pkill9>rekado_: the tmsu package has tmsu in all caps, and also it has the src directory in the output path <roptat>though it's a slightly modified OCaml 4.07.1 for now <roptat>later versions require menhir (a parser generator written in OCaml), so they are not really good targets for the bootstrap. We can build the latest menhir with the bootstrap 4.07 though, so there's hope, but we might have to change the interpreter to be able to interpret the latest OCaml <rekado_>pkill9: including the source directory is probably not good (is this what the go-build-system does?), but TMSU being all caps… I don’t know why that is. <pkill9>in atleast some other go packags, i think the src directory has to be explicitly deleted maybe <pkill9>yea i wonder why, maybe their makefile corrects it <boombim>Hello. I got error with zathura in guix <roptat>boombim, have you installed a plugin, like zathura-pdf-poppler? <roptat>if so, check your environment variables, you should have ZATHURA_PLUGINS_PATH defined <roptat>(it should be set automatically by guix for you) <boombim>I don't iunderstand. I don't need plugins yet <roptat>boombim, without a plugin, I don't think zathura can do anything <roptat>you need zathura-pdf-poppler or zathura-pdf-mupdf to open a pdf <rekado_>mothacehe: I removed a bunch of nodes from /etc/guix/machines.scm but right as Madalin wanted to reboot some of them he noticed that they are in use again. <boombim>so I have installed zathura-pdf-mupdf. Shoud i create ZATHURA_PLUGINS_PATH environment variable now? <rekado_>does cuirass still respect that file? <rekado_>or do I need to restart cuirass whenever that file changes? <roptat>boombim, "guix package --search-paths" should tell you what to do <mothacehe>rekado_: no Cuirass does not go through that file anymore. The build nodes ask for pending builds and perform them on their own. Madalin can reboot the machines even if they are busy. <emacsen>pkill9, a bit like going into a Catholic Church and asking if anyone is a Muslim <emacsen>not a bad question, but you'd probably find better places to ask it <pkill9>well I want to know what people think of it compared iwth guix system <rekado_>pkill9: it’s *very* different; I don’t know how to compare them. <pkill9>which would you use as a server, openbsd or guix system? <emacsen>pkill9, "Do do you love more, Jesus or Mohammad?" ;) <emacsen>just sayin you won't find unbiased opinions here ;) <pkill9>but openbsd makes a lot of effort to be secure by default <emacsen>pkill9, they're very different in goals, so it's very hard to compare the two. <pkill9>and it's very stable so, maybe it would be good for a server you can just leave running without maintaining, specifically for static site hosting <emacsen>which is better, a tank or a speedboat <lfam>It's an interesting thing, reputation. OpenBSD has spent many years talking about security and focusing on it. GNU / Linux is what powers the world, however <emacsen>I also dislike how OpenBSD doesn't even notify upstream of all their patches, or hasn't in the past <lfam>Sometimes GNU / Linux learns things from OpenBSD <emacsen>they've left bugs in and sometimes said "Oh we fixed that years ago"... thanks.... <lfam>But, OpenBSD serves so few use cases that it's hard to say it's more secure in a meaningful sense <lfam>You really have to think about what you want to do and what you're worried about in order to make judgement about it <lfam>emacsen: That happens in GNU / Linux too ;) <emacsen>lfam, it's true, but more with commerical OSes I suspect <lfam>In all cases, communication and coordination are usually "harder" than fixing bugs <lfam>In the sense that programmers are good at programming <bavier[m]>and sometimes getting upstream to accept even trivial patches proves to be exceedingly difficult. <lfam>Yup. And I can't say that OpenBSD has a reputation for effective interpersonal communication ***lovetolearn is now known as ltl3
***ltl3 is now known as ltl2
<Aurora_v_kosmose>Huh, git format-patch unwrapped one of my lines in my patch. How peculiar. <lfam>Did you send the patch as an attachment? <lfam>It's unlikely that `git format-patch` caused the problem <lfam>It's more likely that your mail program did it. I recommend using attachments <Aurora_v_kosmose>Part of the message body, sent using msmtp. And I had apparently forgotten to update my commit, so yeah, PEBCAK <lfam>I use msmtp, but with `git send-email`. I recommend either attaching the patch or using `git send-email` <Aurora_v_kosmose>I'd tried send-email but it refused to work adequately, so I just piped the formatted patch into msmtp. <pkill9>i'll probably just stick with guix system <pkill9>now if only there were a way to instantiate a new vps with a given guix configuration <pkill9>i'll just use snapshots for now I guess <roptat>guix deploy does that I think, no? <roptat>though it's limited to one VPS provider <roptat>or add support to guix deploy for another VPS provider ;) <pkill9>i want everything done automagically for me <terpri>it'd be nifty to have linode support, but again...effort <Aurora_v_kosmose>Ah... I found why git send-email wasn't happy with me. Full path, not just the program name. <civodul>i think the effort for adding 'deploy' backends is quite small though <terpri>(they have some kind of semi-interactive/form-based scripted installation system, iirc, which might work nicely with command-line installation) <civodul>plus, one can paste existing code as a starting point <terpri>(and i don't need another yak to shave, i still have ~90 custom packages in ~/guix of which about half should be submitted :p) <lfam>Anyone got a timeline in their head for the next big rebuild cycles? <lfam>I was thinking we should wait at least one more month, to take advantage of continuing improvements to the build farm :) <lfam>But, maybe not much longer than that. I think we have the capability to build more quickly than in the past <mothacehe>civodul: some of the memory issues I'm having are caused by a pointer finalizer I introduced in guile-simple-zmq. It's so hard to get them right. <civodul>lfam: yeah, i'd say one month at most <lfam>I was wondering if we should do another staging cycle, or combine it with core-updates <lfam>Should we do an ungrafting cycle? <civodul>mothacehe: it does take some time to know what to pay attention to <civodul>lfam: i'm tempted to focus on core-updates now <mothacehe>hehe yes plus I fall into the same traps each time I'm using them <lfam>In that case, we might as well join the branches, right civodul? I think core-updates is a superset <lfam>I need to go AFK for a couple hours, but if anyone else has thoughts on this subject, I'll read the log <civodul>for core-updates, there's the possibility of merging wip-build-systems-gexp <civodul>if i can get all the build systems ported and all the test failures fixed, that is <civodul>that would introduce its share of... exciting news :-) <pkill9>i'm getting this error using guix deploy: arguments: (system-error "open-file" "~A: ~S" ("No such file or directory" "/gnu/store/p3ahdfcwa5yd65l5nzsnzshw9s7x3xc7-remote-exp.scm") (2)) <civodul>pkill9: we'd need more context, but it would seem that the expression to be executed on the remote machine was gc'd before it could be evaluated <pkill9>i've sent it with `guix copy` and gonna try again <pkill9>but I didn't run any garbage collection <pkill9>what happened was, i ran guix deploy before having authorized susbstitutes from my local machine <pkill9>so it would have rejected that remote-exp.scm <pkill9>after I authorized it, i guess it didn't try sending it again <pkill9>it's an interesting concept, having the remote machine build stuff from my locally-created guix <pkill9>I'd like the less-overhead of just ssh'ing in and sending it commands, but *pkill9 wants to use `guix deploy` <pkill9>damn it did it again with a different file <pkill9> arguments: (system-error "open-file" "~A: ~S" ("No such file or directory" "/gnu/store/svdfdjdiw1kblp8l3gcgb3q9344i9dzz-remote-exp.scm") (2)) <pkill9>also i set "build-locally?" to #f, but it was trying to build stuff on my machine <maxxcan>leoprikler: hello, Finally I figure out the problem but not the solution <pkill9>also it says --dry-run is a flag for `guix deploy`, but when I se that it says it doesn't recognise it <alextee[m]>not sure what exactly went wrong but after my last system upgrade I can't run my program beacuse it can't find the gdk pixbuf svg loader <alextee[m]>gdk-pixbuf+svg seems to be a dependency of gtk3 which my app uses <alextee[m]>and i can see the svg loader in ~/.guix-profile/lib/gdk-pixbuf-2.0/2.10.0/loaders <alextee[m]>but it looks like ~/.guix-profile/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache doesn't include it for some reason <maxxcan>alextee the same to me in my last chance in a virtual machine *pkill9 is `guix deploying` to the same machine <alextee[m]>i suspect something is forgetting to run gdk-pixbuf-query-loaders to write to the loaders.cache file <alextee[m]>i think this should be done during the post-install phases <alextee[m]>actually `gdk-pixbuf-query-loaders` doesn't return it either. strange ***rj_ is now known as rj
<apteryx>lfam: where should go-build-system updates go? staging? <apteryx>seems we don't have many go packages; master may be OK <roptat>as long as we don't have other packages depend on go packages? <pkill9>well i reported the bugs in guix deploy so it will hopefully be fixed <jlicht>oof, sorry about the http-parser thing! <apteryx>roptat: seems OK: packages=$(./pre-inst-env guix package -A '^go-' | cut -f1); guix refresh -l $packages -> Building the following 80 packages would ensure 248 dependent packages are rebuilt [...] <jlicht>sneek: later tell mothacehe: thanks for cleaning up my mess. `http-parser' did not show up in the RSS feed, so I was not at my laptop :/ *jlicht is drooling looking at nix' "lorri" tool <lfam>apteryx: Master is okay. It's technically just over the limit but Go packages are mostly very cheap to build <lfam>I used `git grep "build-system go-build-system" | wc -l` to count <roptat>after 4h and 15 minutes, the build failed in the install phase because I used let instead of let* :/ <rekado_>roptat: would this have been caught by compilation? <lfam>That's happened to me before <rekado_>perhaps we could add a feature to compile the build phases to check for errors <roptat>it would have told me "possibly unbound variable" <lfam>I always compile, but this is just a warning, IIRC <roptat>but it's not a compile-time error <lfam>If compiling many files, it's easy to miss <rekado_>roptat: well, that would have been a good warning <pkill9>i really wanna get guix deploy working, so my dream of being able to instantly create servers like they're just applications you install, comes to fruition <pkill9>except without the opaqueness and inflexibility of current devops services <rekado_>lfam: I mean to compile the build scripts on “guix build --whatever”, so that it wouldn’t be drowned out by other noise <rekado_>pkill9: where do you want to deploy? What’s the target? <pkill9>rekado_: I want to deploy to a vps, but there's one main issue, which is that it seems to start building locally instead of respecting (build-locally? #f) <pkill9>there's another minor issue, which is that it's not sending remote-gexp.scm, however that's easy enough to work around for now using `guix copy` <rekado_>“guix deploy” works by building the system locally (or by offloading to another server); it then sends over the whole thing and switches to the new system on the remote. <pkill9>the manual says that (build-locally? #f) will have it build the system derivation on the remote <jlicht>rekado_: it's a caching daemon that takes away many pain points for a closely integrated development experience with nix-shell, based on direnv <alextee[m]>well i found a workaround for the gdk pixbuf thing. i created the cache file elsewhere by passing `GDK_PIXBUF_MODULEDIR` so it finds the svg loader and then I use `GDK_PIXBUF_MODULE_FILE` to point my app to the file <alextee[m]>seems like auto-detection is broken in recent guix commits <jlicht>dongcarl: is this an error on running "guix pull", or "make authenticate" in a git checkout? <dongcarl>I think `guix time-machine` works very much like `guix pull` :-) <jlicht>dongcarl: I know that message when working with a git checkout, and then a "fetch all remotes" takes care of that ill <dongcarl>Ah gotcha, perhaps I need to find where `guix` checks out my repo and do a manual fetch <dongcarl>Aha! Found it... it's in ~/.cache/guix/checkouts... manually fetching the keyring branch fixes it! <dongcarl>If anyone knows if this has been fixed in master already or not: please let me know :-) <lfam>It's not clear what's wrong, so hard to see if it is fixed <dongcarl>lfam: So I first did a `guix time-machine` to a commit on my repo, it failed because I'm missing some keys on my keyring branch, so I got those keys into my keyring branch and did a `guix time-machine` again, but it still fails. <dongcarl>It seems like the problem was that the second `guix time-machine` assumed that there were no updates to the keyring branch, and thus did not try to fetch it again <dongcarl>Now that I've manually fetched it... It works! <lfam>I recommend reporting it to <bug-guix@gnu.org> <lfam>I'm guess it's a corner case <pkill9>rekado_: do you know what could be causing guix deploy to build locally? <lfam>I'm not him but, have you set up offloading? <lfam>I haven't used `guix deploy` but I assume it uses the offloading functionality to achieve remote building <jlicht>How can one generate an s-expression similar to the output of `guix describe -f channels', but including the "branch" that `guix describe' displays? <pkill9>lfam: I set 'build-locally? #f' so it should build on the machine I am deploying to <lfam>Right, but you also need to do some work to ensure that is possible. That's what I'm asking you about <pkill9>oh i see, so it treats the remote machine as the machine to offload to <lfam>Does the remote machine even have Guix installed? <lfam>I'm not sure that it uses offloading. I'm looking at the code <pkill9>has anyone used pipewire in place of jack and/or pulseaudio? <pkill9>i don't really understand any of the lower level stuff much <leoprikler>how would you even configure guix to "use pipewire everywhere" as it were? <pkill9>probably using grafts leoprikler, or an LD_LIBRARY_PATH environment variable <pkill9>does no one use the build-locally? setting? <lfam>It could be that it doesn't work, or it could be that there is some more setup that you need to do <lfam>It's sort of an obscure feature so I recommend filing a bug report or waiting longer for advice <pkill9> idk what setup i need to do if there is any :/ <iis>hello, is it possible to run AppImage software on Gnu Guix? I tried with Criptext-latest.AppImage (https://criptext.org) and got the "No such file or directory" error <lfam>I say it's obscure because, with offloading, you'd typically build on one machine and deploy to many. It's less likely you'd want to build on every remote machine <lfam>I mean, s/offloading/deploying <lfam>iis: No, those programs are built for a different operating system than Guix <lfam>iis: They are probably failing to find the linker / loader *pkill9 needs to finish the fhs script <lfam>pkill9: In the meantime, you could build locally <iis>pkill9: and lfam: ok. AppImage it is supposed to be out of the box, like a portable linux software. <lfam>iis: Yes, that is how it's advertised. But as you see, the reality is different ;) <pkill9>iis: it relies on typical filesystem hierarchy standard location of glibc <lfam>It's portable to old-style GNU / Linux, but Guix is something different <iis>And what about flatpak and the other ... what is the name? <lfam>Guix is just too different <iis>snap is the other. I get it. Guix is different mmore organized <roptat>I think people managed to run some flatpaks <roptat>some had font / graphical issues though, but I can't help, I don't use flatpaks <iis>pkill9: thats good, although It seems to me flatpak is good Idea but waste of resources/disk space and some vulnerabilities <iis>pkill9: I'll check the link. Thanks. <pkill9>flatpak is a poor implementation of guix :P <pkill9>it's real goal is to deliver proprietary software <dftxbs3e>I think we can use bwrap (flatpak's unprivileged sandboxing utility) so emulate some of that desktop emulation of Flatpak on GNU Guix (I heard installed packages could have "runtime wrapper options" in the future, so this might allow it). <dftxbs3e>I talked to Flatpak upstream and they said that is the best thing to do <dftxbs3e>bwrap combined with running portal daemons as well <pkill9>bwrap is a dep of flatpak ithink <pkill9>wel if bwrap is a depthen surely it's already implemented <sipa>i wanted to build without substitutes, but forgot to specify --no-substitues to guix build... how can i delete the result to rebuild it? <dftxbs3e>yes bwrap is all we need, but running portal daemons is not there, also somehow we have to embed the permissions needed for each package etc. <pkill9>i have an excuse to run a vps for deploying to servers <pkill9>I can use that same vps to offload builds for my laptop <sipa>dftxbs3e: thanks; guix gc -D /gnu/store/zsdy03jywqs252ik3p3576cmbhnc0ddi-libarchive-3.4.2 says it's still alive <pkill9>are you supposed to ssh into the 'master' server that deploys to the other servers? <pkill9>I suppose you can just edit the file locally and execute it on the master server <sipa>dftxbs3e: i don't know, i'm using some scripts around guix, and not too familiar with the details; would guix build --check help me? <pkill9>this could be a way of providing another service for producing server applications <pkill9>except with the flexibility and transparency of guix <sipa>dftxbs3e: seems that's building something from source at leastr <dftxbs3e>sipa, check can rebuild yes, guix challenge can rebuild and check against the substitute server what it has as well <pkill9>does anyone use things like ansible? <pkill9>how do they compare with guix deploy? <dftxbs3e>sipa, if it is still alive it means it's used somewhere in a profile, so remove all profiles that use the package or something, but maybe GNU Guix itself uses libarchive indirectly too, so .. <dftxbs3e>pkill9, ansible's a mess, GNU Guix declarative whole-system configuration is much much better, ansible is very very verbose and messy since it alters and checks machines that could be anything <dftxbs3e>pkill9, I think guix deploy needs to be extended to support more scenarios <pkill9>yea, that's what the people want, but the people don't currently want to put in the effort (I am in that category, lol) <dftxbs3e>I don't feel good enough in Scheme to even attempt <pkill9>tbh i will probably end up looking into it <pkill9>once i setup a vps for deploying <pkill9>because I think I will use it enough <pkill9>and then I can create and destroy and modify all the web services I desire <pkill9>and package new server software and configure it better <dftxbs3e>pkill9, do you have a single VPS or fleet of VPS? <pkill9>to try out openbsd, but I'm gonna destroy that/switch it to guix <pkill9>the the great thing with guix, is you can easily create domain-specific configurations for the web services <pkill9>because you can code the operating system configuration <pkill9>so you could have a function that takes a link to a git URL that contains a repository for a statically generated website <pkill9>and have that create an OS config that when deployed is immediately serving that website <pkill9>and have it automatically check for updates or whatever <pkill9>it's all the configuration of guix, multiplied by a fleet of VPS' <pkill9>(I should work in software sales) <sipa>dftxbs3e: so this is triggered by a guix time-machine environment, with --bootstrap <fnstudio>hi, i've just installed guix on a new debian machine (apt install guix) <fnstudio>i seem to have problems with the user config files and bash profile <fnstudio>for instance, i see that `~/.guix-profile` is a dangling symlink <fnstudio>that points to an non-existing `/var/guix/profiles/per-user/user/guix-profile` <fnstudio>wait, this must be written in the docs - let me have a look there first! :) <pkill9>I'm going to raise an army of Guix Systems *rekado_ dusts off guile-aws <pkill9>does guix deploy work with the latest release of guix, i.e. the iso from the front page? <pkill9>or does it require newer git releases? <fnstudio>(update: the symlink is no longer broken; i'm not sure why... i think it's because i edited my bash_profile but then hadn't logged out and in again; all working now) <jackhill>jgart[m]: I don't think I'll be able to make it today, but I like the idea, and hope y'all will do it again in the future, and I'll be able to join then. I'm in the right time zone at least (North Carolina) <jgart[m]>jackhill: We'd love to have you! We'll be hosting this meetup at least once a month. We often have impromptu meetups to work on stuff together. Just reach out at #libremiami:matrix.org or here. We have an xmpp bridge set up for the matrix room if you prefer xmpp. I'll be making asciinema recordings of the meetup sessions available in a git repo at gitlab.com/libremiami Stay tuned! I'll also post a livestream link of the tmate <jackhill>jgart[m]: cool, I'm interested in the XMPP bridge of the room. <pkill9>rekado_: could a translator for the Hurd be used for the functionality provided by tmsu? ***rekado_ is now known as rekado
<rekado>translators can do all sorts of weird things, so: probably, yes <rekado>whenever you use FUSE with Linux you could probably use a translator on the Hurd.