<sophrosyne>yep looking through the logs it seems like this isn't the first time someone has brought up that you can't extend the home-fontconfig-service-type <Kabouik>Any idea what could be wrong? https://0x0.st/oiw8.png This is `guix pull -c 2 -v 3`. I did that after trying `guix pull` and seeing stuck at the "check" stage ob "ruby-byebug" for several days. It's on a phone so I thought it could maybe be hours, but several days (and replicated 3 times to make sure) was weird, and -v 3 shows this issue. <Kabouik>It's Guix package manager, not system. The system is Debian Sid (LXC container). <nckx>Maybe that's just how long it takes? <nckx>Horribly, none of the berlin aarch64 build nodes seem functional. <sam_>sometimes tests just hang. <sam_>Especially within sandboxes... <sam_>you can see it's tried and failed to do socket bits which is probably related <sam_>sometimes stuff handles failure poorly <sam_>i don't think you should give it any more time <nckx>What does the image say? <nckx>Kabouik: You could peek at the process tree, see if anything's using CPU, strace a few test processes to see if anything's happening, but it doesn't look good. <sam_>(this would still be a valid bug, fwiw) <nckx>Some tests might need to be disabled on aarch64. <nckx>I'm building it here and it only spends a very brief time after ‘Running’ before it starts printing a whole lot more. <Kabouik>If there is any way to disable those tests, I'm all ears, but I was under the impression checks are mandatory with guix <nckx>Not mandatory, but disabling tests changes the hash. <nckx>And of course maintaining a custom package without tests and input-rewriting it everywhere takes some overhead. <Kabouik>That'll make duplicate symlinks every time I guix pull, right? <nckx>I don't know what you're referring to; what I meant was you'll never get substitutes for anything that (transitively) uses the modified ruby-byebug. <Kabouik>I see (I think), disabling tests is an issue then <Kabouik>> nckx: I'm building it here..: for me the stall during byebug check is reproducible <Kabouik>No worries, I'm replying now because I'm here but am always connected so I'll see your comments later when you are back (please ping me). Is that with an lxc container too? <nckx>qemu-binfmt on my laptop. ***califax- is now known as califax
<lfam>I recommend a choice between 2 options <lfam>First, you could just use the Git repo from Debian <lfam>Second, you could make a Guix package with (source #f) and put each font URL as a native-input to the package <lfam>I will find an example of that <lfam>If you choose option 2, I don't know if you would have to use the trivial-build-system, or if you could still use font-build-system <Karthik[m]>lfam: thank your for your thoughts, I feel using Debian's repo would be easier, I will attempt it. <lfam>Yes, it will definitely be easier <lfam>But, the 2nd choice is more correct. We will accept either way though <dumbdemic[m]>Captains Log: 12 hours 28 min into rust build hell upon trying to install virt-manager with `guix install virt-manager` <lfam>dumbdemic[m]: Do you intend to build everything from source, rather than use pre-compiled binaries? <dumbdemic[m]><lfam> "dumbdemic: Do you intend to..." <- Substitute server was freezing earlier and I decided to try a different substitute server (--substitute-url="https://bordeaux.guix.gnu.org") "progress" is now possible but the ensuing rust build hell wasn't a great alternative 😞 <lfam>If you want to stop building and use the ci.guix.gnu.org server again, your previous builds will not be wasted <lfam>It's weird that bordeaux wouldn't have these substitutes, but that's another story <lfam>But, it's not a great sign that those substitutes are missing from bordeaux. It's likely you'd have to build a lot more too <lfam>There *are* intermittent issues with connectivity to the datacenter hosting ci.guix.gnu.org. We're aware of it and it's being investigated <nckx>Does bayfront not run Cuirass? <lfam>Not sure, but I think it runs the Guix Build Coordinator <nckx>Well, bed time. Good night. <apteryx>dumbdemic[m]: even with the network issues, it's probably much faster to run your command in a loop until it succeeds than building from source <lfam>Agreed. I've done that myself in times like these <lfam>The server *is* working in a degraded state <gnoo>i always need to do that. while ! guix pull ; do sleep 2 ; done <lfam>Always? Sorry to hear that. That's definitely something we want to know about <gnoo>yeah, even while installing about a month ago <lfam>I'd say I only have issues every couple months <gnoo>it always errors with something related to TLS <lfam>Make sure to install the key, mentioned on that web page, dumbdemic[m] <lfam>Does anyone know if there is a bug report for the TLS errors? <lfam>Also, can you say where in the world you are gnoo? I do have intermittent but recurring issues with SSH access to the server in question, from the eastern US <lfam>I have wondered if the datacenter's peering is not quite ISP-grade <lfam>The datacenter is operating by a research institution, not an ISP or a company that only runs the datacenter <lfam>And, the datacenter is in Berlin, Germany <apteryx>lfam: I think there is one about a TLS error yes <apteryx>but I suspect it may have to do with slow local IO, that times out the connection, or similar. <dumbdemic[m]>nckx: lfam Thanks for the help! I got virt-manager installed in 5 min with the "https://guix.tobias.gr" substitute server. Building virt-manager from source was definitely not the move lol 😄 <cbaines>lfam, on bordeaux.guix.gnu.org, at least for x86_64-linux and i686-linux, it's still catching up from the core-updates-frozen merge <cbaines>it's doing pretty well for other architectures though <vagrantc>other architectures doing well, that is... <cbaines>I'm sort of talking relatively, ci.guix.gnu.org pretty much only has substitute availability for x86_64-linux + i686-linux at this point <vagrantc>it's been a while since i tried updating an aarch64... i think shortly after the merge <cbaines>for reviewing patches and branches, I'm thinking of ways to review build reproducibility using just one Guix Build Coordinator instance that builds something multiple times <cbaines>that might at least help with assessing reproducibility, but there's still value in being able to compare things between substitute servers <vagrantc>we could maybe scrounge some machines hosted on reproducible-builds.org to give you another dataset to work with <vagrantc>could even run it on debian to give it a little more of a foreign environment :) <vagrantc>e.g. to check reproducibility even when running on a foreign distro vs. guix system <cbaines>yeah, I am interested in doing that kind of testing, since there may be some issues when building against non-Guix kernels <vagrantc>cbaines: i could definitely throw some time into it ... i was orginally just panning on doing a whole archive build periodically (e.g. released versions) and just basically doing "guix build --no-substistes" on everything available <vagrantc>and then making results available via guix publish ... <cbaines>depending on exactly what you're trying to do, using the Guix Build Coordinator might be beneficial <vagrantc>i was just thinking of the laziest, easiest thing i could get running :) <vagrantc>stick that in a weekly cron job and see what happens <vagrantc>about how much dis space does a world rebuild involve? <cbaines>I'm not sure it's actually that much <cbaines>guix weather says the x86_64-linux substitutes from bordeaux.guix.gnu.org are 130,135.5 MiB (~16GiB) uncompressed <cbaines>just ignore the uncompressed number for ci.guix.gnu.org <cbaines>I forget which bug applies, but some of the narinfo's have an incorrect value in them <vagrantc>i've got a machine with 1TB or so unused ... so that sounds doable <xelxebar>query-path-hash from (guix store) is confusing me. Running it on a random tar.gz in the store gives a different base32 than what `guix hash' outputs. <abrenon>(I've just answered my own question trying to write it down here so thanks everyone !) <abrenon>xelxebar: I don't know but guix/scripts/hash or guix/hash don't seem to use (guix store)'s query-path-hash so why would you expect the results to be the same ? (the behaviour of guix hash is still confusing to me) <xelxebar>abrenon: That's a good point. It's hashing a single-file store object, so I guess they're using different algorithms? I dunno. Still find it kind of surprising. <xelxebar>Looking in guix/scripts/hash.scm, it's using port-hash? I'm unable to discern how I could perform the same hash from the repl. <abrenon>port is the term for open files if I'm not mistaken, so I suppose it has to do with call-with-port or something <fproverbio>does eog fail to build for anyone? getting "no such file or directory libportal/portal-gtk3.h" when doing a system reconfigure <xelxebar>abrenon: Yeah, that'd be fine, but I'm unable to find *where* port-hash is coming from. Feel like I'm missing something really dumb. <abrenon>I have no idea where this is defined… it doesn't appear to be defined in guix' source code, so I'd venture as far as hoping it's somewhere in (ice-9 binary-ports) ? <notmaximed>in "guix repl": ,m (guix scripts hash) <newline> ,apropos port-sha256 <newline> --> (gcrypt hash): port-sha256 ... <abrenon>"enter" as in "now I can see everything the module can see from inside" ? <notmaximed>There's a bit of documentation in the REPL, try running ,help in the REPL <notmaximed>abrenon: yes, and you can do (set! some-variable ...) to overwrite things <notmaximed>,m: Enter the module, ,import: import exported bindings <abrenon>so is ,import like (use-modules …) ? <xelxebar>abrenon: Just an inference from looking at hash.scm's use-modules. <civodul>rekado: upon "guix time-machine --branch=wip-texlive", i get "warning: texlive-luatex-lualibs is deprecated" <civodul>must be because the deprecated package is in the closure of Guix? <vldn>how to use or include guix http-client on a foreign distro? ***Guest2835 is now known as roptat
***aya is now known as gyara
<xelxebar>Ah, so for a single file, `guix hash' boils down to (bytevector->nix-base32-string (file-hash (hash-algorithm sha256) <filename>)) <xelxebar>So nix uses some funky encoding scheme instead of RFC 4648. Hrm... <xelxebar>vldn: Thanks. I'm slowly reading through the paper. Haven't gotten very far yet. I guess you're hinting that this is addressed directly there? <vldn>searching the right page :D there was something about the encoding <vldn>why there are just lowercase chars etc. ***aya is now known as gyara
<xelxebar>nckx: Why do you know that off the top of your head?? <nckx>xelxebar: Re case: you only need 32 characters so there's no need to be case-sensitive. And uppercase would just look horrible? I have citations for neither, just common sense. *nckx was just walking by, though; AFK. <vldn>i try to include some guix guile scripts like the http-client on a foreign distro via a guix binary installation but guile keeps telling "no code for module (guix http-client)" ***aya is now known as gyara
<allana>Hi Guix! I have a question about defining packages. Say that I am developing a piece of software, and I have a guix.scm with a package definition for my software. For the "source" field of the package, is it possible to refer to the local git repository? Any examples out there? Right now I am using local-file and pointing to a source tar.gz that I need to remember to build before I invoke "guix shell". <xelxebar>"... the alphanumerics excepting the letters e, o, u, and t. This is to reduce the possibility that hash representations contain character sequences that are potentially offensive to some users." <xelxebar>Interesting. That's a solid motivation and answers a lingering question I had :D <florhizome[m]>What definitely is possible is changing the source from the command line, take a look at ––help transform <xelxebar>vldn: Is the module in the guile load path? <vldn>i just run the script within the the guix-profiles guile <vldn>where do i find the guix system modules? <vldn>i expected it to be automatically loaded <abrenon>allana: you don't have to point (local-file …) to an archive, you can perfectly point it to a directory, with #:recursive? #t <abrenon>(define %source-dir (dirname (current-filename))) <abrenon>then (local-file %source-dir #:recursive? #t) <allana>florhizome[m]: Ah, will try file:// of url-fetch, Thanks! <abrenon>you can even pass a #:select? predicate to filter out some files (like, if you're working from a git repos, you may want (git-predicate %source-dir) as a value for this keyword parameter <abrenon>(see guix/gexp.scm for the definition of local-file, and guix/git-download.scm for git-predicate) <abrenon>florhizome[m]: no I don't reckon so, it's still, the current state of the folder when you trigger the build <rekado>civodul: I just changed the only reference to texlive-luatex-lualibs (renamed it to texlive-lualibs) on version-1.4.0 <abrenon>git-predicate is there to avoid your copying the whole repos history to the store each time you build (which happens when you use url-fetch with a local path <allana>Thanks for the help florhizome[m] and abrenon! <allana>I ended up using the %source-dir approach for this one. <civodul>rekado: could we merge the texlive-relevant fixes on "master"? <civodul>(i've been trying on and off to compile a LaTeX document but i'm no longer sure which strategy to follow) <jlicht>civodul: wasn't that a world-rebuilding change? <civodul>dunno, i didn't follow the discussions <civodul>but if it's gonna end up in 1.4.0, it'd be nice to have it in master too <abrenon>wow sneek certainly seems to have some favourites around here <florhizome[m]><allana> "I ended up using the %source-dir..." <- I mean it’s clearly the better one and I will try it too <vldn>sneek: guile help define <rekado>civodul: it’s a world rebuild, so it won’t be on master <rekado>it affects texlive-bin and texlive-latex-base, so it affects everything <rekado>civodul: the strategy to build a document shouldn’t have changed. It’s just that with every TeX Live release files may be moved to different packages. <jlicht>phf-1: if this happened about 15 to 5 minutes ago; I had this too, a simple retry actually worked fine <phf-1>Well, I tried again and it works now... <rekado>the MDC is still diagnosing site-wide network problems <apfel>hi there, can somebody tell me what the environment variable was called which is used to include local package definitions? <apfel>never mind, GUIX_PACKAGE_PATH is what i am looking for <vldn>is there a web api for the guix build coordinator / data service @ data.guix.gnu.org ? <vldn>like the minimal api for cuirass <cbaines>vldn, the Guix Build Coordinator does have an API, although it's usually only accessible from the same machine, since you can use it to do things like submit builds <phf-1>Noob question. I'm search for the `ps' program. `guix search ps' or `guix search process status' does not give any useful result. How do you search for programs? <cbaines>vldn, the Guix Data Service is designed as an API with a web interface, you should be able to request JSON from all of the pages <vldn>is there an example how to request specific parts of the data service? <cbaines>vldn, what specific bits are you interested in? <phf-1>procps is what I'm searching for but I had to go through `dpkg -S /bin/ps' <vldn>querying successfull built packages and evaluations ***wielaard is now known as mjw
<vldn>and getting the associated commits <phf-1>"querying successfull built packages and evaluations and getting the associated commits" do you have a pointer to how to do that? thx. <cbaines>vldn, cool, well let me know how you get on. I'm happy to add new pages/API endpoints to make things easier <vldn>i'm actually trying to do it right now phf-1 <cbaines>vldn, are you looking at this to avoid guix pull'ing to a revision without substitutes? <phf-1>Will write a small piece about that <cbaines>vldn, one suggestion I would make, perhaps just use the Guix Data Service as a source of the outputs for a particular revision <phf-1>or maybe improve the cookbook? <vldn>but try to implement it with the data service <cbaines>vldn, once you've got the outputs, then just check if substitutes are available from them directly with the substitute servers <cbaines>unfortunately it's quite slow, but I think that can be addressed by omitting the output consistency information (which I'll look at adding the option for) <cbaines>but apart from the slowness, that might be perfect for your needs <vldn>aah thats what i was after, really insightful with the whole query string!! <vldn>cbaines: (which I'll look at adding the option for) just let me now :) would be useful ***califax- is now known as califax
<aadcg>does anyone have a package definition for the emacs pretest? <civodul>rekado: so i'd say we can merge the texlive world-rebuild branch once binaries are available; i'm in favor of keeping version-1.4.0 close to master <civodul>by strategy i meant that i'm not sure which branch to use to get it done, or whether to use the big texlive package :-) <Nazar>hello there, i want to submit a few new packages to guix, is there any step by step manual for that ? <aadcg>Nazar: take a look at this info node: (guix) Submitting Patches <rekado>civodul: we haven’t started building wip-texlive yet. I was going to do this later, but then version-1.4.0 rolled along and I thought we could save ourselves a big rebuild cycle. <Nazar>aadcg so in two words, generate patch and send it by email right ? <notmaximed>Nazar: "guix import" can be very useful for creating the package definitions <florhizome[m]><Nazar> "aadcg so in two words, generate..." <- You might want to runt „guix lint“ on them before sending. It gives you some tips in terms of style etc. <Nazar>thank you guys! will try to submit:) <abrenon>I cannot for the life of me figure how pandoc manages to find beamer themes <abrenon>it's relatively easy to package a latex beamer theme with copy-build-system, too bad it's so hard with the dedicated "simple-texlive-package" stub <efraim>I wanted to test building go with gccgo on aarch64 but I forgot how slow it is to build go <xelxebar>Huh, (guix monad-repl) isn't automatically loaded into `guix repl'? <rekado>abrenon: don’t use simple-texlive-package then. <rekado>just use the copy-build-system then <abrenon>I guess : ) but it's frustrating to see a tool not being able to use it properly while knowing that it's probably there for a good reason since it was devised by people who understand all this better <ennoausberlin>Hi. I wonder what is best practice to start a web application (django) automatically after reboot? <notmaximed>ennoausberlin: Maybe you could write a service to start the app? See (guix)Shepherd Services <rekado>abrenon: I added the simple-texlive-package procedure only to simplify some common patterns I noticed when packaging things. It doesn’t exist for any better reason :) <rekado>and it’ll likely change significantly or disappear completely with an overhaul of the texlive-build-system <abrenon>oh will it ? but doesn't it manage setting $GUIX_TEXMF correctly to make sure pdflatex finds what it needs ? <ennoausberlin>notmaximed: That would be possible. Are there any other methods? The system wide mcron might be an option, too. But I did not found a job-specifier for once-at-boot time. <rekado>texlive-bin has a search path setting for GUIX_TEXMF. That’s all that’s needed. <rekado>the default texlive config is defined in terms of GUIX_TEXMF; installing texlive-bin into your profile (or rather texlive-base, which propagates it along with the minimum set of packages you’ll need) causes the variable to be set and thus all texlive packages to be found. <rekado>using the modular TeX Live is simple: install texlive-base and whatever package your document needs <abrenon>now I wonder what I did to believe that : ( I needed that clarification <rekado>I’ve never used the nginx plugin <rekado>I only ever use standalone or dns challenges <phf-1>Ok. Will try these then, thx. <abrenon>if I enter a shell with pandoc and my package, pdflatex complains it can't find my beamertheme <abrenon>if I enter with pandoc, my package and texlive-base, it complains it can't find beamer.cls ^^' <Guest85>Would you recommend creating a top level btrfs subvolume for /gnu? Is it likely that I want to separate the snapshots of /gnu? <abrenon>which brings me back to my first question: how does pandoc find beamer themes ? <rekado>what provides beamer.cls in your environment? <rekado>have you tried adding texlive-beamer to the environment? <rekado>because that’s what is supposed to provide beamer.cls according to the tlpdb <abrenon>no, I haven't tried that, it's always magically worked for me so far with the included beamer themes <abrenon>now I'm trying to add one and it's proving harder than I thought <abrenon>hmmm, I think I'm too much confused, I thought everything was a matter of hooking the output path to $GUIX_TEXMF (because I thought of python packages) <nckx>Guest85: Why do you want to snapshot /gnu? <abrenon>and then you taught me that it was different <abrenon>honestly I have no idea how it works, I know less each minute that I spend working on that ^^' <abrenon>I've entered a shell with only pandoc, I can compile my beamer presentation but beamer.cls is not within the profile (if I'm to trust find) <rekado>abrenon: guix shell pandoc texlive-base texlive-beamer <Guest85>nckx: I new to guix. Is it likely that I wouldn’t want to snapshot it? <rekado>beamer.cls is provided by texlive-beamer, so you’ll need that package if you want beamer.cls <abrenon>hmmm but then how does pandoc finds it on its own ? I found no texlive-related package anywhere in its (propagated) inputs <rekado>why woudl pandoc need to find texlive things? <notmaximed>Guest85: guix has built-in rollback and transactionality features <rekado>let’s not get ahead of ourselves; you say that beamer.cls is not found. I showed you a way to make it available. <abrenon>because when it compiles to a beamer presentation, it uses pdflatex (and the error messages I get are LaTeX error messages) <abrenon>and you're absolutely correct, when I enter the environment you specified, it was there <notmaximed>And snapshotting /gnu separately from /home seems likely to cause problems, because ~/.guix-profile (indirectly) points to /gnu/store/[stuff] items <notmaximed>So if you rollback /gnu with file system features, then ~/.guix-profile becomes broken <notmaximed>Guest85: what is the purpose of backing up /gnu? <abrenon>and if I add my theme's guix.scm, everything is there ! : ) <Guest85>I don’t know which is why I am asking. <notmaximed>There's a non-backup reason to make /gnu/store (or /gnu? not sure) a BTRFS subvolume: compression <efraim>civodul: I'm seeing hash mismatches connected to the kicad upgrade <abrenon>ok, and then I need to manually add texlive-latex-geometry… it looks as though adding my package "broke" pandoc's magic to find everything it needs on its own, and from there I need to add everything back piece by piece <notmaximed>I don't how effective BTRFS compression is in practice. <nckx>Guest85: I'd say it's unlikely to be useful. If do want to back up /gnu and restore it later as a working store, you must make sure to snapshot /var/guix (or at least /var/guix/db) along with it. For that reason I'd advise *against* making them separate subvolumes since AFAIK that makes this impossible? You could play symlink tricks, of course, but otherwise snapshotting / and backing up selected parts of that seems like the better choice. <abrenon>rekado: thank you very much for your help ! it's not exactly clear, but a picture is forming and it's way less muddy <nckx>efraim: A ‘fix hashes’ commit was recently pushed, are you up to date? <nckx>Otherwise, kicad upstream is clearly drunk. <nckx>Guest85: The only reason to back up /gnu is to save downloads and/or rebuilds later. None of the contents are precious in that they can all be rebuilt from the ‘sources’ that are Guix, your package manifest, and your system configuration. <efraim>looks like I was a couple of hours behind <abrenon>ahahahah how could I miss that ? my own environment was providing pdflatex, not some dark magic within pandoc <podiki[m]>issues frontend is stuck again? (sorry if this came up earlier and I missed it) <aadcg>guix's website seems to be down <nckx>aadcg: The institute hosting the site has been having some trouble the past few days. <nckx>podiki[m]: Hm, example? This usually means rsync is stuck, but it's not even running now. <nckx>TBC, it's a scheduled task so that's not bad on its own. <podiki[m]>or new issues (like the lua-5.4 patch earlier today) <nckx>aadcg: By the way, it's not quite down. Some requests succeed (so refreshing the Web page or retrying the build eventually work). <johnjaye>like i can install it from an iso in virtualbox right <nckx>johnjaye: Guix is a package manager that builds free software packages, from source code, in a way that allows you to more tightly control their dependencies, and allows other interesting features like profiles, generations, and transactional rollbacks. It should run on any Linux [distribution]. Guix System is a GNU/Linux distribution built on the Guix package manager. <johnjaye>ok. someone said on a comment that it was the closest thing to a guile based linux distro since guix packaging is scheme <johnjaye>and i guess gnu guile died or never took off or something <nckx>(It was a stuck rsync, it was just immune to TERM. Dunno what that means, and if it's bad.) *nckx never kicks, only prods. *nckx occasionally KILLs. <mbakke>is it just me or is 'guix style' completely borked atm? i.e. 'guix style --input-simplification=always speech-dispatcher' does anything but removing input labels <podiki[m]>mbakke: after the update to style yesterday? <nckx>podiki[m]: That's spear-of-destiny level prodding. I charge extra for that. <mbakke>podiki: I think that's what may have broken it yes <johnjaye> 9 /* kill (cannot be caught or ignored) */ <rekado>johnjaye: first time I hear that GNU Guile has died. <johnjaye>well i guess the idea is it died then revived as guix? idk. is guix even baed on guile scheme or is it a different scheme <mbakke>oh, I needed to specify '-S inputs' explicitly <mbakke>the formatting looks like it could use some work <podiki[m]>I wanted to try out the new style today, I'll have to read that news entry/manual <rekado>johnjaye: GNU Guile was never dead. Not even close. <rekado>Guix is written in Guile Scheme. <johnjaye>rekado: i think his justification was gnu "died" or broke up and by extension guile as well. i assume it means active development <rekado>it’s not a new name for Guile or anything. *rekado can’t keep up with the obituaries <johnjaye>online projects are born live and die very fast. they're like favorite pets <gnoo>obviously he means we all died and are living in a simulation <rekado>johnjaye: it’s funny you say that considering that GNU predates ‘online’ for most practical purposes and is one of the longest lived free software ‘projects’. <nckx>johnjaye: It sounds like a bizarre assertion (…on the *Internet*??? I know!!), but then here we are, working on a GNU project, written entirely in Guile, so maybe we just didn't get the memo. <johnjaye>nckx: guix is the next generation is sounds like <rekado>next generation of … what exactly? <nckx>podiki[m]: It's still at the cleaners :( rsync didn't go gently. <rekado>these network problems are terribly annoying <johnjaye>maybe that's the beauty of it. we define what it is with our code. and so the circle continues <gnoo>johnjaye: guile is a language, guix is a package manager. completely different <gnoo>and it's not as entangled as emacs and elisp <nckx>Guix certainly revitalised interest in Guile but Guile wasn't dead before that. <podiki[m]>(issues front end is looking more current across the board now) <nckx>Although if you define ‘life’ as constantly chasing different features and goading everyone to target the git master branch of your compiler, as is currently a fad, I can see the confusion. <nckx>podiki[m]: Feel free to ping me or rek ado or so if this happens again. <nckx>rekado: I still think adding ‘timeout 1h --kill-after 5m …’ to the rsync command wouldn't hurt anything. Nor would a much shorter timeout, but the returns diminish. <nckx>Eh to the puppet configuration we feed into ansible for guix deploy, of course, yes, *cough*. *nckx 👀 podiki[m]'s watching. <nckx>rekado: Unlikely, but does MDC IT have any kind of status page or similar we could synergise? <phf-1>How to print logs with `herd'? <phf-1>is there an equivalent to `journalctl -fu service' ? <phf-1>ok, will check `/var/log/...' <podiki[m]>we have syslog and I see rsyslog was just added (but haven't tried it out) <notmaximed>... that's not 100% true, Shepherd services can ask to write stdout/stderr to some file, tpypically under /var/log/... <nckx>podiki[m]: Mind if I PM you to ask some Matrix questions? <podiki[m]>I have redirected my own local Shepherd service to syslog, which you can add a tag of sorts <rekado>nckx: the MDC doesn’t do synergies. <rekado>there’s just internal monitoring <nckx>rekado: Oh well. I'll just keep linking to your random IRC messages. <florhizome[m]>the publicly defined variable is gtkmm–3, but the names of all gtkmms are just gtkmm <rekado>florhizome[m]: guix build -e '(@@ (gnu packages foo) the-variable-name)' <rekado>or guix build the-package-name@the-version <mbakke>system tests are not working for me, creating 'partition.img' consistently fails with "Could not allocate inode in ext2 filesystem while populating file system" <mroh>./earth: file system full? <florhizome[m]>rekado but in a inputs list (new style) would I still go with the defined public variable or with gtkmm@3 ? <rekado>florhizome[m]: the variable name <rekado>there are package names (used on the command line interface) and variable names (used within Guix) <rekado>KarlJoad: it has a pipewire package <mbakke>mroh: file system is not full, and it happens on two different (Guix) machines <abrenon>mbakke: did you check full both in terms of space and free inodes ? <nckx>drakonis: Does PW run a system-level daemon (unlike, say, PA)? <mroh>mbakke: for me it fails in check-local FAIL: tests/texlive.scm <nckx>drakonis: I'd see more connection between the two messages if s/pulseaudio/ALSA/. <nckx>I'm not saying running as a system daemon is bad (it may well be better) but it's not a requirement to replace PA. <drakonis>but it does certainly replace pulseaudio but still has interop with applications that consume it <nckx>mbakke: Which single TEST could I run to reproduce that? <mbakke>nckx: 'make check-system TESTS=openvswitch' should do it <nckx>Today, I'll be build Inkscape, apparently. <nckx>Yeah. So. It's creating a 242-kilobyte disc image 😒 <nckx>*kibibyte, sorry, the difference is hilariously significant here. Still a tad small though. <nckx>Assuming it succeeds, LGTY? <mbakke>nckx: I'm curious as to why it doesn't show up in the CI. Kernel regression? <mbakke>not familiar with that part of the code and would defer to mothacehe if they are around :) <mbakke>or maybe file system related, I've only tested on btrfs and tmpfs <nckx>It'd be odd if we both ran the same kernel or even file system (bcachefs here), this happens within the image. <nckx>I don't think mothacehe wrote that bit. <nckx>I didn't notice the CI discrepancy. I'll try running it by hand on berlin. <nckx>Correxion: tmpfs. I'll try bcachefs although that really, really, really ‘shouldn't matter’ 😉 <nckx>Narrator: it didn't matter. <notmaximed>nckx: do you mind if I PM (about off-topic or not)? <nckx>I never mind unless it's for trollin'. And they don't usually ask. <nckx>mbakke: The last thing I saw before Sway crashed for unrelated reasons was that berlin creates a ~350K image >_< <notmaximed>nckx: I sent a PM, but I'm not sure if it was received because notmaximed is not registered <nckx>I assume you got my rambling reply. LMK if not. <rekado>oh, the texlive test is trivially broken; will push a fix. <notmaximed>johnjaye: Guix is neither pro-SystemD nor anti-SystemD. As I understand, the reason that Shepherd is used and not SystemD or SysV init or the like, is that with Shepherd, we can write all kind of things in Scheme (like most of the rest of Guix) ***roptat is now known as Guest4659
<the_tubular>There's still some cool feature in systemd that I don't know if you can use in guix yet <podiki[m]>if anyone is looking to review some (I think simple and quick) new packages: <lilyp>podiki[m]: "1-3" is a pretty weird version string, even more so if we reference it by commit <podiki[m]>lilyp: agreed, I wasn't sure and went with what is listed as "version" in the upstream AUR (arch user repo)...suggestion? <lilyp>for version, it's typically a good idea to use git-version if you're already using a commit <lilyp>as for the base, lemme check real quick <notmaximed>podiki: Could you check if the tarball ships tests? <podiki[m]>so maybe (version (git-version "1" revision commit)) where revision would be "3" in this case <notmaximed>(Sometimes the pypi tarball doesn't but the git repo does) <lilyp>yep, in this case AUR has a revision baked in <lilyp>that being said, I'm not sure whether this package accomplishes something that can't already be done in Guix system <podiki[m]>notmaximed: yes, I see test in the git repo, good catch <podiki[m]>lilyp: sure, I guess you could do this with special files in system config (using the xsession desktop file)? but I think this serves its purpose <notmaximed>podiki: It would be the first revision of xinit-xsession, so that would bre (git-version "1" "0" commit) <notmaximed>the not-yet-completely-merged git updater requires revision to be placed in the same let form as commit (let ((commit ...) (revision "0")) ...) <notmaximed>(technically it looks for other things but in practice it boils down to that) <notmaximed>Does this work on foreign distros, on Guix System ...? <podiki[m]>notmaximed: the xinitirc-xsession one? that would go in system profile, at least that's how I use it (so it is seen as a possible xsession for all) <notmaximed>For which login managers does this work (GDM, any, ...)? <podiki[m]>I suppose it would work in a foreign distro too (the desktop file goes in share/xsessions, the bash script in bin) <notmaximed>I would recommend documenting this a little in the description. <podiki[m]>I've tried it with gdm, sddm, lightdm (on arch, with original arch pkg) <notmaximed>Nevermind, I see that it's already in the description. <podiki[m]>for foreign distro, as long as xdg_data_dirs and path is set up I think it should work just the same; for Guix system I think that's why it should go in system config <notmaximed>FWIW you can replace (assoc-ref outputs "out") by #$output if you place #, right before (modify-phases ...) and import (guix gexp) <podiki[m]>yeah, I've been catching up on submitting old pkgs, mostly pre-new style <podiki[m]>since I'll change the revision on xinitrc-xsession I'll update to new style too <char>Hello. I made packages for several gnome-shell-extensions. Can I send all the patches in the same email or should they be separate. <podiki[m]>gexp help: for #:install-plan I found I had(?) to write #~'(("thing" "where")) but that seems weird <podiki[m]>trying #~(list .. didn't work; what is it about install-plan? <ngz>podiki[m]: This should be equivalent to #~(list (list "thing" "where")), shouldn't it? <podiki[m]>oh I need to put list explicitly at each level due to the #~ ? let me try <ngz>You can also try #~(list '("thing" "where")) <ngz>And pick whichever you prefer :) <ngz>char: If they are unrelated, they could go into different emails. <podiki[m]>ah yes, that too (thought I tried it but maybe missed a quote) <ngz>char: New bug numbers are cheap anyways ;) <podiki[m]>to maximize different things appearing together <florhizome[m]><notmaximed> "johnjaye: Guix is neither pro-..." <- And systemd simply could not be used with the hurd. <the_tubular>Also, can anything be used with the hurd as of now florhizome[m] ? <florhizome[m]>I‘m pretty sure there are services you could run headless in Hurd vms. But idk if guix has a graphical Hurd session. I haven’t looked at the hurd yet, I just know that Systeme is pretty linux specific. <podiki[m]>sneek: later tell notmaximed thanks for earlier, both patches updated <char>ngz, They are not related, but they are next to each other in the file such that the git-hunks overlap <ngz>char: You can remove trailing #T at the end of your phases. <ngz>char: Also `(("glib:bin" ,glib "bin")) => (list `(,glib "bin")) <char>ngz, Thanks, I'll fix those <Kolev>Where can I find `notify-send`? <podiki[m]>Gooberpatrol66: you should be able to see inside the container from outside (e.g. in another terminal or host file browser) <dcunit3d>how do i attach an arbitrary guix scheme buffer to a running geiser repl or `guix repl`? i'm trying to get hacking on scheme to feel like hacking with clojure/cider <ngz>raingloom: coeurl could use new package style (no labels in inputs and package-inputs). Also, its description should be a full sentence. 
