<jgart>I added python-recutils to GuixRUs <jgart>seems like it would be a nice package for upstream but it currently doesn't have a license or any releases <jgart>One test is failing so I disabled it <jgart>I'll open an issue to ask above questions with ttymck <jacereda>KE0VVT: could it be that you need to do `guix pull` without the sudo? <Kabouik>/tmp/nnn.scm:2:0: error: (syntax-parameterize ((current-definition-location (lambda (s) 2)))): bad syntax <jacereda>Kabouik: You have (define-public nnn), remove the closing paren <jgart>what can trigger an error like this? <jgart>error: in phase 'validate-runpath': uncaught exception: <jgart>gnu/store/zclng64h7k4i8d611ya13hjc631mdzq3-st-terror-0.8.4/bin/st: error: depends on 'libfontconfig.so.1', which cannot be found in RUNPATH () <lfam>jgart: The "RUNPATH" is a property of an ELF binary that includes the path of the your program's runtime dependencies <lfam>Try `readelf -d /path/to/binary` <lfam>Basically, you need to set something like (string-append "LDFLAGS = -Wl,-rpath=" (assoc-ref inputs "fontconfig") "/lib") <Kabouik>Hum jacereda, it seems it's my editor's lisp highlighter that automatically added this closing bracket! <lfam>Well, it doesn't have a RUNPATH at all jgart <lfam>Most binaries in Guix will have one <lfam>It really depends on the package's build scripts <jgart>This is the package definition in question in case that clarifies anything <lfam>If I were you, I would compare the source code of this package with st <lfam>Since st also depends on fontconfig but (presumably) builds successfully, you should find out what the difference is <lfam>Also compare to the output of `readelf -d $(guix build st)/bin/st` <lfam>That will show you how it should look <jgart>I had a few other st forks I packaged that had the same issue with RUNPATH <jgart>I haven't pushed those to the channel <Kabouik>That fixed the issue but I'm getting another one due to invalid base32 hash, thanks jacereda <Kabouik>I took the hash from the release url, I guess that's not what I needed <lfam>Weird that it doesn't work for any of them jgart <jgart>I'm having too much fun packaging st forks ;() <lfam>It explains what these fields are in a general way <jgart>It's interesting to see what people do with st. So many forks, so little time <lfam>"The sha256 field specifies the expected SHA256 hash of the file being downloaded. It is mandatory, and allows Guix to check the integrity of the file. The (base32 …) form introduces the base32 representation of the hash. You can obtain this information with guix download (see Invoking guix download) and guix hash (see Invoking guix hash). " <Kabouik>Oh, so I have to manually download the file first to get the hash. Thanks a lot lfam. <Kabouik>I'll try that now and will probably eventually try the trick to skip the hash (at least for git repos I trust) ***Xenguy_ is now known as Xenguy
<raingloom>guix import go -r github.com/matrix-org/dendrite@v0.5.1 generates a 12k line diff. i cri. ;_; <jgart>raingloom, I thought about it once *vagrantc wonders under what conditions sneek issues "wb" :) <jgart>vagrantc, Is there any docs for using sneek? <jgart>or an irc command that shows a help/info menu for sneek? <jgart>Or, it's just something people pick up "by rote"? <vagrantc>i just learned "later tell SOMEONE SOMETHING" and "botsnack" <jgart>vagrantc, cool! I'll start by feeding it first <lfam>nckx: Do we monitor our own uptime? :) <nckx>lilyp: Ah, that was not the reason I apologised, but good to know :) <nckx>Not that I know of that is. <hasjplante03[m]>does anyone know why my shepherd keeps exiting for no reason at all? im using guix home if that matters. <nckx>I just asked about Savannah's in #savannah but don't expect an answer until tomorrow here. <lfam>Yeah, hence my cheeky question :) <lfam>I guess we have the same opinion <lfam>I'm curious, does anyone deploy Git servers via declarative Guix configuration? <lfam>We do have a cgit-service-type, which is one of the Savannah frontends <nckx>rekado_: OK! My ionice wasn't meant to imply the rsyncs weren't important. I think quite the opposite. <lfam>But, like, is there a fully integrated "server in a box" type solution? <lfam>That's what we would need to feel confident about hosting ourselves, I think <nckx>I would guess the author of the cgit service at one point, but I don't use it myself. <nckx>29 Dec 00:52:11<rwp> nckx, Sorry but it's not. And uptime is going to be affected strongly by the network uptime in the Boston datacenter. <nckx>29 Dec 00:52:56<rwp> For example when the entire everything FSF/GNU was down for eight hours Sunday night the week before last. That's going to destroy any reasonable uptime rating. <nckx>Berlin's dismal bandwidth to parts of the world and/or times of the day hadn't occurred to me yet, but would be ‘less annoying’ for git at least. <nckx>lfam: Oh, our mails are almost identical if, er, personal style is discounted. <rekado>nckx: I didn’t expect my silly impulse to be seriously considered. I was just in this kind of mood, you know. <rekado>*I* wouldn’t want to host anything more than we already do. <rekado>but … sometimes I just yearn for things to be … different. <Kabouik>How do you guys know qhich modules to list in use-modules at the top of a package definition? I'm struggling to understand package names, whether they are guix or gnu, whether I should use use-modules or define-modules... I read the manual but found examples of both <nckx>Sorry if I took it more seriously/strongly than intended. I understand the yearning, but we (certainly including myself here, and just humans in general) love to rush into fun self-hosting adventures only to fail at the years of maintenance they imply. <nckx>I think the brutal honesty of better monitoring our own uptime would help temper that impulse, but I don't know any Free hosted services… and won't volunteer to self-host 😛 <Aurora_v_kosmose>If I want to use a given substitute-url entry on every user-level invocation, how should I do it? <Aurora_v_kosmose>Without going all the way to system-level & modifying the arguments of the guix daemon. <nckx>Aurora_v_kosmose: See the docs for GUIX_BUILD_OPTIONS. <nckx>Kabouik: To answer the easy part first: use-modules and define-module (not -modules) don't overlap: are you importing some existing module, in which case you ‘(use-modules (some existing module))’, or creating it, in which case you want (define-module (my cool module))? Maybe the confusion stems from the fact that (define-module …) supports optional #:use-module keywords, but just consider those synonymous with (use-modules …) if it helps. You can <nckx> import as many modules as you like but are always defining at most one per file. <nckx>Kabouik: In Guix, proper packages are always in (gnu packages <category>). As to how to find out which package is in which module, you can use ‘guix show PACKAGE’ (location field) or simply grep gnu/packages/. <Kabouik>That helps, thanks! I successfully built my custom nnn package apparently, using just a bunch of (use-modules), but finding which ones took a lot of trials and errors[D <nckx>The real answer is ‘you'll eventually know enough module names by heart that you'll only occasionally have to look it up at all.’ <nckx>At least for non-package things like (guix build utils) etc. <Kabouik>(The license part was hard, I would never have found it if I didn't find an example on someone's repo) <nckx>Kabouik: Those all look sane. I forgot about Guix's hints, which you probably followed, and which are often even correct. <Kabouik>(guix build-system gnu) is a bit obscure to me too <Aurora_v_kosmose>I was off doing something else for a while but came back to my ongoing project of setting up my dev environment to a Guix base yet again. <florhizome[m]>Kabouik: That’s the gnu-make build-system that you are probably using <Kabouik>Now I think I really need to delete the hash part, I'd want to download the latest release all the time and not have to download the file, guix hash, and to edit the scm file first. At least for this software because I trust it. <lfam>rekado: It's definitely something to strive for <nckx>Kabouik: You could have just (use-modules … (guix licenses)) like all the others, and written (license bsd-2) in your package. There's a reason we often use #:prefix in this case, but it's not some dark magic or anything. <lfam>rekado: Like, robust deployment of complex systems is something that Guix should be good at <Kabouik>But why do I have to use guix and gnu in the same brackets florhizome[m]? <nckx>(The boring reason is, at least, that there's a ‘zlib’ licence and a ’zlib’ package and they could conflict, so we tend to use the licence: prefix for consistency even in modules where it's not currently needed.) <akirakyle>I'm trying to install guixsd for the first time and I'm having trouble updating. I've run guix pull and can see I'm on the latest commit, but now I'm stuck runnnig guix system reconfigure /etc/config.scm, it keeps failing trying to build guix during the check phase and looking in the log I see the error "service 'org-server' provided more than <akirakyle>once". This looks like it fails on the first test on a line "+ guix system -n disk-image gnu/system/examples/desktop.tmpl". Any advice? <Kabouik>Makes sense nckx, I understand now. But I wouldn't have guessed the syntax, I'm too new on lisp <nckx>I'm not even sure the exact syntax is standardised across Schemes, let alone lisps. <florhizome[m]>Oooooh hey akirakyle glad you’re coming to guix I wanted to package emacs webkit anyways:)) <florhizome[m]><Kabouik> "But why do I have to use guix..." <- because gnu-make-build-system is actually gnu-build-system and under /guix/build-systems/gnu <lfam>Please share the entire error message on the same site <lfam>Are you sure the error refers to 'org-server'? And not 'xorg-server'? <akirakyle>florhizome[m]: I've been wanting to switch from nix to guix for a few years now, and now I'm stuck in isolation so I figured it be a good time :) <akirakyle>I'm doing this in qemu so I don't have copy paste readily available :) <lfam>Can you also share your `guix describe` output? <lfam>Just share the first 8 digits of the hash in `guix describe` <florhizome[m]>yup I saw that you included a nix package description :) it’s a good time to land :) <akirakyle>lfam the guix build logfile is too large for the debian paste service <lfam>Also, can you clarify what you're doing? Did you already install Guix? Or are you installing it now? <akirakyle>the commit I'm on is ba19307 according to guix describe <florhizome[m]>I’m really wondering where those xorg are coming from, since there is no desktop-service <akirakyle>It's a bit involved since I'm trying to set up guixsd in a qemu instance on an m1 system, but since there's no aarch64 installer I did something similar to what I also had to do with nix which is use a generic arm installer from debian then install guix on top of that then from there ran guix system init <lfam>I agree with florhizome[m] <akirakyle>I did all that and I'm booting guix just fine. I installed an guix 1.3 I think so now I'm trying to update to master <lfam>There's no explanation for an error message involving xorg-service-type, so I think that maybe you missed the error message <akirakyle>As far as I can tell this error doesn't happen when building my config.scm, it happens when building guix itself <lfam>Does it say that the build of a particular file has failed? That filename would end in ".drv" <lfam>Knowing that would help a lot <akirakyle>Yes its rjwl9fmm4b6icvry8l2wlz2dwq09ic-guix-1.3.0-17.2a49ddb.drv <Kabouik>Thanks florhizome[m]. Still not quite straightforward to me but I guess it'll come as I get more familiar with guile (in 2060 after Skynet and the machines take over the world). <akirakyle>The log file from that failure is whats too big to paste <Kabouik>If I add a search-patches in my definition, the patch is searched in the same folder as the .scm file? <akirakyle>Here's the tail end of the log file: paste.debian.net/1225091 <lfam>I'm trying to build desktop.tmpl on x86_64, and I expect it to work. But maybe there is some weird bug on aarch64? Hard to explain this failure mode <nckx>So thank you for making me dig into the history :) <akirakyle>lfam: I'm looking through the logfile more carefully now and it looks like there's actually two tests failing: the tests/guix-system.sh which I pasted the output of and another one tests/gremlin.scm <lfam>Can you share errors from the failed gremlin test? <nckx>lfam: Right. That is not what we were expecting. <lfam>Has anybody actually tried using Guix on an M1 CPU yet? <lfam>Like, besides akirakyle? <lfam>I'm wondering if we have any stories of success <nckx>Oh, it's some Macintosh thing? <lfam>It's Apple's new ARM chips which are the fastest CPUs available at the moment <nckx>Kabouik: What's the name of these modules (as named in the define-module line)? <akirakyle>In principle since I'm running this under qemu, it should just appear as a generic aarch64 cpu to guix <lfam>akirakyle: Yes, as long as you are setting up QEMU right <nckx>But emulation adds its own layer of buggy dust. <jgart>I'd like to make a poll on explaining anything you'd like about a monad and its' relation to g-expressions in Guix in your own words. Just for fun. We might be able to use the poll results as input for more docs on the subject. <akirakyle>This shouldn't be emulation but virtualization <lfam>We did abandon aarch64 emulation on our build farm, because it simply didn't work well enough <lfam>Right, we were going from x86_64 -> aarch64, and that didn't work <lfam>Well, I'm currently running the command from that test "by hand" on x86_64 to see if I can reproduce the error. And I'm also running the test suite with `make check` <lfam>It takes a while to get to that test <akirakyle>Maybe I'll just have to bite the bullet and git bisect this error since I was able to build guix 1.3 <nckx>Kabouik: My bad, I missed the -f part. I'm not actually sure how patches are handled there. <nckx>GUILE_LOAD_PATH=$HOME/P/nnn-ctx8 guix build -f … should work. <jgart>since it is not a trivial concept/design decision in how we put things in a store <nckx>Kabouik: A guixier way to write the same is ‘guix build -L ~/P/nnn-ctx8 -f …’. <Kabouik>That works indeed! It would be easier to remember if I could put the full path/to/patch directly in the scheme and drop the env variable, since it would just be about invoking guix build -f, but I don't think that'll work <nckx>Well, you might be able to call add-to-load-path in your file, but I can't promise it will work. <jgart>does anyone use recutils in their day to day grind? If so, what do you use it for? <nckx>If you use a channel, search-patches will search the root directory of the channel, not any subdirectory containing the .scm file, I was wrong. <akirakyle>lfam: maybe I actually don't understand something here. Why is guix being built when I run guix system reconfigure? Shouldn't guix already be built by the earlier guix pull so that the guix being used for system reconfigure is the latest? <Kabouik>I'm not there yet (my understanding is channels are "published" package definitions, mine so far is just a local .scm file <nckx>I'm not very familiar with the ‘best’ -L and/or $GUIX_PACKAGE_PATH workflow, if there is one, since I've always used guix.git checkouts or channels. <Kabouik>But in the future I'd love to just be able to `guix install nnn-ctx8` indeed <jgart>Kabouik, what don't you understand yet about channels? <Kabouik>Just haven't read enough of the manual I think (I'm still on a phone remotely sshing into a guix machine since 2 days), navigating through the manuals is not optimal :p <jgart>If you're going to use a channel and not have people subscribe to it, you can lower the barrier to publishing/entry by not signing the commits <Kabouik>I would just want something that is not public obviously since my custom definition is just a very minor patch and a compiling option. <jgart>Here are two channels that don't sign commits <jgart>Kabouik, you can also subscribe to a "local channel" <Kabouik>I also need to drop the sha256/base32 part before I can make it a package, so that it automatically checks the latest release without checking hash (and hence require a manual guix download and scm editing) every time <jgart>notice the file:/// in the url field <Kabouik>Really appreciate all your help here, thanks all <nckx>Kabouik: Installing with ‘--with-latest=PACKAGE’ might do the job. The hash isn't optional and can't simply be dropped. <Kabouik>I read that it is not optional, but someone said earlier here that there is a trick to skip the hash check I believe <Kabouik>ddThat was jpoiret and drakonis, unless iISUNDERSTOOD. <Kabouik>Woh, woops. Unless I misunderstood*. <nckx>Everything's going to heck. <nckx>jpoiret> although there's something around that lets you do that anyways <nckx>I wonder if they're just talking about package transformations tho'. <nckx>Which are nice, but don't seem well-exposed on the Scheme side. <nckx>Maybe I'm masochistic for imagining (package-with-latest-source hello) or so. <Kabouik>Anyway, I now have my private channel in channels.scm (don't think guix takes it into account yet), nnn.scm kinda works, so I can just edit it when the mistery is solved on how to fetch the latest releast without checking the hash (or, alternatively, check the hash, but do that automagically without me first running `guix download url-to-tar.gz`) <jgart>Does anyone know of a package definition that writes a file with content in a downloaded git repository with guile? <jgart>I thought I had come across one the other day... <nckx>Kabouik: So your use case isn't covered by guix install --with-latest? <jgart>My use case is that I would like to create a small file with guile without making a patch file for a package <nckx>jgart: ‘writes a file with content in a downloaded git repository with guile’ isn't quite clear to me. <nckx>Do you mean do the equivalent of echo blah > some/new/file in a phase, or so? <Kabouik>That's a good question. I'm progressing with very little steps. `guix install` installs nnn with the official definition (i.e., without my patch and without the ctx8 compile option). Now with my own nnn-ctx8.scm, I just tried `guix build -L /path/to/scm -f /path/to/nnn-ctx8.scm`, haven't tried `guix install` from the private channel yet because I'm still setting it up <jgart>nckx, for example writing a one liner setup.py file in a python source tree that then gets built with guix <jgart>I want to do something similar but for a ruby package <nckx>I'd say use (with-output-to-file "setup.py" (lambda _ (display "hello, this is stuff"))) in a snippet IIUC. <nckx>Your hipster Rubies and Gemspex mean nothing to me. <nckx>Let me know if it's not what you want; maybe we can find something that is. <jgart>nckx, it's missing a gemspec file <Kabouik>Do I need to reconfigure to take my new channel into account? <jgart>but I'm too lazy to send a patch to them so I just want to do it myself with guile ha <jgart>but you'll need to `guix pull` depending on what you're doing <nckx>I'd use (name "nnn-ctx8") so you can unambigously identify it from the CLI. Otherwise Guix will pick whichever "nnn" is newest, Guix's or yours (with yours winning if they tie). <nckx>(…I'm not sure how deterministic that last parethesis is but it's my experience.) <Kabouik>Yes I did edit the package name eventually actually <Kabouik>Forgot to rename the nnn.scm file though. <nckx>That name is just for humans. <nckx>Computers exploit this vulnerability mercilessly. <lfam>It corresponds to a particular Git commit, whereas `guix pull` uses the latest commit by default <lfam>akirakyle: So, this test succeeds when I run the tests with `make check`, and also I am able to build the disk-image attempted by that test <akirakyle>lfam: why would guix system reconfigure then be trying to build a different guix than the guix that issued the command? Maybe I'm misunderstanding though <lfam>I don't know off-hand exactly why this is happening, but I can say that it's expected and correct behaviour <lfam>I don't have any guesses as to why this test would fail in this way on aarch64. Like, why some architectural differences would cause this problem <akirakyle>Alright, well I suppose the only thing left for me to do is to git bisect between master and 1.3 to see where this starts failing, it'll take awhile though. If I manage to track down a commit I'll send in a bug report <lfam>Somebody else with a fresher memory can explain the purpose of the 'guix' package <lfam>It's the kind of error that should be easy to track down. Like, it's a bug in how the services are composed in the operating-system declaration found in desktop.tmpl <akirakyle>Thanks for checking and helping. Well if you say it should be easy, hopefully that means its doable for me as a guix newbie! <lfam>Yeah, it *should* be easy. But it's mystifying as to why it fails for you and not for me or the build farm <nckx>lfam: I'm going to delete wip-test-52667. <akirakyle>Has the build farm actually build this version of guix yet? I assume I would get it as a substitute if it did? <akirakyle>I've grow accustomed to not having all the substitutes available for aarch64 given it's often neglected in build farms <lfam>akirakyle: I checked, and the build farm doesn't actually know about this derivation. Like, it has scheduled builds for this version of the package, but not for the revision of the package that corresponds to what has failed for you <lfam>So, it's definitely fishy <lfam>If you click through into those scheduled builds, you'll see that the derivations are different, unless I made a mistake looking it up <akirakyle>lfam this build looks like it corresponds to my derivation <akirakyle>I forgot to send the first two characters earlier since they go in a different directories under /var/log/guix/drvs/ based on those two characters and I just copied the file nae <lfam>Okay, I'll build this derivation on the build farm now. We'll see what happes <akirakyle>You have that power?? :) I knew I came to the right place <lfam>This is definitely the place to talk about Guix :) <jgart>nckx, thanks! it worked `with-output-to-file` ;() <lfam>It's maybe a bad idea to build it immediately since the aarch64 builders are currently busy, but what else are computers for except to do our bidding? <lfam>Anyways, it will take at least an hour to get a result <akirakyle>Yeah why does it look like all the machines are idle but the graph says there's 80k+ pending builds? <lfam>Presumably, the pending builds are for armhf (32-bit) and aarch64 <lfam>The majority of the builders are for x86_64 and i686 <akirakyle>What aarch64 hardware is this running on? It takes my m1 less thate 45min to hit that error <lfam>It's mostly the Honeycomb LX2, which is a 16-core Cortex-A72 implementation <lfam>Your M1 is the fastest CPU that exists right now <nckx>jgart: Ruby obviously doesn't mind the leading spaces this creates, but if you ever encounter a language which does, and don't want to lose the Guile-side indentation, you can actually ‘escape’ newlines like so: https://paste.debian.net/plainh/9fec475d <lfam>The Honeycomb is the only serious 64-bit ARM computer that's commercially available for <$30k <nckx>FORMAT will ignore any leading spaces following a ~@\n <lfam>Like aside from the new macbooks, which aren't supported well enough yet for use in a build farm (if ever) <nckx>If we had money to burn we could shove MacBooks in a rack? <lfam>Yes... once they are made to work :) <akirakyle>Maybe as the asahai linux people get more of there work upstream you could use a buch of m1 minis? <nckx>There goes my thermal nightmare. <lfam>Each new Linux release improves the support drastically <lfam>Which means, the support is still waiting for drastic improvements ;) <lfam>We could possibly use some M1 minis <lfam>It's a tough time to be buying. <nckx>Funny how the ‘servers are faster than my laptop’ truism is apparently not true for ARM. <lfam>If we were to spend a bunch of money we'd maybe buy some Ampere Altras, which are competitive <lfam>There are servers that are competitive with the M1 in terms of raw speed, but vastly superior in terms of core count, I/O, etc <lfam>But, the only one you can buy at retail is the Altra <lfam>As of a few months ago anyways <nckx>I've heard bad logistical anecdotes about it. <lfam>But we had to wait for the Honeycombs too <lfam>None of these weird products are getting their supplies right now <akirakyle>Where's that substitutes over IPFS I've been reading about? Wouldn't that make this whole build farm slowness less of of an issue? <lfam>It's what I meant when I said that it's a tough time to be buying <lfam>IPFS would be like a CDN <akirakyle>I could share my local builds as a substitue? <lfam>It would only distribute substitutes <nckx>akirakyle: Not here yet, and it wouldn't solve build speed. <jgart>nckx, thanks for the tip! I'll update the `shitchat` definition and add it for the sake of prudence <nckx>akirakyle: People would have to trust you to provide them with binary blobs. Possible, but not a solution at scale. <akirakyle>Ah! So no different than trusting other build farms <lfam>I was mistaken about the Altra price. You can get a maxed out 64 core workstation for $13k <lfam>And those chips are super fast too <lfam>Anyways, the Honeycomb could probably build Guix pretty fast with all 16 cores dedicated to it. But each job only gets a subset of the cores, and the machine is already loaded. So it will take longer <nckx>akirakyle: No different, but in principle when trusting ci.guix and bordeaux.guix, you're trusting the same people who push commits to master. In the case of other build farms you're trusting some random user, which may be a trusted friend, but that won't scale. <akirakyle>I thought I read awhile ago in eelco dolstra's thesis about functional package management that there was a way of doing distributed package management with minimal or no trust? <nckx>Yes, but this is no longer adressing build farm speed, only distribution. <nckx>If you mean what I think you mean. <akirakyle>Yes something about content addressed package stores? <nckx>If ci.guix has built a thing, and signed a thing, and the thing is reproducible, the signature will validate joe random's thing. But ci.guix still needs to build the thing first. <nckx>Otherwise you're still trusting only joe randoms signature — their word. <lfam>Guix *does* look on local networks for substitutes signed by the official build farm <nckx>That said ci.guix is an absolute beef-fest as far as x86 is concerned, we just need to bump the aarch64 capacity to similar levels. <akirakyle>Ah I see! I guess guix needs to get in on some of the sponsorship money nix seems to have garnered for its build farms <nckx>I'm not sure money is an issue. <lfam>I think the real issue with expanding the build farm is hosting <nckx>(Literally — I haven't checked the numbers this month.) <lfam>We can buy powerful machines, but the ongoing costs of hosting are another story <lfam>We need to be able to budget for that recurring expense, and that's harder to do <lfam>So, yeah, we need to find some companies with a spare 1/4 rack or something <nckx>As long as no strings are attached. <lfam>Or recurring donations, yes <lfam>Sure, the deal has to be right <lfam>But anyways, we can buy enough machines, no problem. The hosting is the tricky part <nckx>With my paranoid hat on, you'd want to firmly separate the people who seem eager to sponsor the build farm from where the build farm is actually hosted. <akirakyle>I wish I could help, but alas I'm a poor grad student <lfam>Everyone can help the project in their own way <akirakyle>A suggestion though as aarch64 becomes more popular, it might make sense build an installer or a qemu image? I know the arm world is a mess with the whole bootloader story so such an installer likely would not actually work for any board out there, but it would help someone like me who's trying to spin up something in qemu. <lfam>Helping us get Guix working on the M1 will help a lot <lfam>Yeah, the installer needs adjustment to build for aarch64. Help wanted! <lfam>It's actually really easy to try it <akirakyle>Well perhaps I could help out there as I get more familiar with the innards of guix <lfam>You can just adapt that command and run it "manually" in the Git chekcout <nckx>Can't agree more with lfam. Helping to improve Guix aarch64 support is just as valuable as contributing monies. <lfam>I know other people are interested in using the M1 computers with Guix <akirakyle>Ah I actually tried running running that as I was figuring out quirks with installing from guix on debian. I can't remember why that failed though <lfam>I bet it's because it hard-codes a dependency on something that only exists on x86_64 <lfam>Because, that's how it failed when I tried it a few months ago <akirakyle>I'm pretty sure the asahai project is not going to result in a linux runnable without binary blobs so how will that square with the fsf's stance on this? <nckx>(emacs:23316): dbind-WARNING **: 03:06:12.347: AT-SPI: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files <nckx>How the hell do I make emacs shut up. <lfam>But, most of us use Guix on computers that use non-free software <lfam>It's just how things are <nckx>nckx: export NO_AT_BRIDGE=1 <akirakyle>Okay, I do have to say the lack of official documentation on how to practically run guix makes it a lot more involved to get up and going compared to nix, which is already not the easiest <nckx>kreuzberg is hung again. <lfam>akirakyle: It sounds like you followed the directions but they didn't work? <nckx>There goes 40% of aarch64 build capacity. <lfam>Like, what did you wish was there akirakyle? <akirakyle>I don't suppose the fsf will change its stance on the nature of firmware blobs anytime soon? It must getting more and more difficult to get ahold of those old thinkbooks that run deblobed kernels <lfam>No, it's not going to change <lfam>But like I said, almost everyone who uses Guix uses it on whatever computer they have <apteryx>I run linux-libre on a Ryzen 3900X gaming desktop, not sure why you think linux-libre is confined to old gear <nckx>Almost all modern machines run deblobbed kernels, until you want wifi. <akirakyle>I've tried a few times over the years to install guix on bare metal and never managed, partly for not budgeting enough time (although I could've installed nix in that time), and partly for not understanding how to setup a nonfree kernel. In this case getting setup in qemu proved easier <lfam>The reputation of Guix *is* that it only works on libreboot with Hurd on 13 year old thinkpads. I have noticed this in comments sections <lfam>People latch onto the most outlandish details of a story :) <akirakyle>It's the wifi part. I've never used a desktop <apteryx>you could buy a 15$ dongle and forget about it <akirakyle>(personally, at work I'm sometimes forced to) <lfam>I think we can agree that the lack of wifi support is easily surmountable and that people are also easily put off by such small hurdles <akirakyle>I know it might sound silly, but I've mainly used macbook air's so I'm very accustomed to never having anything pluged in except for power <lfam>Yeah, and you are the median user of actual computers, which are becoming a small niche compared to mobile phones <lfam>Anyways, GNU Guix will definitely not support the wifi on a macbook air. But I'm sure that it will be supported by Linux <akirakyle>I would disagree about wifi support. It's quite difficult to figure out which proprietary blob is needed to support your wifichipset then the correct way to install it in your kernel varies from distro to distro <akirakyle>Even on macos it can be troublesome, although it's improved over the years, and now its pretty solid on the m1 machines <Aurora_v_kosmose>It came up in #qubes a few days ago. Turns out the broadcom chipset requires firmware that's distributed bundled in the proprietary drivers and needs to be extracted from it to be at all usable. <lfam>I'm surprised you've had trouble with wifi on macbooks. I use a macbook pros with macos for work and I always felt like their wifi implementation was the best of all laptop manufacturers <lfam>I meant to say that I use "macbook pros" as in, a fleet of them <nckx>lfam: Thanks for pointing out that bug. So we're using the positively ancient uvesafb to… support ‘modern’ AMD GPUs. Le sigh. <akirakyle>I've always been on airs so that might be a difference <lfam>It's a problem for the free software movement as led by FSF <lfam>There *is* some new support in external modules from the aircrack project <lfam>I use the aircrack driver to get 5 GHz wifi on linux-libre and it works <lfam>But, it has all the normal problems of out of tree drivers <lfam>So yeah, like I said, we are sympathetic <lfam>But it's not really something we can do much about <akirakyle>Thanks, I do wonder what this landscape will look like in the next decade, both on the fsf side and the commercial side since it doesn't seem like the situation is necessarily improving <Kabouik>Hum, guix pull is unhappy with my private channel. <lfam>I predict the situation will reach some kind of breaking point <lfam>Ultimately people work on what they want to work on <Aurora_v_kosmose>It's bizarre that there isn't some sort of standard set of operations for wifi radios. <Kabouik>Keeps aggressing me with "build of /gnu/store/xxx/private.drv failed" <lfam>There are standards, at least good enough for projects like aircrack-ng to write new drivers for existing hardware <akirakyle>Oh there is, its just is heavily regulated by the FCC and so its prohibitively expensive for anyone other than a large company to implement them, then their resulting IP is often export controlled <lfam>I can't give you an exact answer. But I suspect that the standards only describe things at a high level, and actually making a radio that works in the GHz bands is really a lot easier said than done <lfam>Like, computer programmers will radically underestimate the difficulty of that task <lfam>A few orders of magnitude difference in data rate? <akirakyle>I can attest knowing several people who work in this field that the sending and receiving is the hard part when you start asking for 100Mbps+ speeds <lfam>LTE is actually faster than wifi in many cases <lfam>Take note that ethernet PHYs faster than 1 Gbit/s also require special drivers <lfam>It's just not so easy to do <lfam>I thought we were talking about old school modems, not LTE <nckx>Kabouik: Should print a build log. <nckx>Kabouik: Which is often inscrutable without accompanying source. 😉 <Aurora_v_kosmose>But it seems that new ones essentially just extended the command set old modems used. <SeerLite[m]>Kabouik: If it also says something like "log output at /gnu/store/somehash.bz2" you can use bzcat or bzless on that file to get some more info on why the build failed <Kabouik>Ah! bzcat was what I was missing then <lfam>I think this talk by Bunnie Huang (designer of the famous Novena ARM board) about the issues in open hardware are germane to this discussion: <https://www.youtube.com/watch?v=zXwy65d_tu8>. He is somebody that cares very much about the free software movement and has successfully designed and shipped hardware that tries to espouse those values <akirakyle>I think part of the issue, at lest with respect to the fsf, is that between the abstraction a programmer cares mostly about and the ADC/DAC in the modem connected to the antenna, there's increasingly complicated algorithms that the modems would like to run (including neural nets in the future) that it cannot all just go into read only memory. Hence <akirakyle>the binary blobs becoming increasingly popular since then you can fix or improve things. <lfam>It's well worth watching if you care about these issues, IMO <Kabouik>Does that many any sense to you? "(exception misc-error (value #f) (value "no code for module ~S") (value ((nnn-ctx8))) (value #f))" <Aurora_v_kosmose>akirakyle: I think that should be feasible in the modem itself anyway though. <nckx>Kabouik: That's what I meant. We'll need to see the source. Are you missing a (define-module …), for example? Is your directory structure what Guile expects it to be, in this case an ‘nnn-ctx8.scm’ file in the root of your channel directory? <akirakyle>And that's what these modems now all have, but the issue is just that the fsf catagorizes the binary blob that these coprocessors must be loaded with as the same as other software on your system <lfam>You should definitely watch this talk :) <Aurora_v_kosmose>akirakyle: Well, so long as it has access to the same memory buses as the CPU, it is. <lfam>Or are you quoting from it? <Aurora_v_kosmose>If, however, like with the pinephone, it's separate from the rest of the system, then it shouldn't. <nckx>I never got that reasoning. <akirakyle>Sure, its just that its cheaper for the modem to not have its own storage for the code it needs to run and just let the mainboard upload its code to it <Aurora_v_kosmose>A number of manufacturers fail to separate dubious & untrustworthy components from the rest of the system. <Aurora_v_kosmose>akirakyle: So long as it's just loaded into the modem at boot-time and the modem has no ability to order the CPU around or read/write the system memory or buses, I think it should be counted as an exception. <akirakyle>Yes they don't have an incentive for adding more security than is necessary <akirakyle>But also I think it's more expensive to design the system in such a way <nckx>The FSF position makes sense; ‘software doesn't need to be free if it something something memory bus’ does not. <Aurora_v_kosmose>Proper compartmentalization like that makes it easy to recycle bits or replace them too. <Kabouik>I believe the directory is what Guile expects: /home/mat/Projects/guix-channel/.git into which nnn-ctx8.scm is copied, and this is the channels.scm: https://0x0.st/or5P.txt. Not sure about a missing define-module though, but the scm file works fine with guix build -f nnn-ctx8.scm. <Aurora_v_kosmose>nckx: Software doesn't need to be free if it cannot interfere with the user's computing. <nckx>You're performing part of your computing on that coprocessor. <Aurora_v_kosmose>nckx: A separate modem that obeys modem commands can only interfere in the same way an ISP can. <vagrantc>the distinction between "burned in" firmware and "loadable" firmware seems pretty arbitrary <nckx>It is in no way external or third-party. <lfam>What I want to know is why we never hear about firmware for hard drives and SSDs <akirakyle>My understanding is the the fsf's motivation isn't from a security perspective but from a you should have access to the source of all compiled code on your system <nckx>It is not owned by your ISP, unless you lease it. <akirakyle>where your system is everything on your harddrive <nckx>Yeah. ‘It's sandboxed’ is completely missing the point. <akirakyle>(which is why the firmware running your hard drive is excluded, since it's not actually contents in the hard drive) <lfam>Your hard drive that is its own computer that can be upgraded but without free software <lfam>If we are willing to accept that, why hold ourselves back from other firmware? <nckx>Why hold yourself back from proprietary software. <vagrantc>lfam: because it is really well hidden? :) <Aurora_v_kosmose>I'd prefer if everything was open, but I'm willing to accept blackboxes under the condition they cannot inflict harm. <lfam>It just seems to me that we are nowhere near "done" making a free computing system <akirakyle>FWIW I think that position doesn't make sense as it encroaches on advocating for free hardware, which I'm all for, but contradicts the fsf's stance <lfam>We have hardly got free software for any component of the system <nckx>Aurora_v_kosmose: Disc firmware is known to be completely subvertible. <lfam>I'm not saying that nonfree firmware is a good thing <Aurora_v_kosmose>nckx: Yes. This is also why FDE is mandatory even if you have no actual requirement for it. <Aurora_v_kosmose>Unfortunately dm-crypt's support for authenticated encryption is somewhat embryonic. <nckx>I don't think there are SSDs/HDDs with free firmware? There are plenty of usable wi-fi chips with it. So no, I don't see the equivalence. <Aurora_v_kosmose>If one uses authenticated encryption, the HDD cannot interfere with data in ways that will not raise errors. <vagrantc>nckx: so proprietary software is ok as long as there is no free software alternative? <lfam>It makes sense nckx. They aren't equivalent in that regard. But I still draw a different conclusion <nckx>It can still log usage times, volumes, plenty of good stuff. <nckx>Made easy to exfiltrare by your LTE/wifi blob ☺ <nckx>But we're conflating freedom with security again, apologies. <lfam>Anyways, what Guix can do about these issues is quite tightly constrained <nckx>vagrantc: Can't agree, sorry. <nckx>I see we all have very different opinions, which is nice. <akirakyle>lfam: Yes I understand and sympathize, it's a messy world and sorry I seem to have veered the topic into this <vagrantc>nckx: i can't agree either, but drawing a distinction between devices with free firmware and devices without ... might lead someone to that conclusion <nckx>Kabouik: I assume you didn't actually place nnn-ctx8.scm into .git, but into guix-channel? <nckx>Kabouik: You're missing a ‘define-module’ header. ‘guix build -f’ is not a test for that. <nckx>vagrantc: I don't think that conclusion would be valid, but I can see how it might be drawn in good faith. <lfam>I think the best thing that we can do in Guix is continue trying to build the community. From my point of view, the free software movement has a history of schisms, and the longer we can hold Guix together by creating a compelling technology that people want to use in spite of some difficulties with hardware support, the more likely people will be won over by our side and later go into industry and make hardware that we like *vagrantc keeps trying to use systems with as much free software as possible ... <nckx>akirakyle: You did nothing wrong, please don't apologise :) <nckx>It's perfectly on-topic. <lfam>Like, I think one of the mistakes of the past was for the free software movement to allow itself to split along these lines and create pragmatic "escape hatches" such as Debian, which is my primary operating system <lfam>Guix's model of making it easy-ish for users to "escape" while still staying within Guix is superious <vagrantc>i was really disappointed to find out the mnt/reform was not possible to do this with ... although you can swapout the CPU/RAM module in theory for something that didn't <lfam>In a similar way, Debian protects itself from a schism via the nonfree apt channels <Kabouik>So I fixed my channel path nckx, not sure about (define-module ...), let me read about it <nckx>I'm not sure where it's documented. <vagrantc>and guix protects itself by having secret software societies <nckx>Just add (define-module (nnn-ctx8)) t the top and you should be good. <lfam>It's certainly no secret vagrantc :) <nckx>Like real secret societies but shittier. <lfam>I mean, it's not as good as what Debian does IMO, but it's what we can do <lfam>Within the constraints that the project exists within <nckx>I'm not familiar with Debian, lfam, what do they do better in that regard? <vagrantc>they explicitly have a section of Debian that is confusingly not part of Debian but includes things that Debian cannot <nckx>Kabouik: Don't forget to commit each change (either as a new commit or with --amend) as guix pull will only ‘see’ committed changes. <nckx>I guess it makes sense if you're a user. <lfam>It makes sense if you're a user <nckx>I also appreciate you worded it funnily. So the DFSG don't hinder that? <nckx>Confusing acronym time incoming. <vagrantc>the criteria forwhat is ok for various parts of Debian and the parts that are not Debian but hosted on Debian infrastructure are at least spelled out <Kabouik>I did nckx. Hesitated to add the patch in commit though, I thought guix would only want to see the scm file, that might be a mistake. <nckx>‘Hosted’ meaning support (bug trackers, maybe metadata, …) or actual software packages as well? <nckx>Kabouik: You should add it. <vagrantc>nckx: all of the above, to some degree, where permissible <lfam>From a user's perspective, it's seamless <nckx>Permissible as in ‘external’ (legal) or internal policy? <vagrantc>yeah, i think that's fundamentally where Debian had a falling out with the FSF and/or GNU ... it wasn't separate enough <lfam>Yeah, I read old debian mailing lists from the 90s <nckx>Yeah, ‘seamless’ is… ehm. Right. <lfam>I think the falling out was somewhat personal... <lfam>A combination of technical disagreements and ... social alienation <vagrantc>classic internet drama, as opposed to modern internet drama <lfam>Quite a familiar pattern, I have to say <akirakyle>The first few attempts I previously made at installing guix on bare hardware I was not aware of the guix "(not so) secret society" so I was trying to do that myself and obviously failed <nckx>lfam: Do you have a link to the very beginnings of that? Very much my interest ☺ <lfam>Yes nckx but it's on a nasty website <lfam>Somebody leaked the archives as part of some weird vendetta <nckx>I want the drama from a historical perspective, not vindictive. <lfam>But from a historical perspective they are fascinating <vagrantc>nckx: basically, there's main (totally free software), contrib (software that is itself free software but depends on, say a toolchain or something that is non-free) and non-free (it is legally permissible to distribute by does not meet free software guidelines) ... contrib and non-free are ... technically not part of debian <opalvaults[m]>There's a former Debian dev that made a blog or website about his self-sustaining in the woods or something. I believe he was a part of the systemd exodus. That whole distribution is fascinating. <opalvaults[m]>The history behind it, etc. I hope big game-breaking changes don't happen to this distribution. <nckx>opalvaults[m]: Their lifestyle appeals to me, their opinions do not. :) <lfam>I'll be frank: The goal with Shepherd is to create an integrated and declarative management system that is as much a break with the past as systemd <opalvaults[m]>I wouldn't know anything about the opinions of them or anything. <nckx>Oh no, we've gone systemd. <vagrantc>nckx: knowing the person, i suspect their nuanced opinion might resonate with you :) <Aurora_v_kosmose>nckx: If the untrusted components can cooperate without being authorized, there's a problem. <nckx>vagrantc: Possible! Them not being part of Devuan makes that far more likely. By wich I simply mean, nuance was not a design goal there. <lfam>Godwin's law of distros: Any long discussion turns to systemd <vagrantc>but it's been interesting as someone deep in the debian community and edging myself in here :) <nckx>lfam: I was thinking the same thing. <opalvaults[m]>nckx: I promise I won't go there. I don't even think I have any strong opinions. I work on a Debian farm so I like what systemd provides me :D <Aurora_v_kosmose>If the HDD has a way to talk to the WiFi without being authorized by some trusted component to send that message, something's wrong. Of course faulty DMA & IOMMU does mean that in a lot of cases. <nckx>Aurora_v_kosmose: I don't disagree but the converse should not imply any improvement. I consider firewalled blobs just as bad. But I'm repeating myself now. <opalvaults[m]>Shepard is fascinating. The fact that I can make declarations that manipulate startup processes in one single file that describes the state of the system is so neat. <vagrantc>wow, so we've covered all the hard topics today, firmware, init systems, what's left to talk about? :) <Aurora_v_kosmose>Given it's mostly a wrapper over iptables/nftables, not to my knowledge. <lfam>vagrantc: I think we should change the name of the project <Aurora_v_kosmose>I have some grieviances with it, mainly parts where it doesn't support some things and I need to drop to raw commands. <opalvaults[m]>I like nothing having to deal with iptables flags. firewall-cmd --add-service=https --permanent && firewall-cmd --reload <vagrantc>lfam: i think the only question is camelcase or not <nckx>opalvaults[m]: I meant firewalled as sandboxed is sometimes used nowadays. <nckx>As in, forcibly separated from other components. <nckx>vagrantc: Rust in the kernel? <vagrantc>nckx: in? why not switch to a fully rust kernel. <robin>hm, am i missing something or is the substitute* documentation in (info "(guix)Build Utilities") either wrong or confusing? "Be careful about using ‘$’ to match the end of a line; by itself it won’t match the terminating newline of a line." <opalvaults[m]>Looks like it has iptables management at least which is cool with iptables-service-type *vagrantc is thankful people are bringing things back on topic :) <vagrantc>opalvaults[m]: seenenoughemptyrantstoday :) <robin>because there are plenty of substitute* usages in guix where a newline is included in the replacement string which presumably aren't superfluous (maybe it's referring to some bizarre edge case like substituting "$"?) <robin>s/confusing/confusing (to me)/ <nckx>robin: Try (substitute* FILE (("a$") "b")) where ‘a’ is a whole line. <Kabouik>"Building profile with xx packages" really takes forever on my machine, despite only 56 packages. Not sure which one made it this long but that's painful. <robin>substitute* usages with regexen ending in "$" i mean, of course <nckx>Gooberpatrol66: That kernel doesn't count, it's obviously, well: ‘There was also some previous work on Perl bindings’. *nckx hopes robin doesn't somehow get different results because that would be weird indeed. <opalvaults[m]>Does anyone use gnome-keyring-daemon to manage keys? It doesn't appear that there is an explicit --stop flag. If I don't provide a G-Expr, or provide an arbitrary one that pkill's the daemon when Shepard stops the service is okay? <nckx>robin: Of course, feel free to suggest improvements to the wording, assuming it's possible to clearly explain a confusing thing. <Kabouik>Thanks a lot nckx, lfam, jpoiret and others who helped me making my first private channel with my first custom package definition. It works with the local patch, I'm pretty happy. Next step will be to make it a bit less involved for new releases (I don't see myself editing it every time there is a release, especially as it's just for me) and auto-fill the version number and investigate this hash-trick-mistery I heard about. But that'll be for another <Kabouik>This is a steep uphill journey for someone who's not a programmer or experienced in guile/lisp, but it's rewarding and hopefully Guix can become my comfy distro on my main machine once I reach important milestones on that test machine. <nckx>Now that you have a channel, you can at least ‘guix install --with-latest=nnn-ctx8 nnn-ctx8’ and Guix might even fetch new commits every time you ‘guix upgrade’ it. Not 100% sure about that last bit — another thing I've not had use for myself, and the manual doesn't explicitly say. <nckx>Erps, I was looking at someone else's package, which uses git-fetch. If you could modify yours to use that, you could. <Kabouik>(method git-fetch) instead of (method url-fetch)? <Kabouik>Happy to try that tomorrow, but really the 7-8-minute long guix pull due to profile building makes it hard to iterate changes quickly tonight <nckx>That is why I sometimes use -f even with channels (but none of my channels have patches). <nckx>Except the GRUB one of course. Theming one's GRUB is very important. <Kabouik>(version ...) is used to compose the tarball url and is hardcoded currently in my scheme file, I'll have to investigate how to avoid that. Maybe git-getch just won't need it anyway to recognize the download url. <Kabouik>Ahem. 'git-getch' won't do miracles though, I reckon. :< <nckx>It doesn't, but why should it need to? You're fetching a tarball from github; might as well fetch it as a git repository instead so you can use --with-branch= at will. <ryanprior[m]>As an exercise, I want to write a web app (let's say using ruby/sinatra, but could be using anything in Guix) and then package & deploy it to a server along with a shepherd service to manage it. <ryanprior[m]>Anybody know of a tutorial or example of this? Or anybody willing to walk me through it / pair program with me on it, and I'll write the tutorial and send it to the cookbook? <ryanprior[m]>I know how to: write the service, write the guix package definition for it, and run `guix pack -R` to generate a package. But I don't know how to write the service definition or how to deploy & start the service on the remote machine. <robin>nckx, hm yeah, with a file containing "a\nb\nc\n", substitute* doesn't perform a replacement for "a$" but does for "a.*$", which i guess is what "by itself" means in the manual. actually, none of "a$", ".*a$", "[ab]$", "aa*$", or "aa?$" match, but "a.?$" and of course "a.*$" do <nckx>Should we suggest using a.*$ to match up to (and including! which in turn is confusing to some!) the newline? <nckx>Well, please suggest any improvements you think would help make the issue clear, I think I'm too used to this mess by now to see it clearly ☺ <robin>i'm not sure why "."-related matches appear to be treated specially (vs. char ranges and so on) -- though i'm sure the answer is buried deep in glibc somewhere -- but i'll just remember it instead of understanding it ;) <robin>nckx, well, given that i don't understand the behavior, i don't really have any suggestion other than maybe mentioning the .* "pattern" <robin>huh, "aa.{0}$" doesn't match either, although "aa.{0,1}$" does, i was hoping that might work for simple literal replacements <robin>(...with an extra a prepended to the test string) <robin>i'll put "actually understanding (ice-9 regex)" on my todo list, i guess <jgart>ryanprior[m], Get in touch with arunisaac <jgart>ryanprior[m], Above is a Guix System service that Arun coded up for genenetwork3, which is a flask app used in production. <jgart>ryanprior[m], Would be cool to generalize a Guix System service or make Guix System library/framework for deploying python/etc... web apps. <jgart>ryanprior[m], We've discussed this idea before I think. ***lukedashjr is now known as luke-jr
<jgart>hasjplante03[m], what should I see in `guix home`? ***lukedashjr is now known as luke-jr
<tissevert>is /homeless-shelter a guix thing or a python thing ? <tissevert>it's a really neat way to detect all the software that writes wherever it can for mere checks during install <viivien>From python-pywal, it seems that you can redefine HOME safely if the software tries to write to this place <tissevert>yeah, I've finally found countless examples doing that in $GUILE_LOAD_PATH <tissevert>so I thought I'd do just that — I'm trying to package a python lib that presents and caches and API, and apparently the first thing it does upon import is create the cache dir if it doesn't exist <tissevert>but it was hard to understand what was going on without any previous knowledge of that dir and where it was coming from ^^ <jgart>is `guix search` broken for anyone else? <jgart>I included the output of `guix describe` at the bottom <tissevert>jgart: the same search doesn't return anything here <jgart>Are you using the same revision as my `guix describe` output? <tissevert>I'm on ccd9d07de083a1b232a8b939959e27d4acac45bf too <tissevert>it's still git-versioned, with a ton of unchecked changes I don't know what to do about <jgart>I still have to do something about `guix home` <tissevert>and I'm still thinking about going guix home <jgart>I think I will continue with chezmoi <jgart>and slowly move some things over to `guix home` <tissevert>but last time I tried to import a config, it merely said that my bash_profile was at .bash_profile <jgart>did you try `guix home import`? <tissevert>and I fail to understand how that's reproducible and allows me to export it to other hosts <jgart>I mean `guix home import dir-name` <jgart>that's who I learned of chezmoi from <jgart>oleg (kitnil's) guix dotfiles are pretty extensive <jgart>currently chezmoi is out of date in guix unfortunately <tissevert>my PS1 is simply a short version of the current path, then I add contextual stuff like the first bytes of the current guix environment if any, and the current branch if I'm in a git repos <jgart>upgrading it is not trivial as there have been many version bumps and dependencies have exponentially grown/changed from the version in guix <tissevert>I guess I'll have to figure out how to use guix home <jgart>I'd like to work on the update but I think it might be a weekend project <jgart>maybe watching rde videos? not sure. I haven't had the time to learn `guix home` properly <jgart>I'd like to use it on a foreign distro <jgart>I'm looking to migrate to carbs linux or oasis linux and get guix running there <jgart>another long weekend project <tissevert>an OS with runit, but guix as package manager <jgart>I use Guix System mostly on servers although I might dedicate a laptop to Guix Desktop development/exploration <jgart>tissevert, this is my runit service for the guix-daemon: <jgart>exec /var/guix/profiles/per-user/root/current-guix/bin/guix-daemon --build-users-group=guixbuild <jgart>It's just another thing to hack on <tissevert>it's just that the init system looks very complicated and hard to get to on guix <jgart>I like the simplicity of runit <tissevert>while I used to have a lot of fun with runit <tissevert>it reuses a lot of UNIX stuff, so that everything from permissions, starting or stopping a daemon is merely an operation on files <tissevert>it's the first init system where I never needed to read the documentation about stupid variable names like "Wait" or "Depend" <jgart>I almost met the author of mcron in England before I left but then covid happened and thesis I guess ha <jgart>I'm looking to reach out again <tissevert>florhizome[m]: I'm curious about their similarities <tissevert>guix is the first system where I hack so little about my boot process <tissevert>I love doing PXE boot, and loading squashfs in RAM and stuff <tissevert>and I have absolutely no idea where to start if I was to ever do this in guix <jgart>I like a hybrid system where I can be declarative about a subset of things and not with others <jgart>atleast on my laptop, I like that approach <jgart>for servers with certain services, Guix System's declarative nature is awesome. <jgart>I'd rather set up a mumble server with Guix System than with any other distro <opalvaults[m]>tissevert: the Shepard manual is a very easy read if you haven't given it a once over already. It's pretty informative. I find it to be even more informative than runit. I'm still trying to do what I've done in systemD in the past and it appears to be just as flexible. <opalvaults[m]>s/I find it/I find Shepard to be even more informative than runit when it comes to statuses of services, how I create my own user-level services, etc. <tissevert>opalvaults[m]: thanks ! I didn't know there was a separate documentation apart from what I could read in the guix manual <opalvaults[m]>And here's the documentation. A cursory once over in the jump start section got me up to speed and I've been leisurely reading more when I run into issues. <opalvaults[m]>And last thing before I'm off for the night, here's an example I've created so you can get an idea of what it looks like to declare your own services <opalvaults[m]>(oh, i suppose I've spelled shepherd wrong ;p note to self dont code at 1 in the morning) <sneek>Welcome back mothacehe, you have 2 messages! <sneek>mothacehe, jpoiret says: I'm nearly done implementing a per-installer `run-command`, with configurable line-hooks: you can chose what to do with each line of the output, ie giving it to syslog and displaying it, be it in newt or in the tty. I'll try figuring out how to buffer and handle refreshing in newt properly next, but it should be good <sneek>mothacehe, jpoiret says: Also, do you think a parameter (run-command-in-installer) is good enough? I don't really see how we could pass the installer-specific procedure down to the steps. <tissevert>opalvaults[m]: wow thanks for so many resources ! good night <gnoo>turns out the culprit was bios loading bios before uefi and guix installed only uefi <gnoo>thanks! now, how do i make it so typing 'startx' will start x? <gnoo>i installed xinit and xorg-server <gnoo>startx now says unable to open /gnu/.../X no such file or directory <tissevert>I think there are resources about that, I'm pretty sure I've seen one already but I can't remember where <gnoo>i can open 'root' account with gdm but opening my user account dosen't work, it just bails out <jpoiret>gnoo: you should configure a user password <gnoo>i already did, i can log-in in tty <jpoiret>although GDM prevents TTY switching, no? maybe just its wayland version <gnoo>root's running i3 so it's xorg not wayland <jpoiret>i mean the GDM one, but yes by default everything should be Xorg unfortunately <gnoo>any way would be okay, even typing startx on tty3 <jpoiret>startx/xinit is finicky on Guix iirc <gnoo>oh, then gdm would be okay too <mothacehe>jpoiret: nice! sure a parameter to distinguish commands we want to have output in newt seems fine. On my side, I have created a dump.guix.gnu.org service that accepts crash dumps and that runs on Berlin. On the installer side, I'm able to generate a crash report with the current installer result + backtrace + syslog + dmesg. <jpoiret>it is weird that i3 fails to start for your user on GDM. Can you look into /var/log/debug if there are any related failures? <gnoo>also how can i add a group to my user? adding just (user-group (name "gnoo") (id 1002)) on /etc/config.scm spitted out a error before <jpoiret>mothacehe: great! that would solve our problems with paste.debian.net :) <jpoiret>gnoo: the user-group record needs to go in the (groups ) field of the operating-system, not users <mothacehe>cbaines: are you familiar with the DNS setup on bayfront? I added a "dump" entry poiting to berlin, reconfigured, restarted knotd, but it doesn't seems to be effective. <tissevert>gnoo: last time this happened to me I had left some .xsession script in my HOME directory <gnoo>nope, chmod +x .xsession didn't work <tissevert>then perhaps it's failing because it still contains instructions that were designed for your previous system ? <gnoo>so, for declaring a group, this should work, right? (groups (cons (user-group (name "gnoo") (id 1002)))) <gnoo>thanks, i'll now restart to see if it works <gnoo>oh, there's an example on "(guix)Using the Configuration System", i should probably read that :P <jpoiret>gnoo: you want (cons* (user-group ...) %base-groups) <jpoiret>because you want to add your group to the list of default groups, not have only your group <jpoiret>as to cons vs cons*, the latter lets you cons multiple values like (cons* v1 v2 v3 lst), whereas cons does not <jpoiret>it's a macro that directly translates to multiple chained cons <gnoo>oh, it's different than elisp where * denoted order <gnoo>no, in elisp, (let a b) could evaluate a or b at first but (let* a b) will fist evaluate a then only b <gnoo>what is the boot time for you guys, on my old laptop, void-linux used to boot at 30 seconds but guix is taking a lot more <gnoo>i also get a lot of: localhost dbus-daemon[325]: [system] Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms) <gnoo>ok, so i changed .xsession,.xinitrc,.Xauthority to .xsession.old,... and it's working! <jpoiret>mothacehe: incidentally, it looks like the main installer runner doesn't use exceptions but rather the old error system, this is why the backtraces from guile get mangled. Maybe we should switch to that, although I don't know how compatible both are (if we can still keep the old raising code but only upgrade the catch code) <gnoo>can finally open from gdm <tissevert>I can't say about the guys, but as for me it takes maybe about 30s. <jpoiret>gnoo: that meaning of * exists in guile too for let/let* for example, but it's also used for lambda/lambda* to have keyword arguments, etc... <jpoiret>it's weird that dbus wants to start elogind though <jpoiret>if you do `loginctl list-sessions` in you session, does it error out? <gnoo>no, it lists out 3 sessions <tissevert>I wasn't in front of the computer when I started it, but according to dmesg, it seems to have reached the encrypted data partition in a bit more than 10s., and from the line that says it managed to open it after I typed the keyword to the line that says NetworkManager got its link up, there were another 16s. <gnoo>there's an alternative to logind, right? can i use that instead? <jpoiret>oho, we only have elogind on Guix, fortunately <jpoiret>they both share 'org.freedesktop.login1' as their dbus name, and here dbus is trying to starte elogind itself even though it should already be started <gnoo>oh, but that requires dbus, right? i thought someone here said we can remove dbus in guix <jpoiret>well, you could, but then you cannot expect GDM/elogind to work, among others <gnoo>i used to use dhcpd and wpa_supplicant before, so i want to try that :) <jpoiret>screensharing under wayland, rootless mounting via udisks <gnoo>i'm using xorg, and will use seatd if i want to use wayland(sway) <jpoiret>you'll still be missing on the last two (among many others), but that's entirely up to you! <gnoo>yeah that's not much of a problem, i'm the sole user of this computer and never had to screenshare up to now <jpoiret>dbus is included in the %desktop-services list, you can remove it from there along with all the others <gnoo>thanks! i'll do that tommorow. today i need to read the manual <gnoo>thanks! appreciate it :) <vldn[m]>i try to evaluate the cuirass substitute builds before pulling the channel, find the commit with the completeted and existing subs and pull it, it already works for the standard substitute channel, but if i try another substitute server with channel it doesn't :( somebody has an idea? http://ix.io/3JUH <vldn[m]>here is another version with a package list that should be checked, but same problem, guix working, other channels not.. <vldn[m]>it's the wrong commit that the script finds, it's the normale guix channel commit i think.. <vldn[m]>guix pull: Fehler: Git-Fehler: object not found - no match for id (9309b488ca4ceef4fcc9283546e3b05c57b16ca8) , wrong commit number :/ <Kabouik>Is there a way to pull "master" with (method git-fetch (uri (git-reference (url "url") (commit version))) instead of a hardcoded commit or version? <Kabouik>jpoiret, drakonis, could you tell me more about what you hinted yesterday when you said it is possible to work around the hash check in a package definition? I want to avoid editing the scm file when sources have been updated (it's a private channel so I'm the only one taking the risk). <jpoiret>well, now that i'm looking at it, i don't see an easy way to do that. Someone more familiar with this might have another answer <jpoiret>although, when the hash mismatches, guix will very handsomely give you the actual hash, so updating it is quite fast <Kabouik>I see, thanks. It seems I'm able to git-fetch master but it'll always fail due to the hash unless I manually edit it <jpoiret>unless you want to a) update the package every day and b) it has a bunch of new commits every day, it shouldn't be too much of a chore <Kabouik>I won't upgrade it every day, but it's certain guix would find a new update every time I fire up `guix install`, so that would be convenient <vldn[m]>but maybe a script is possible to fetch automatically the commit after building it and updating it automatically.. <vldn[m]>or try with some guile to fetch the hash with guix download and include it before building <vldn[m]>would be a good guile and guix training and helpful :D <Kabouik>I'm sure it would be good practice but I reckon it's gonna be quite a challenge for me :> <Kabouik>If only I could give "*" as hash, that would make things easier :> <jpoiret>the main issue is that the hash is expected by the guix daemon, which is not written (or hackable) from guile <Kabouik>I wonder if I can programmatically replace (base 32 "hash") by some magic thing like (base32 (guix hash (guix-download url))). The syntax is all wrong obviously <tex_milan>I am trying to package neovide. It is a rust application, they have same forked crates and durng build they try to git clone them and it fails as it cant see the network (cannot connect to github.com). Is there something in cargo builder that messes with it? <tex_milan>Manually they can be cloned. Problem is not with address. <xelxebar>I successfully screwed up my guix store again with a power cut. Now lots of .drv items are just empty files. <xelxebar>Doing a `guix gc --verify=contents,repair' detects tons of problems, but it ends up OOMing all 24GB and never finishing. Restarting always seems to begin on the same item, so it doesn't seem to be repairing things mutably. <xelxebar>Any ideas for getting a working store again? <xelxebar>Maybe start a live distro and do some sort of dance to rebuild it? <vldn[m]>but you can keep your files if you just delete the guix specific files and folders from the mounted root system <vldn[m]>but maybe others have better suggestions for repairing the existing store <xelxebar>vldn[m]: Cheers. That's a reasonable fallback if no other less drastic solutions are available. Cheers. <vldn[m]>i wonder why the store fails often, i often got a defect store as well but maybe that's my weird config, at nixos i never had a unrepairable pkg store <vldn[m]>power cut shouldn't have such a drastic outcome, what filesystem do you use? <jpoiret>guix system init should be ok, if you remove /gnu first <xelxebar>Hrm. So yours just "randomly" fails? In my case, it's only happened after a power cut when something's pulling/installing/etc. <xelxebar>jpoiret: Thanks. So init will not touch existing files? <vldn[m]>does it work from the running system? <vldn[m]>i play alot with pulling,rebuilding and profile sourcing, the problem could be me xelxebar :D but still try finding the issues i stumble above <jpoiret>I believe init doesn't do such a thing <vldn[m]>thanks to guile more power of the system then in nix so more problems that could happen :P <xelxebar>What do you mean by "play alot with"? Are you doing funky things? Pulling and rebuilding alone are bog standard operations... <vldn[m]>but does e2fsck or something for ext4 or btrfs doesn't fix the power cut errors? <vldn[m]>maybe an automatic fsck on starting could be fixing you store too in the future <vldn[m]>but i think it's default on ext4 or not? <jpoiret>the root filesystem is fsck'd on boot iirc <xelxebar>vldn[m]: Oh, the filesystem itself is fine (I'm running btrfs). It's store *contents* that are mysteriously empty. <Franciman>is it possible to apply patches to kernel modules with guix? <vldn[m]>not working though :/ for the guix channel it's perfectly fine, but for the unspoken one i have to make more definitions like just checking the right channel in the evaluations.. <xelxebar>vldn[m]: I'm very interested in this. Mind letting me know if you end up with a good solution? <vldn[m]>here is another version without a package list: <xelxebar>Cheers. I'm saving these to dig in later :D <vldn[m]>if you are faster then me, let me know :) would be nice if this channel definition could help to make my guix on my notebook a substitute distro only :) <rndd>i tried to use git send-email which is not a git comand. Little search showed that this problem may be solved on debian by installing git-email package, which does not exist in guix. Maybe it is packaged with another package? <jpoiret>Looks good! I'm rewriting installer-program so that we use exceptions instead of catch, and have each installer handle exceptions however they want <jpoiret>I'm having an issue though, i just changed the installer record, and its only use at newt.scm, but i keep getting syntax-error on the form installer (and in an unknown location, so no idea where it could come from) <mothacehe>I suppose you already wipped to gnu/installer/*.go files? <jpoiret>I was thinking that the guix package's (gnu installer ...) were leaking into the installer environment <jpoiret>There are no go files there, they're compiled in the store. Also the abi check would've picked that up i think <mothacehe>right, unless --enable-installer is passed to the configure script <jpoiret>It does recompile all the installer files properly when i make a change though (and the syntax forms should already have been expanded then) <mothacehe>that's a hack i used to find compilation errors early on <jpoiret>But it's when running that it errors, so there's some uncompiled code somewhere (with no location too!) <jpoiret>I'll be off for a couple of hours, then i'll rebase my changes on yours <mothacehe>sure, don't hesitate to send wip versions, or the backtrace message. I'll try to have a look. <florhizome[m]><Franciman> "is it possible to apply patches..." <- Yes; you could definitely define a modified kernel or kernel module package, but maybe other approaches could work out, too. There are also articles about that on the web as far as I remember. <vldn[m]>how to create nested json objects with guile-json? <vldn[m]>like ([0] = { name="sdsdsd", id=2...}) <Kabouik>parinfer messed my brackets up in system.scm. Is there a way I can recover the currently used scheme to fix the file? <PotentialUser-9>In procedure open-file: No such file or directory: "export HISTFILE=~/.local/cache/bash_history" <PotentialUser-9>Has anybody else come across this before? I literally just installed Guix and tried to run 'guix home reconfigure' with the example configuration and it's not working. <jpoiret>Kabouik: you should find the current config at /run/current-system/config.scm <florhizome[m]><PotentialUser-9> "In procedure open-file: No..." <- does .local/cache exist ? <Kabouik>Excellent, thanks jpoiret (that was /run/current-system/configuration.scm) <florhizome[m]>jpoiret: are you going to implement adding channels from the installer? (; <PotentialUser-9>florhizome[m] It didn't but creating it didn't make any difference. Same error message. <PotentialUser-9>It's more that I'd like to see it work. Do you know what would work in the bash-profile spot? What I would like to do is add something like 'set -o vi' as that's something I always set. Although maybe that's not the right place for it. I'm not really sure. Just experimenting with trying to get the home command to work at all at the minute. <florhizome[m]>each time I think I’m getting comfortable with all the stuff needed to contribute sth to guix, sth doesn’t really work. hello debbugs, welcome to my life. <antonio79onFr>Hello, I cannot make work texlive installation using individual packages with org-mode export. I have always problems with fonts not found. The large texlive installation works fine, but I would like to stick with a light installation. What am i missing? <ngz>antonio79onFr: what does your minimal texlive look like? <ngz>antonio79onFr: I also have troubles doing the same, but this is because I need kpfonts package. However, this is not required per Org by default. <antonio79onFr>I have installed several texlive packages, including tex-baes <ngz>No, actually you shouldn't need it. It comes from my own LaTeX packages alist. <ngz>However, you may need, at least, "texlive-fonts-ec", "texlive-amsfonts" and "texlive-stmaryrd". <ngz>"texlive-generic-ulem", "texlive-latex-capt-of" and "texlive-latex-wrapfig", too. <Nazar>Hello there, does anybody know why files signature changed after it copied into store ? i have defined own package and after that i have problem with signatures <Nazar>sha256sum ~/composers/composer <Nazar>542ce16add6fd5ecfb0049dd49a0214e69a966a602b42c215adb19438c13a890 <Nazar>sha256sum /gnu/store/kb52s93zk8cl2r3w41w4qkvf7znfxr3f-composer-1.10.22/bin/composer <Nazar>3e58a6e61c28b79b162b12c2e67aa7fad7e652d1af5cbdbcf0cb87c4851217d5 <Nazar>yes composer.phar php script <jpoiret>Often, even the copy-build-system modifies the things it copies <jpoiret>Check if for example the shebang differs <jpoiret>You can diffoscope them to see the difference <Nazar>already:) there is no difference <Nazar>and there is date ahen it was modifiet it is like that Modify: 1970-01-01 03:00:01.000000000 +0300 <nckx>sneek: later tell rndd: ‘guix install git:send-email’ assuming you also ‘guix install’ed git (for implementation reasons, both must be installed to the same profile). <nckx>Nazar: There must be a difference if the checksum differs (file modification date is not a factor for the sha256sum tool). Does ‘cmp ~/composers/composer /gnu/store/kb52s93zk8cl2r3w41w4qkvf7znfxr3f-composer-1.10.22/bin/composer’ really return nothing? <Nazar>no this one, i hace compared the content of those file it was the same, but this one tells me differ: byte 4, line 1 <nckx>Then you made a human mistake whilst comparing :) <nckx>Sounds like the shebang. <Kabouik>Any workaround to avoid hardcoding /home/user in a (url "file:///home/user/path/to/guix-channel/")? <Kabouik>Guile doesn't seem to like ~/, I guess $HOME won't work either <nckx>Kabouik: Why not? You could use (string-append "file://" (getenv "HOME") "/path/to…") <nckx>~ is just shell shorthand for that. <Kabouik>Right! Didn't know about getenv, nice. <Kabouik>I don't think you doubted it but just wanted to confirm you solved my issue :> <Kabouik>See, now you solve my issues and then you thank me <Kabouik>Soon you'll beg to configure my system! <nckx>Hm, I'm easy to nerd-snipe but not that easy. <nckx>You'd have to do an exceptionally poor job for me to scream ‘no more, give it here’. <florhizome[m]>it tells me it cannot find use-service-modules, I could try to put (gnu) in use-modules. <florhizome[m]>these little things refusing to work are just pain atm and never seem to stop -.- <nckx>florhizome[m]: You're not alone, plenty of prolific contributors who use emacs don't use emacs-debbugs. I don't either. I don't think I encountered downright bugs, but it wasn't an intuitive improvement. <nckx>florhizome[m]: Paste your system.scm. <nckx>I know, I was typing that when you returned. <nckx>phodina[m]: No respect for $CC in their build system? <Nazar>how i can resolve this issue with signature ?:) <nckx>Nazar: What is the issue? (I know, they don't match, but why is this a problem, why do they differ in the first place, why is this difference *bad*, …?) <Nazar>bcs i cant run that program, bcs it checks the sha256 sum befor running <Nazar>Fatal error: Uncaught PharException: phar "/gnu/store/kb52s93zk8cl2r3w41w4qkvf7znfxr3f-composer-1.10.22/bin/composer" SHA1 signature could not be verified: broken signature in /gnu/store/kb52s93zk8cl2r3w41w4qkvf7znfxr3f-composer-1.10.22/bin/composer:23 <nckx>(Don't paste the stack trace here.) <nckx>No need. Some people unfamiliar with IRC sometimes do, and I wasn't sure what was coming. <phodina[m]>nckx: Nope, I tried setting it to cc-for-target but tjey don't pull the variable and have hardcoded cc almost everywhere. <phodina[m]>I'll open an issue and try to make PR with changes. <awb99>I need to change the guix channel to commit id 2c451db39aabc69bdbf186f412ee6e0b4e180ccb <awb99>do I do this via time machine? <awb99>or do I modify the channel.scm file? <nckx>phodina[m]: That would be easiest for us (and arguable the most correct solution in our worldview), but if upstream is uncooperative you could (mkdir-p "bin") (symlink (cc-for-target) "bin/cc") (setenv "PATH" … you get the idea). <awb99>My reason is that ungoogled-chromium-wayland is not building correctly, and I want to wait with updates till it does. <Nazar>okay i will try to remove that bytes mannually in install phase <karrq>Hello everyone, I need some help debugging an issue. I edited my .config/guix/channels.scm to add a channel and when I `guix pull` I get an error "Temporary failure in name resolution" but i can ping the url shown without any issues... any ideas what it could be? <phodina[m]>nckx: Yeah, I thought about it. Not the cleanest solution but might do the trick in the meantime. Thanks. <nckx>Nazar: I don't know much about Phar(?) or Composer. I guess patch out the ‘signature’ verification (I find it a dubious feature) or, if you want to get fancy, calculate the SHA-1 yourself and substitute* it. <nckx>Since I still don't know what ‘that bytes’ is I can't suggest other things. The patched shebang is, generally, a feature. <nckx>awb99: It's a bit silly, but I use this ‘do what I mean’ hack to automatically add the 'guix channel unless it's already present. Makes it slightly easier to (un)comment it without having to restructure the entire list. https://paste.debian.net/plainh/ea2d66b1 <Kabouik>Do appimages work on Guix? I have one to try but I'm in ssh so not the best place to try graphical apps <karrq>karrq: even without the custom channels I get the same issue.. <nckx>karrq: Does not look Guix-related at first glance. Which name fails to resolve? <awb99>so %default-channels is the current system channel config <nckx>karrq: You can try invalidating the cache with ‘sudo herd invalidate nscd’ although it's never worked greatly for me. <nckx>awb99: Well, for me it's always just (list 'guix) since I don't customise it anywhere else. Possible! <nckx>You'd need a slightly more complex helper to handle multiple channels if so. <karrq>nckx: yeah I wasn't sure it was guix related, but I could ping gitlab outside guix anyways... also it was failing to pull with the normal channels so in savannah... I did think maybe it was a DNS issue but then `ping gitlab.com` wouldn't work... regardless I have restarted ncsd (guix on foreing distro arch) and pull works now, whew <nckx>florhizome[m]: Not entirely to my surprise I can't reproduce this, but I had to delete a few modules that I lack. I definitely wouldn't put too much stock in that error and/or hint; (gnu) is obviously there; seems like something else is confusing Guile. https://paste.debian.net/plainh/4a03c917 <nckx>☝ ‘guix system build’s just fine. <florhizome[m]>nckx: yeah geiser is also not working, guile is confused a lot these days :/ <florhizome[m]>Those are way too many modules, but they don't seem to be the problem anyways <nckx>For a few months I had my (admittedly complex) system configuration in a state where any error, from minor typo to undefined variable to straight-up garbage, would just print ‘eval.scm: unexpected #f’ (I forget the details). That was fun. Guile confuses easily in certain situations. <nckx>(There was never any ‘#f’.) <nckx>florhizome[m]: If the module import I removed aren't the problem, I have no idea what is, sorry. <antonio79onFr>Hello again, I made some tests with texlive standalone packages and org-mode latex export. No sucess. Strangely I got it work sometimes but them after a logout/login cycle I broke again texlive system (missing fonts during pdflatex compile). I have no idea why. I make it work correctly only with the full texlive package. Otherwise missing fonts errors are usually present. I'm not a latex expert to debug it. What I'm doing wrong? Th <antonio79onFr>supposed be a trivial task.... am I the only one facing this issue? <awb99>When I use guix home. Should I by default not include any of the packages in the guix os profile? <antonio79onFr>Info: I installed the following packages: "texlive-base" "texlive-amsfonts" "texlive-fonts-ec""texlive-generic-ulem" "texlive-latex-capt-of" "texlive-latex-wrapfig" <awb99>I guess that they are automatically included anyway. *vagrantc wonders why sneek is so welcoming <ngz>antonio79onFr: you need to paste your minimal texlive setup and the error from pdf. You don't need to use Org mode, just call "latex" on the "tex" file Org mode generates. <ngz>Also showing a minimal generated tex file would help. <Guest42>ehat do i do if my system doesnt have cow-store service <Guest42>im getting service 'cow-store' could not be found <drakonis>you might want the appropriate irc channel for that i guess? <Guest42>its not associated with that channel tho <drakonis>that has to be made available on install time? <drakonis>then refer to the appropriate irc channels my guy <drakonis>there's an explanation on the readme i believe ***Xenguy_ is now known as Xenguy
<Kabouik>Any way to use an appimage on Guix? I know the paradigms are very distinct but I do need a couple apps whose Linux versions are only available as appimages, and closed source (meh, yes). <Kabouik>I tried to extract the appimage but failed baddly. <Nazar>okay in case someone need this, i have resolved issue with signature by thi (delete 'patch-source-shebangs):) thanks to all:) <lfam>That will definitely break the package <lfam>Well, probably definitely <Nazar>at least the signature is not changed by this phase <antonio79onFr>hello, I'm back with some information on my issue. I get the following error: "ERROR: Font OT1/cmr/m/n/10.95=cmr10 at 10.95pt not loadable: Metric (TFM) file not found." <antonio79onFr>I have several texlive packages installed, including the fonts the compiler is complaining. <antonio79onFr>I can get along with the complete texlive package, although i prefer to work with standalone packages <Nazar>looks like package is working as well:) <Noisytoot>The best solution would be to not use proprietary software <ss2>I’m not sure if the samba package has a problem. Calling samba-tools crashes while it tries to import talloc. The build log says talloc has been found. <lfam>Sounds like a problem, indeed <ss2>Looks like a path is missing? <lfam>The samba package propagates the talloc dependency <lfam>So, it's definitely a bug (a regression?) that it cannot be found <lfam>Although I would try installing samba-tools into your user's profile and see if that works <notmaximed>How does one find the patch set URL for a patch series on issues.guix.gnu.org (this has been answered before but I didn't find any good search keywords)? <ss2>ah, no, what do you mean now? <lfam>ss2: I mean, `guix install samba`, or whatever package provides samba-tools <ss2>lfam: right, “into” my profile, sure. Have done that, and have got a modified samba anyways now. But they all don’t work. <ss2>I’m removing it from my system profile, and will see if it is the same while there’s only the package left in my profile. <ss2>nope, crashes still. <Kabouik>Thanks Noisytoot! I'm afraid it'll be too complicated for me as I don't really understand what pkill9 made with fhs.scm. I agree just ditching proprietary software would be best, but there's one I couldn't replace with a FOSS alternative (cloud computing, the alternatives are not the same business plan). <ngz>antonio79onFr: As asked already, it would help if you could paste your tex document, too. <robin>Kabouik, appimage is...not easy to get working, far less guix-friendly than something like flatpak. actually, making a flatpak containing an appimage program is the only way i got one to sort-of work >_> i've tried the extract-and-run approach too, but that requires nontrivial further steps as i'm sure you discovered <awb99>I am trying to use emacs with soe plugins. The error I get is "error "straight.el bootstrap failed: Failed to run \"git\"; <antonio79onFr>ngz: I will paste only one part of the text. The issue appears anyway. <ngz>antonio79onFr: Please paste the complete headers. The contents do not matter. <robin>Kabouik, btw, re: rust nightly, i have packages for rust stable and beta, still working on nightly (there's a bootstrapping issue with rustfmt, should be straightforward otherwise) <lfam>What provides "giomm-2.4"? <lfam>ngz: No reason, maybe it stopped working when the server crashed? <ngz>Please use paste.debian.net <ngz>lfam: Could you restart it by any chance? ***ChanServ sets mode: +o lfam
***antonio79onFr was kicked by lfam (antonio79onFr)
***ChanServ sets mode: -o lfam
<lfam>ngz: I sent a message to the sysadmins about it <lfam>Hopefully antonio comes back <nckx>lfam: You can add a reason to the end of the /kick line to clarify it's not hostile. <lilyp>lfam: giomm-2.4 should be provided by glibmm 2.64 <lilyp>2.70 has a different minor version <lilyp>why does it have that? don't ask me <lilyp>Kabouik: If you plan to use AppImage extensively, you better learn your patchelf game :) <lfam>Do we have any internet radio player packages? <ss2>lfam: as in to brouse shoutcast? <lfam>I see curseradio, but something with a GUI would be nice <lfam>I'm trying to package some, and it's really a pain <lfam>I would be happy to just use something already packaged <ss2>do you use mpd? Cantata (a QT client) has a decent browser built in. <antonio79onFr>I have the same setup as yours, but still the same problems presist <ss2>well decent. It’s just a tree. <lfam>But, it seems to have no generic install procedure, and can only create DEB or RPM packages <lfam>Maybe I'm wrong but, like I said, it's a pain <lfam>It requires the unpackagd gstreamermm <ss2>they’re all drop down menu driven from trays. <lfam>Actually, I didn't try radiotray-lite yet. It's the radiostation program that requires gstreamermm <lfam>Yeah, a tray-based application is fine for me <lfam>I guess the easiest way forward might be to figure out how to install radiotray-ng <lfam>Like, I am I missing something? <ss2>I’m an mpd addict. Though the options are not limitless there. I haven’t seen a decent shoutcast browser in years though. But seeing from the pictures from radiotray, etc., Cantata shows such menues to go through. <lfam>I see that Nix has a radiotray-ng package. I can copy what they do <ss2>that site’s such a cool idea! <antonio79onFr>ngz: well,... I already made it compile with standalone packages, strangely something broke the system.... but what? Anyway, I would like to thank you for your help... i think the discussion merits to go to a email list. I already requested to participate in the guix email list before, but I think I was never accepted <lfam>antonio79onFr: Anyone can join the Guix mailing lists. You don't need permission <ngz>antonio79onFr: You're right, I can reproduce your issue. <ss2>I’m looking for an option to fix talloc in samba. Unfortunately I’m a bit stuck there. <ss2>lfam: should I open a ticket? <lfam>ss2: Did you try googling your error message? <lfam>That usually finds previous discussion of most bugs <roptat>how can I refer to the cross-gcc now that we got read of labels? <notmaximed>roptat: is this in #:configure-flags or in phases or ...? <notmaximed>If in phases, you can look at 'inputs' or 'native-inputs' as appropriate <ngz>antonio79onFr: I think I get it. I thought texlive-latex-base would provide fonts, but they are provided as native inputs only. <notmaximed>(assoc-ref native-inputs "cross-gcc") or (search-input-file native-inputs "/bin/TARGET-gcc") or something like that <notmaximed>There's also #+(this-package-native-input "cross-gcc"), but that doesn't work for implicit inputs. <roptat>I tried (or (assoc-ref inputs "gcc") (assoc-ref inputs "cross-gcc")) but this is #f in a cross-compilation <notmaximed>I don't think the native-inputs/inputs distinction is new? Though possibly the input labels have changed. <lilyp>it's not new, but certainly confusing with "this-package-native-input" <lilyp>go ahead and try it; I'll wait for you to fail <nckx>antonio79onFr: Which mail did you send and to which address? <roptat>so (or (assoc-ref native-inputs "gcc") (assoc-ref native-inputs "cross-gcc"))? <ngz>antonio79onFr: I don't know. I'm just grasping at straws at the moment. <nckx>How can I get the value of ‘guix system build --system=THIS system.scm’ inside system.scm? (%current-target-system) remains that of the host. <notmaximed>--system is ‘fake’ QEMU-based emulated native compilation <nckx>* (%current-system) remains that of the host; typo. <nckx>But sure, it's emulated. <antonio79onFr> ngz: I checked here and texlive base has the cm and cm-super packages as propagated inputs <lilyp>perhaps %current-system is only bound inside the evaluation of (operating-system ...)? <notmaximed>roptat: Could you share what you currently have? <nckx>Hm. You mean on the build side? That was my suspicion as well. <lilyp>meaning you can't meaningfully evaluate it elsewhere, unless you thunk it <antonio79onFr>well, I will try later to describe this isseu in the email list <roptat>ah I wasn't building the package I thought about... <lilyp>nckx: just a hypothesis, but try it <nckx>I am, thanks, but it's a pain. I thought there was an obvious way I was missing. <roptat>so (or (assoc-ref native-inputs "gcc") (assoc-ref native-inputs "cross-gcc")) returns something when cross-compiling, but #f otherwise <notmaximed>roptat: Replace the first 'native-inputs' with '(or native-inputs inputs)' <notmaximed>For what I presume are historical reasons and/or inertia, 'native-inputs' isn't set when compiling natively <roptat>mh, to be fair I don't know what I'm doing. What's the difference between inputs and native-inputs in that context? <notmaximed>Maybe something to change in the next core-updates (i.e., also set 'native-inputs' when compiling natively, even if simply to 'inputs') <notmaximed>the difference: native-inputs corresponds to the native-inputs of the package, + some implicit inputs. Likewise, inputs corresponds to the (non-native) inputs of the package + some implicit inputs <lilyp>roptat: you need to duplicate those with inputs instead of native-inputs currently <notmaximed>native-inputs vs inputs: The difference is important when cross-compiling. <notmaximed>native-inputs are compiled for the system the package is built on, <notmaximed>whereas inputs are compiled for the system the package will be run on <lilyp>I agree with notmaximed's suggestion here, it seems to make the most sense <roptat>I know the difference when declaring a package, but I was confused because i thought it was always inputs in phases <nckx>I thought --system set the parameter for the entire evaluation (including host-side) but I was wrong. <lilyp>I'm pretty sure the services field ought to be thunked as are e.g. package inputs <nckx>Yes, but that only works ‘in-line’. <nckx>Thunking is great but won't let you keep that list as-is. <nckx>Possibly due to my being primed by the mess that is %base-initrd-modules last week I'm starting to hate this fragile web of mere lists and other false friends that don't actually do what you expect. <lilyp>I'm not sure what I'm missing here, but I think you can just wrap it in a pair of brackets and apply it as function everywhere, no? <lilyp>oh yeah, %base-initrd-modules poked me as well <nckx>That's what I suggested above. I don't know what you're missing. <nckx>I don't think you're missing anything, FWIW. I think you see the mess clearly. <lilyp>I think I need to go to bed. <lilyp>Dream up some Greek letters. <nckx>Alright. Thanks for the help, confirmation, and sympathy! <lilyp>Good night and happy hacking :) <jgart>Does anyone know of a tool/way to copy a guix package from one module to another module (destination possibly in a separate src tree)? <jgart>I'm just brainstorming an idea for how to achieve this in a more automated manner <jgart>The syntax for the cli might look like this `guix copy-module -L . emacs-foo guix-channel/packages/my-emacs-packages.scm` <roptat>ok, I figured it out it looks like I can cross-compile libcxx now <notmaximed>(guix upstream) (or (guix packages) or maybe (guix lint), not sure about where exactly) has some code for locating the source code of a package (including the line number) <jgart>It would just append the package to the end of the file or wherever is convenient/easier to implement *nckx gives up, just makes the unexported thing a procedure, yay functional programming. <roptat>had to fix CROSS_CPLUS_INCLUDE_PATH instaed of CPLUS_INCLUDE_PATH as it's done now, when cross-compiling <ngz>Hmmm texlive packaging is hard. <nckx>jgart: The interesting thing would be auto-importing modules IMO. <nckx>No idea if that's possible, just dreaming aloud. <jgart>but this is a different idea to that one <Guest42>any idea why images generated using `guix system image` dont work with qemu or ventoy? <Guest42>says something about image not supporting uefi <lfam>They should definitely work with QEMU <nckx>jgart: Not the way I read it: ‘copying’ a working package implies copying at least its ‘closure’ of module imports. Otherwise it won't work. <lfam>Guest42: Well, I did it a few minutes ago, so there must be an answer between "yes" and "no" <jgart>nckx, I'm thinking something dumber than that <lfam>Please share what you did and how you started QEMU <notmaximed>Guest42: there's "guix system vm" for creating VM images <nckx>jgart: Oh, never mind then. <lfam>I used this command Guest42: < guix system image -t uncompressed-iso9660 --label="GUIX_x86_64-linux-leo" --system=x86_64-linux gnu/system/install.scm> <jgart>I mean just copying the package definition <jgart>without it's dependency trail <Guest42>im generating an image from my config <lfam>And then I use it with something like this: <lfam>qemu-system-x86_64 -m 1024 -smp 1 -enable-kvm -nic user,model=virtio-net-pci -boot menu=on,order=d -device virtio-blk,drive=myhd -drive if=none,file=guix-system.img,id=myhd -drive media=cdrom,file=my-image.iso <notmaximed>Guest42: If you use 'guix system vm', guix will generate QEMU's command line options for you (IIRC) <lfam>`guix system vm` creates immutable VM images. It's not comparable to `guix system image` <notmaximed>Though the output of "guix system image" should be usable as well. <Guest42>like i need a vm i can update and all <jgart>nckx, It's like a cp that knows about guile modules and package definitions. But now that you brought that up I realize some gotchas that I have to work out <lfam>Guest42: Those instructions give you that <lfam>If you'd like assistance, please share (on https://paste.debian.net) your config.scm, the command you used to create our ISO, and the QEMU command you tried to use to run it <lfam>Otherwise, "it doesn't work" doesn't give us much to go on <nckx>jgart: I definitely didn't mean ‘oh, A is boring, you should be trying B instead’! I just thought meant B here :) <jgart>I think there might be a dumber way that will get me 70% of the way and that might be enough to wane my motivation to try implementing this <jgart>nckx, What you had me realize was that I'd like to copy over any dependants to the channel which are not part of Guix upstream but were maybe committed as separate commits <jgart>So, I'll have to have a way to solve that <jgart>I want to specifiy just the main package and any required deps that are not in upstream and are not currently in the custom channel in order to copy them over to the custome channel <jgart>anyways, I'll think about this more to elucidate some things for myself <roptat>when inheriting a package, what's the cleanest way to replace an input? <roptat>I inherit from a package with say 10 inputs, and I want to change only one of them <florhizome[m]>nckx: coming back to my error before, what could I do to look what would be the problem with guile? <jgart>What's the easiest way to download al the irc logs for #guix in some form of plain text? <jgart>I'd like to do the same for guix-devel but I imagine that would be in mbox format? <notmaximed>Possibly exception.sh can be patched to set -rpath <jgart>notmaximed, I have a feeling there is a better way <jgart>well sorry l2md would be for guix-devel <jgart>notmaximed, you're thinking to wget the html? <notmaximed>Yes. Also, maybe logs.guix.gnu.org supports plain text (after setting Content-Type appropriately). <jgart>notmaximed, So, I guess a script that does that? <jgart>decrements and knows about datetimes <phodina[m]><notmaximed> "Possibly exception.sh can be..." <- Thanks, I'll look into that <jgart>decrements by datetimes I meant <jgart>not sure what you mean, by takes care of IRC logs <jgart>you mean the underlying system? <notmaximed>The system that listens on #guix and generates the log. <jgart>like there is for guix.gnu.org website <jgart>where did you find `bayfront-log`? <nckx>florhizome[m]: I'm not sure. <jgart>well, one hack for sure would be using the datetime idea I mentioned above <nckx>So bayfront is just a ZNC instance running on Bayfront. <jgart>It might not be the best way <jgart>but it would work. Might be needless work though <nckx>So the logs *are* plain text. <jgart>nckx, so you think I should just try writing a script for the method I described above? <nckx>I'm still reading the backlog. <nckx>I'm sure I'll get the point. <jgart>that's my thinking so far on how to scrape the logs to plain text <jgart>the search box doesn't seem to find everything reliably <jgart>I'd prefer to just grep the logs from 2021-2013 <nckx>The search relies on an indexer (Mu IIRC) which is fabulously performant when it works but is frequently broken. <nckx>Your ‘generate plausible dates’ idea is fine but seems uneccessary. Just run a recursive wget on the front page, it lists literally all the dates of interest. <jgart>Ye, others have complained to me about not finding things in the logs that they know existed at one point <jgart>so the search does not acurately find it <nckx>That is *if* scraping is the only option, which it shouldn't be. <jgart>nckx, cool so, probably a wget one liner should do the trick... <nckx>We have the text logs. We then reformat them for Web viewing. No reason not to expose both. <jgart>That would be cool to expose both <jgart>I think an easier way for new users to get the mailing list archive in mbox would be great too <jgart>or some docs about how to do it <nckx>But your mention of ‘source code’ above implies you think this is far less of a spaghetti string operation than it really is. Last I looked there wasn't even a ZNC service; it was just running under rek ado's screen instance :) <nckx>Ah, goggles is the name of the Web UI. I was drawing a blank. <nckx>It's in maintenance/hydra/goggles.scm jgart. <jgart>oh ok, so it's using xapian for search... <jacereda>OTOH, the patch creates a mbpfan.scm, is it better to have it in its own file or should something like that go in linux.scm? <notmaximed>I don't think linux.scm would be the right place, because this doesn't seem linux-specific: if the Hurd supported macbook hardware, then presumably mbpfan could be ported to the Hurd. <nckx>I agree with notmaximed. <lfam>Also, that patch hasn't been tested according to its author <lfam>So, somebody needs to test it <nckx>‘Happens to only work/build on Linux’ is not an excuse to litter linux.scm with unrelated stuff. <jacereda>I can test it if someone tells me how :) <lfam>I also see that the v2 patch didn't make all the requested changes <jacereda>in fact I was unable to find the v2 patch in the official mailing list archives <jgart>jacereda, If you'd like to add it to GuixRUs (community guix channel) as a pre-release while we wait for upstream to review feel free to send a patch and I can review and merge/test it soon if upstream takes longer to review: https://git.sr.ht/~whereiseveryone/guixrus <jgart>jacereda, Or, add it in your own channel while you wait is another option <jgart>and report back any fixes you might make that can be used by upstream <lfam>If you are able to apply the patch and test it that way, let us know jacereda <lfam>Otherwise I'll see about making a Git branch you can pull from <jacereda>do I need to create a channel or can I just have it where I keep my config.scm? <jgart>jacereda, You can also have it in a local channel that is offline. <jacereda>lfam: thanks, how did you find it? somehow the search results for 'mbpfan' didn't show that in my case <lfam>jacereda: I looked it up in my email client and saw that it was fromNovember 2021. So I went to the guix-patches archive for that month <lfam>The search feature on lists.gnu.org doesn't work very well <nckx>Lol. /var/cache on bayfront is littered with: logs.xapian/ logs.xapian.2021-02-19.broken/ logs.xapian.broken/ logs.xapian.broken2021/ <ss2>lfam: I did have a look, and had tried building with "--bundled-libraries=none", or =!talloc,!tevent, which didn’t help so far. It is getting late now too. Gonna have a second look at this the next days. <nckx>And you can't just delete the database, no sir: terminate called after throwing an instance of 'Xapian::DatabaseOpeningError' <jgart>that might be the thing to do for the guile addicts who want to scrape guix-devel <nckx>vagrantc: Now imagine I had to ask *after* reading that. <vagrantc>basically dumps mail into a git repository and provides soem searching interfaces <vagrantc>still don't quite wrap my head around it <jgart>I usually prefer people to tell me, story of my life `(and jk (not jk))` <Kabouik>lilyp actually there's mainly one appimage I needed and one I could potentially ditch, but if I can't run it, that's going to cause me headaches. I see robin said one solution would be to make a flatpak containing the appimage, but I assume it's not straightforward, may not fully work, and may not be done on Guix since I couldn't even extract the appimage there <Kabouik>patchelf and the extra non-trivial steps are a bit overwhelming <nckx>Can you patchelf an appimage, I was just about to ask? <nckx>And why didn't the extraction work? <robin>Kabouik, yeah, the idea was basically to use flatpak as an FHS-system emulator. didn't end up helping in my case as it was basically a proprietary package manager, but if it's a standalone application i think it would work <ixmpp>Yes, you can i think, but you will then have to extract it and patch the resulting nested binaries <robin>Kabouik, also, is running it in a VM of another gnu/linux distro an option maybe? <nckx>ixmpp: Was that in response to me or robin? <nckx>Thanks. I meant the appimage itself, which is some kind of self-extractor that (apparently) failed to run, not the contents. <Kabouik>No it's not possible to run it in a VM robin because it's a cloud computing app that streams a VM, and basically I can't start the app in another VM if I remember correctly my attempts years ago <robin>nckx, appimages themselves are basically statically-linked self-extracting archives (except they...dlopen libfuse or something instead of extracting the embedded FS image, iirc?) so it's tricky. i think i had to set the interpreter and also set LD_LIBRARY_PATH so it could dlopen libraries, *then* there's a magic extract-contents option that extracts the actual files (including the binaries you'd want to patchelf) <Kabouik>nckx --appimage-extract was just failing with "./ShadowBeta.AppImage does not ecist or could not be executed" <nckx>robin: Right, I was wondering if one could extra-special-file onself into a barely FHS-enough situation for that to work. <nckx>But ‘static binary that dlopens fuse’ is a punishable offence oh my jeez. <Kabouik>One problem with the flatpak trick robin is that appimages auto-updates all the time and updates are mandatory, because basically the stream to the distant VM is always being optimized <KE0VVT>A lot of work, just to get my laptop to suspend when I close it and unsuspend when I open it, and lock. <nckx>Honestly, this is starting to sound like malware. 
