IRC channel logs


back to list of logs

*raghavgururajan updated Gajim (#46411) \o/
<dftxbs3e>lfam, rekado_, I may have a solution for the ports problem, you could use miredo to setup a 4to6 tunnel so that gets you an IPv6 address with all ports directed to you.
<dftxbs3e>It works behind NATs
<mroh>nckx: That's a lot of rebuilds for master (55050e54a987cd99b8477da1a4993e83adcca129), no? e.g. this ( was pushed to core-updates...
<nckx>I don't have that commit yet, lemme pull.
<dftxbs3e>Yep.. "Building the following 714 packages would ensure 1827 dependent packages are rebuilt:"
<nckx>I'm sure ‘guix refresh’ is right.
<nckx>Hmm, it rebuilds qtbase via xdg-utils.
<lfam>We should revert it, although it would be interesting to see how the build farm handles it
<nckx>I don't think there's a clever reason that it got to master.
<lfam>Ostensibly, we doubled capacity today
<nckx>lfam: There are people who don't use the farm.
<lfam>Alright, can you revert?
<nckx>It's not the end of the world to revert & ask civodul tomorrow?
<nckx>Good night y'allomundo.
<sturm>does anyone have a VM running in Gnome Boxes with outgoing network access?
<OriansJ>open call for those with PowerPC and RISC-V hardware to help #bootstrappable get a FULL Source Bootstrap for their platforms.
<lfam>OriansJ: I filed a request for early access to the upcoming BeagleV computer. My plan is to give access to people who want to port Guix to it, and that includes the bootstrappable community
<lfam>To clarify, it will be available for the work you mention, or for Guix porters
<lfam>Hopefully they pick me :)
<lfam>It's not the most powerful RISC-V computer available, but they solicited inquiries, so I inquired
<lfam>The HiFive Unmatched isn't really that expensive. Purchasing a couple could represent a valuable contribution to Guix
*raghavgururajan hit is head while sneezing
<lfam>Not too hard, I hope!
<OriansJ>lfam: fortunately we don't need access just someone to sanity check our work.
<raghavgururajan>lfam: Regarding our email conversation on getting commit access, what steps do I need to take?
<lfam>The guidelines are here:
<raghavgururajan>Ah cool!
<lfam>Something I've noticed is the frequent sending of patch revisions
<lfam>Like, if you had commit access, would you have committed the first revision?
<lfam>Or would you have iterated to some "final" revision before pushing?
<lfam>Like, it's good that the patches are being improved!
<lfam>When I got commit access, it changed my approach to writing patches. Since I knew that I could push them myself, I became more careful and tried to rely on the review process a little less
<lfam>I still seek review
<raghavgururajan>Ah yes, I'd be more careful and wait for additional review before I push something. :-)
<dftxbs3e>lfam, " I became more careful and tried to rely on the review process a little less" <- How I feel exactly.
<lfam>Cool, raghavgururajan
<lfam>Being able to push, it changed my mindset a little bit
<lfam>It's still important to seek review when you're unsure. Even the most seasoned contributors submit their patches for review, if they are not simple package additions or updates
<raghavgururajan>Also, frequent revisions of patches happened a lot with telegram. There were complications with upstream. Fragmented source-code and confusing configure flags.
<lfam>Yes, that's the submission I was thinking of
<lfam>I did assume it would be complex
<bqv>libgccjit isn't cached? D:
<bqv>Heck if I'm gonna be able to compile that in under a month
<raghavgururajan>> lfam‎: Like, if you had commit access, would you have committed the first revision?
<raghavgururajan>Oh I missed this message. No, I wouldn't have, as that was new pack-def and also a major change. I would only push directly if its a minor change like typos, updates, comments etc.
<bqv>Oh, also guile-emacs is still compiling *since over 40 hours ago*
<lfam>Sounds about right
<bqv>I think that one's a lost cause
<joshuaBPMan>bqv   I don't know when the last time someone worked on guile-emacs....
<wonko_the_sane>'guile-emacs' ? is that related to the plans Stallman et al had which included implementing elisp on top of a Scheme to be called 'GEL' ('GNU extension language', later renamed Guile) since like 30 years ago or something ?
<terpri>wonko_the_sane, inspired by those plans, yes
<wonko_the_sane>: D
<terpri>bqv, guile-emacs compilation is likely slow due to its continued use of guile 2.x (not due to any notable technical difficulties, just lack of time). guile's bootstrap process is extremely slow (3.x might be better, i haven't checked)
<terpri>guile-emacs shouldn't significantly slow down emacs compilation, though guile-emacs itself is really slow (correctness was the priority, not performance)
<terpri>iirc dustyweb has a partial guile-elisp rebase onto modern guile that will probably be the basis of the next guile-elisp update
<terpri>(and the guile half isn't usually difficult to update; i imagine they spent half their time writing proper ChangeLog entries for my commits :p)
***osjejuty is now known as rg
***rg is now known as gsjkdwkddw
<bqv>terpri: neat
***sundbry_ is now known as sundbry
<dftxbs3e>efraim, patch to disable checksum checking and generation (tested lightly on compiling cargo sources themselves):
<dftxbs3e>sneek later tell marusich it looks like guile-static-stripped does not work (in the bootstrap binaries), there's an erased glibc reference showing with ldd
<sneek>Got it.
<sundbry>It seems (ungexp) does not play nice with more complex data structures.. I am having a helluva time trying to get it to eval a list of alists for a shepherd service I am writing.
<wonko_the_sane>Has everyone seen this? - someone found a buffer overflow in screen
<wonko_the_sane>buffer overflow! makes me feel nostalgic
***nckx[2] is now known as nckx
<rekado>terpri: dustyweb’s rebase was outdated; I made a new one here:;a=shortlog;h=refs/heads/wip-elisp
<rekado>this fixes the timeout of the guile-emacs build but the resulting guile-emacs segfaults
<rekado>bqv: it is known that the guile-emacs package in Guix does not build.
<rekado>bqv: I would have updated it to use my fork of guile, but I got stuck trying to figure out why the resulting build segfaults.
<rekado>bqv: there really is no point in trying to build the package as is. It won’t work.
<efraim>dftxbs3e: it seems guile-3.0.2 builds fine on powerpc32, i'm up to jemalloc on my way to cmake-minimal with your glibc patch, using glibc-2.30
***apteryx is now known as Guest63552
***apteryx_ is now known as apteryx
***iyzsong- is now known as iyzsong
<fnstudio>hi, my guile toy project now comes with a guix.scm installer `guix package --install-from-file=guix.scm`
<fnstudio>well, that'd be the idea :)
<fnstudio>the command seems to work well and a folder gets created in `/gnu/store/`
<fnstudio>however, the project executable doesn't seem to be made available in my path
<fnstudio>so i assume i'm missing a step somewhere
<janneke>fnstudio: try: guix build --file=guix.scm
<janneke>and then look if the store directory is what you expect
<fnstudio>interestingly, local files are copied over to the following folders: `/gnu/store/.../lib/` and `/gnu/store/.../share/`
<fnstudio>janneke: sure, let me try
<fnstudio>janneke: i'm not sure what i should expect exactly, but the fact that there's only `lib` and `share` (and no, say, `bin`) seems a red flag to me
<fnstudio>it might be something more on the guile side at this point, than strictly guix related...
<fnstudio>well... i mean, something wrong in my way of structuring the package
<fnstudio>it looks like the package is structured as if it were a library...
<janneke>you should expect a (partial) unix root: bin etc lib share
<fnstudio>janneke: yeah, i was checking another package (eg emacs) and yes, i can see `bin` etc...
<fnstudio>janneke: now it
<fnstudio>janneke: now it's a matter of understanding if i'm missing something in `guix.scm` or whether i should restructure the guile package
<janneke>good :-)
<fnstudio>that's already quite a bit of progress, so thanks
<jlicht>hello guix!
<PurpleSym>Do we have a good solution for NPM packages on Guix yet?
<jlicht>PurpleSym: Not by any sane metric, no
<PurpleSym>jlicht: And a bad/insane/dirty solution?
<jlicht>PurpleSym: heh, there is a wip-node-14 branch floating around with a more recent node version, and a (buggy) recursive 'binary' npm importer.
<jlicht>It works in the sense that I've been able to package beyond node version >10, and we can manually build simple typescript packages using esbuild
<PurpleSym>Node version 10 is probably fine, but RStudio started bundling a TypeScript library, which itself depends on other packages, so the importer could be useful.
<jlicht>The "plan" is to wait for alternative, easily bootstrappable tooling to mature, such as the Rome project
<jlicht>Where "plan" = "wishful thinking"
<jlicht>it worked for rust :)
<PurpleSym>jlicht: Tried the importer using `./pre-inst-env guix import npm-binary fuse-box`, but it backtraces: Any idea?
<PurpleSym>(Using guile-semver from Guix, which is at 0.1.1)
<PotentialUser-42>Hello friends,
<PotentialUser-42>I like software freedom and I also do not have much computer knowledge. Are there any non-free firmware in these two drivers?
<jlicht>PurpleSym: I am being besieged by an army of telemarketers since my phone number ended up in one of their databases; I'll be rebasing (and fixing) that branch somewhere this weekend, so if you send me the command you tried, I can make sure that one actually works.
<PurpleSym>jlicht: I fixed it like this: and now running `./pre-inst-env guix import npm-binary -r fuse-box` succeeded. Sometimes it spits out #<unspecified> for the homepage field, but that’s easily fixed.
<civodul>nckx: oops, sorry about inetutils
<sneek>Welcome back civodul, you have 1 message!
<sneek>civodul, nckx says: I reverted 55050e54a987cd99b8477da1a4993e83adcca129 because it rebuilt 1800+ packages and I couldn't see extenuating circumstances.
<civodul>it hadn't occurred to me that it had dependents at all :-/
<jlicht>PurpleSym: thanks, I shouldn't work on code late at night :-)
<PurpleSym>jlicht: No problem. It even builds the package, but I’m not sure how usable it actually is yet.
<jlicht>PurpleSym: most packages I used it for were quite usable, actually! I was able to use a guix-packaged csso to do some css processing
<raghavgururajan>If any committers are on updating-packages streak, please consider adding #46411 and #46417 to your list.
<PurpleSym>jlicht: Okay. Another question, if I may: Is it possible to pass the importer a package.json and let it import all of the listed dependencies?
<raghavgururajan>sneek, later ask dannym: Any update with wip-deskop and ryzen stuff?
<sneek>Will do.
<jlicht>PurpleSym: not yet, but it should be a reasonably small adaptation to make, as the json returned by the npm registry is quite similar to the structure of a package.json file
<PotentialUser-42>civodul, cbaines
<PotentialUser-42>Hello friends,
<PotentialUser-42>I like software freedom and I also do not have much computer knowledge. Are there any non-free firmware in these two drivers?
<civodul>hi PotentialUser-42!
<civodul>i don't know the answer
<civodul>usually free drivers are part of the upstream kernel
<civodul>the problem with wifi is usually not the driver itself, but firmware
<PurpleSym>jlicht: Okay, I’ll do it by hand for now.
<jlicht>PurpleSym: thanks for sharing findings/feedback/improvements!
<raghavgururajan>Folks! During initial development of `guix deploy`, why was DigitalOcean chosen?
<PurpleSym>jlicht: I’m running into another issue right now: chain-able 3.0.0 and 1.0.1 are pulled in at the same time, but since the variable names are the same only the first one is actually used causing errors in the package requiring 1.0.1.
<jlicht>PurpleSym: manually adjusting it is the name of the game for now, but the crate importer should have a solution for that that I might simply copy in the long run
<roptat>raghavgururajan, probably because the author had an account at digitalocean, so it was easier for them to develop for it
<pineapples>Hi! I have a question regarding channels. Let's suppose a malicious actor gained unauthorized access to a third-party channel I use, and uploads a package that bears the name of a package from the official Guix repository. Let's also ignore the fact there are other, most likely more refined means of compromising a Guix System via a compromised channel. What will happen? Will the package from the third-party channel take preceden
<pineapples>ce over the package from the official repository?
<raghavgururajan>roptat: Ah cool! I thought it was related to uploading custom images.
<roptat>pineapples, I think it depends on the version of the package in the channel and in guix. In any case, you'll at least get a warning that there are two packages by the same name, and it'll tell you which it chose
<roptat>actually, you'll also get that warning if you try to install a package and we have multiple versions of it already
<roptat>if you use a package by variable name (in a script or manifest), you'll get whatever you imported last I think, but guile will warn you "foo in (channel corrupted) shadows definition foo in (gnu packages bar)" or something like that
<roptat>but if you imagine a corrupted channel, it can already do arbitrary code execution, so that's not really the biggest threat here :p
<pineapples>Well. Thank you for the detailed response. The best security practise appears to be sticking to the official channel if possible. Not a huge deal to me if you ask me
<PurpleSym>jlicht: Ooof, I don’t think that’s feasible. I’ll see if I can add version numbers myself.
<adfeno>Hi there, which package provides Ruby's mkmf (the full one, not mkmf-lite) ?
<kondor>Do we still not have a vnc system service?
<pineapples>roptat: >"it can already do arbitrary code execution" How does this happen? As far as I understand, when 'guix pull' is run, every defined channel's modules is compiled? Yes? Would the execution of arbitrary code take place during the compilation? Just curious
<bqv>hey, would anyone be open to a small packaging request? Simple emacs package I would like to use
<fnstudio>i've been experimenting with the guile-build-system a little bit; could anyone familiar with this system confirm if it's primarily meant for libraries as opposed to executables?
<fnstudio>in my example, the build-system successfully compiles the .scm files and move them to a /gnu/store/.../lib/guile/... folder
<fnstudio>no trace of a bin folder though, where i'd expect to find my executables
<fnstudio>maybe i am missing something in the way to use the build system? or in the way i should structure my guile toy project? or maybe i should be using gnu-build-system?
<rekado>bqv: this may be a good opportunity to use the importer
<roptat>pineapples, you could define a package in such a way that it does a side-effect
<roptat>like (package (name (begin (display "hello\n") "foo")) ...)
<bqv>rekado: it has native dependencies, that's what I'm not sure on
<rekado>bqv: can you show us what you’ve got already?
<pineapples>roptat: But does such a package have to be installed for the arbitrary code to be executed?
<roptat>no, you'd execute the code even before, if you do a search or interact with it in any way
<roptat>well, I think, cause I haven't tested ^^
<bqv>rekado: nothing, currently. I packaged it for nix, so I know how to do it there, but I am exceedingly novice to guix so I am not sure how to achieve the same. I'm reading emacs-xyz.scm, but just wondering if someone here might be able to knock it out in seconds
<jsoo>I had a chance to use the official installer this week. What a good experience! Nice work!
<bqv>roptat: package in question -
<bqv>rekado: * ^
<pineapples>roptat: That's scary, albeit an eye-opener. Can non-package Guile modules do that as well?
<roptat>pineapples, maybe, but they'd have to be loaded by something first
<rekado>pineapples: that’s a price to pay for the ability to compute anything
<rekado>we can, for example, compute fancy package variants without having to fully specify the package as data
<iyzsong>little scary, but it's same as npm, pip, both can run any code..
<pineapples>I see. Anyway, if I understand correctly, although any code hosted by a channel can be used to compromise an instance of Guix System, packages have the highest probability of becoming an entry point of malicious code
<bqv>Looks like emacs-libgit builds a native module too, but how does guix handle glib apps currently?
<roptat>I'd say so
<roptat>especially if you consider the channel could simply provide you with backdoored definitions without doing anything fancy
<roptat>you need to trust the channel anyway
<rekado>pineapples: I don’t think I agree with this assessment.
<rekado>pineapples: it is pretty easy to tell people to add a channel; few will actually read the channel code
<rekado>just tell them that this channel provides a package for this or that game
<rekado>bqv: is there anything to be handled? You just add the right inputs (and possibly set an environment variable).
<bqv>well, nix has wrapGAppsHook, which is there to fix a number of bugs that crop up with gstreamer/glib apps, I assumed there'd be an equivalent
<apteryx>Was there discussions about having something like /etc/os-release on Guix System?
<apollo13rU>/!\ this channel has moved to ##hamradio /!\
<bqv>If not, well I suppose I'll just try it without and see what breaks...
<bqv>apollo13rU: wow thats a throwback spam message
<iyzsong>bqv: yes, we have 'glib-or-gtk-build-system' which should do the same thing, wrap binaries with some env variables.
<bqv>Ah, there we go. Excellent, thank you iyzsong
<ohnx>/!\ this channel has moved to ##hamradio /!\
<bqv>I'm sure I saw this happen years back too...
<rekado>pineapples: we could perhaps think about sandboxing channels by default and disabling sandboxing with a channel configuration flag.
<modinjp>/!\ this channel has moved to #nyymit /!\
<bqv>rekado: is is really gonna be possible to sandbox code though, eventually it runs toplevel so surely expressions buried deep enough would escape
<pineapples>rekado: So, at the end of the day, there are multiple entry points of a compromised channel's malicious code, and whatever my or someone else's security model is, as long as we add a third-party channel that we only partially trust, there's no way for us to protect ourselves from it unless we remove it from our system?
<ShibewG>/!\ this channel has moved to #nyymit /!\
<apteryx>civodul, nckx: should we add the r flag for now (force registration)
<rekado>bqv: I’m talking about 6.18.12 Sandboxed Evaluation in the Guile manual
<OvidiuSyG>/!\ this channel has moved to #nyymit /!\
<pineapples>This is mildly annoying
<bqv>i think that's the aim
<bqv>apteryx: agreed
<apteryx>it seems to have halted
<bqv>famous last words
<civodul>apteryx, nckx: re "r" flag, no idea; nckx knows better than i do
<civodul>it's good if it helps thwart that while still making it easy to join
<civodul>(this spam that just happened seems to be Freenode-wide)
<roptat>I went berserk and kicked a few of them out of lfs-fr :D
<roptat>made my day ^^
<roptat>I'm looking at videos, it looks like we had already something in place for translations
<roptat>there are "subtitles" directories, which I guess is good, but I'm not sure how to use them ^^'
<roptat>and the build script for the videos seem to generate pot files for each video, which seems to be related to the text in the video
<roptat>I'm building everything now, just to see if it works and what it generates, then I'll try to target a specific video
<roptat>see if I can translate it properly
<dannym>civodul: Could you look at the kernel-loadable-module-service-type patch (just that one)? I almost was ready to push that contribution to master, but I'm not sure about that "mbegin %store-monad" in kernel-builder-configuration->system-entry. Is it OK?
<sneek>Welcome back dannym, you have 1 message!
<sneek>dannym, raghavgururajan says: Any update with wip-deskop and ryzen stuff?
<fnstudio>(re my question about the guile-build-system, i think it makes sense to actually have a makefile and then use the gnu-build-system)
<Noisytoot>What are all of these "/!\ this channel has moved to <something> /!\" messages?
<Noisytoot>civodul: /mode #guix +r
<civodul>dannym: sure, lemme see
<dannym>raghavgururajan: Yes, I've set up a AMD Epyc build machine now. Currently trying to figure out how to make Guix use RAID 0 and also boot from one of the drives
<jonsger>dannym: episch :)
<civodul>dannym: i'm looking a bit more, will comment by email
<bqv>good god, how on earth do i build something from guix repl
<bqv>i've got as far as getting a derivation object
<bqv>nothing i do seems to actually build it
<bqv>gonna lose my mind...
<rekado>bqv: why build from “guix repl”? Why not “guix build”?
<bqv>rekado: i'm used to my nix workflow, where i can conveniently instantiate derivations from the repl, and also build them
<bqv>it's a bit janky otherwise, having to copy the derivation name to a terminal, build it, copy the output name, etc
<bqv>and from what i can tell it should be possible
<bqv>unless i've misinterpreted
<rekado>sure, it’s possible, but … we don’t copy derivation names and all that
<rekado>I usually write a package definition, then do ./pre-inst-env guix build -K the-thing
<zimoun>bqv: it depends the level you want, the CLI level in the REPL “,use(guix scripts build)” then “(guix-build "hello")” where the string can be your derivation.
<rekado>you *can* do this at various levels in the REPL… oh, well, what zimoun wrote ;)
<bqv>oh, wow
<rekado>but if you use such a very high level you might as well use “guix build” on the CLI. There’s nothing gained from using a REPL.
<zimoun>however, Geiser can choke.
<rekado>the REPL method is nice for building *anything* that’s not even in a file.
<zimoun>rekado: avoid a copy/paste… maybe :-)
<roptat>there's build-derivations from (guix derivations)
<rekado>but since your goal is to eventually add the package definition to a source file you’ll end up needing a copy/paste from the REPL in the end, so…
<bqv>i guess i was more hopeful guix would lend itself more to an ad-hoc style of store usage, rather than strictly file-based like nix
<rekado>it does
<roptat>you can get the "store" object with (open-connection) from (guix store)
<rekado>but if you’re “going to lose your mind” I suggest using the CLI
<zimoun>bqv, as roptat said, there is many ways to build a derivation. It depends on the level you wan to be.
<rekado>see also
<rekado>,run-in-store (package->derivation hello)
<zimoun>as an Haskeller would say: Don’t fear The Monad. ;-)
<bqv>yeah, fair enough
<bqv>i had been fiddling with those tools, i think the problem i was having is that the derivation i'm building fails currently, and it fails silently
<bqv>which is i guess the pitfall of that method currently
<bqv>because i've actually tried both of those methods :p
<bqv>rekado: zimoun: roptat: thank you all though
<dustyweb>wait more discussion on guile-emacs again in the backlog?!
*dustyweb really wants guile-emacs still
<bqv>i had attempted to build it. was informed that that was categorically a mistake
<bqv>cancelled it after 40 hours
<roptat>ouch ^^'
<civodul>dannym: i commented a bit more on the ZFS patches; that's all for today :-)
<bqv>alright, i give up, will someone help me get this building?
<bqv>this is literally the first thing i've tried to package on guix, cause nobody else was interested in helping
<bqv>i have no idea what half these errors mean
<civodul>"nobody else was interested in helping"? really?
<civodul>i've seen a lot of discussion here
<bqv>i asked about 3-4 hours ago
<bqv>i got some direction at least but it's only got me this far
<bqv>and i've been at this wall for a while now
<civodul>so you can be thankful to everyone who helped you get this far already :-)
<bqv>well, i did thank them
<bqv>but i was hoping someone would be interested in just doing it, because i'm pretty sure i'm overcomplicating this
<civodul>did you check the Cookbook entries, like ?
<civodul>seems it might be useful to help you go further
<civodul>("guix repl" isn't of much use when packaging software)
<bqv>i was using the repl for iteration, that discussion isn't relevant
<bqv>the problem i have is, conceptually i understand everything going on here, but the error messages are for all intents and purposes chinese to me, and searching them online yields nothing
<civodul>yeah, that's why i'm pointing at the Cookbook
<civodul>you'd see that the examples there start by defining a module, for instance
<bqv>is it a requirement to define a module to define a package?
<civodul>kind of, if you wish to refer to the package by name from the CLI
<bqv>i don't, i'm building that termbin file by path using 'guix build -f' currently, since y'all demonstrated to me that the repl's a bad idea for iteration
<civodul> explains this a bit
<civodul>re "guix build -f", see the example at
<civodul>the file shown there returns a package object (so there's no 'define-public')
<bqv>civodul: check the last line
<roptat>bqv, what's the error message you get?
<bqv>roptat: copied here:
<bqv>i added a few things to arguments..#:imported-modules
<bqv>because it was complaining of those
<roptat>ah, you're using the glib-or-gtk-build-system, but you overrode the imported modules from that build system
<roptat>so you might be missing (guix build glib-or-gtk-build-system)
<roptat>although, not sure about the difference between imported-modules and modules, but I'm sure you're missing it at least in one of them :p
<bqv>roptat: indeed, adding that and a few other things makes it build! thank you!
<rekado>in case that’s of interest: here’s my Guile Emacs patch:
<mothacehe>hey lfam!
<sneek>mothacehe, you have 1 message!
<sneek>mothacehe, civodul says: you're my hero!
<mothacehe>dunno why but thanks civodul :)
<lfam>I saw you got the wireguard tunnel open!
<mothacehe>yes and working!!
<mothacehe>see :)
<mothacehe>I'm replying to your email
<lfam>About hardware?
<lfam>Cool, I'll wait for your reply
<ngz>Hello. Guix has no identifier for 0BSD license. Is there any issue in me adding one? (i.e., is there something fishy about this license?)
<lfam>Usually we don't add licenses until we have some packages using them. There is the 'non-copyleft' license option
<ngz>Of course. I didn't mention I have a package using it.
<lfam>Feel free!
<ngz>Hence my question.
<rekado>ngz: I couldn’t find it here
<rekado>is there another name for it?
<rekado>where can we read the license text?
<ngz>Ah. Then it should be ISC
<ngz>Ah no.
<bandali>ha, if it's not on (which it doesn't seem to be), it'd probably be a good idea to ask the fsf licensing folks to evaluate it and have it added there (cf
<ngz>There is not much to evaluate.
<civodul>mothacehe: my comment was about the worker stat pages :-)
<civodul>mothacehe: great that the overdrive is back to work
<mothacehe>hehe thanks :)
<civodul>maybe 4 workers is too much tho; perhaps 2 workers with --cores=2 would be best?
<mothacehe>yes wireguard seems to perform really smoothly
<mothacehe>yup you're right
<mothacehe>we also should be able to get rid of those SSH tunnels
<civodul>oh that'd be nice
<mothacehe>I'll see about writing a wireguard shepherd service if things works as expected
<ngz>I used non-copyleft.
<lfam>With 4 workers, each worker would have at least 16 cores available, right?
<lfam>Heh, half the workers are building for aarch64 and everything else is idle. There was a huge backlog
<lfam>It's all Common Lisp / SBCL packages
<lfam>I guess most of that work will be wasted, since almost all of it is being attempted on the emulated platform
<lfam>(The Lisp stuff all fails there)
<lfam>Hopefully there was some "bottleneck" package that was failing before, and the rest of them will succeed
<mothacehe>the few sbcl and cl packages overdrive1 tried to build failed :(
<lfam>Oh :(
<lfam>I remember I tested one of them on monokuma and it did succeed
<mothacehe>well let's see how it goes! Here's a failure for instance:
<lfam>Do we have a way to prevent Cuirass from building a package for a certain platform? Like, could we just disable the building of SBCL stuff on ARM, without editing the packages themselves?
<mothacehe>The only way I know of is to set the "supported-systems" property of the package itself.
<mothacehe>but it could be interesting to be able to do it in Cuirass directly
<lfam>Right, I don't think we want to disable users from building these packages
<lfam>Or, other build farms, for example
<mothacehe>lfam: it could be nice to add this idea, as well as some we discussed monday to
<lfam>Sure, I'll add it now
<mothacehe>thanks :)
<mothacehe>have to go, see u!
<sundbry>@PurpleSym @jicht the approach I take to get work done is using the wip-node-14 branch for the recent node.js (TYVM), and then I do a manual build with `npm ci/install` and then do guix build with the project directory as source to vendor in all of the deps. Not ideal by any means but I have a similar workflow for java/maven projects.
<rekado>FWIW, with my patch for guile-emacs the build of guile-for-guile-emacs and guile-emacs itself passes after 87m7.213s
<rekado>that’s on my laptop
<rekado>guile-emacs fails earlier now compared to my tests a few months ago, because loadup.el now does something with the dumper
<rekado>so it fails right away with “Symbol's value as variable is void: dump-mode”
<rekado>in the past it would start up and then segfault when you do something with it
<zimoun>Using Emacs and Debbugs, I am not able to see “critical” bugs. But it is one of the severity levels What do I miss?
***adfeno1 is now known as adfeno
<ngks>Here's a simple question: I am running Guix System and trying to create Guix packages for some software whose build system requires Docker (probably there is different way to do this but I want to follow upstream instructions at this point in the process).
<ngks> This introduces a requirement that my user be in the "docker" group. I haven't been able to create this group either in my config.scm or at the guile repl.
<roptat>well, that won't be possible
<ngks>I see. Why is that?
<roptat>first, this docker thing would have to be built from source, which is probably impossible
<roptat>then, the user that performs the build is one of the build users, from the guix-build group, and they won't be part of the docker group on other machines
<ngks>yes I guess that's obvious
<roptat>and, if that image is pulling from the network, it won't be able to do so from the build environment
<ngks>also obvious now that you say it
<ngks>I mean, thanks for pointing it out since I didn't put it together on my own
<roptat>I'm kinda overwhelmed by the build process for the videos...
<ngks>so I guess I will have to investigate the software's build process to break this (IMO depraved) Docker requirement.. We'll see how far I get. Thanks for the advice.
<lfam>They are probably using Docker in an effort to have an understandable build environment, but it's unlikely it really depends on Docker
<roptat>probably, you'll find that info either from alternative instructions in the README or INSTALL files, or from the dockerfile itself
<ngks>to follow up on the previous question, can someone point me to docs location (or more likely a location in the Guix sources) that illustrates how to create a user group? It's a basic Unix task and I feel queasy not being able to do it.
<roptat>when you use the guix system, you should forget about trying to use a command to do anything ;)
<roptat>just use the configuration file
<roptat>ngks, here's the documentation:
<ryanprior>Can you extend the operating-system definition at runtime? Or does adding a user or group require reconfiguring and rebooting the system?
<roptat>you need to reconfigure
<roptat>but no need to reboot
<ngks>My question is pretty basic so thanks for hanging with me. I was looking at that section in the docs yesterday; it says how to write user group declarations like `(user-group (name "students"))` but not where the declaration should go.
<ngks>I tried putting that declaration inside the operating-system declaration, no luck. Then I tried putting it inside the users declaration, no luck. At that point it felt like I was just changing things at random. Ideally somebody could point me to a location in the Guix sources that provides an example.
<lfam>I think it would go like (groups (cons* (user-group (name ...)) %base-groups)
<lfam>That's the pattern of the other fields in operating-system
<lfam>Does that make sense?
<ngks>I think this is the answer I'm looking for, thanks. confirming now.
<lfam>I noticed the manual doesn't explicitly show this
<ngks>lfam: it worked, thanks
<adfeno>ngks: most stuff development guides tell you to do aren`t needed for building the actual thing.
<adfeno>I also see many places telling people to run a “bundler”/“minifier”/“obfuscator”/“squisher”/“shrinker” during builds. This is not needed.
<ngks>for sure, my approach is to try and stay as close as possible to upstream instructions. but no closer, so to speak.
<adfeno>ngks: thruth is, they never explicitly separate these steps into comprehensive sections (I`m not talking about Guix, but about third-party software).
<adfeno>So as you said, we must exercise critical thinking to decide if each step is really needed.
<adfeno>I`ll check my MemoServ messages, see if any offline messages were sent to me.
<pkill9>how difficult would it be to add resumable substitute downloads?
<roptat>pkill9, I think I have a patch for that, but it touches the daemon
<adfeno>Although worrying, my MemoServ queue is as clean as a new paper. :)
<adfeno>I must go now. Bye.
<pkill9>nice, thanks roptat, are there any issues with it?
<pkill9>i.e. is it safe to use it?
<roptat>pkill9, not very tested, but I think it's safe
<roptat>well, if you find any bug with it, please report on the issue :D
<rekado>roptat: do you mean the build process for the 3min Guix videos? Perhaps I can help.
<pkill9>roptat: can you link to the patch? I can't find where the latest one is
<dftxbs3e>efraim, okay! great! :-D
<roptat>rekado, well I'm trying to understand what I need to provide in order to translate the videos
<roptat>pkill9, mh.. probably never sent that one ^^'
<roptat>let me check
<roptat>pkill9, sorry, I think I either never made an updated patch or I lost it and never sent it :/
<roptat>so the first patch is the latest version
<rekado>roptat: there are svg slides, audio files, and CLI session scripts; all these would need to be translated.
<roptat>how do subtitles work?
<roptat>if I provide French subtitles, does the process know how to add them to the video (maybe as an option)?
<rekado>I think we never made any subtitles
<roptat>(I mean, as one of possible subtitle languages, like French, English or None)
<rekado>there’s a directory for that, but no, there’s no provision to generate or collate them.
<roptat>English subtitles are still useful for people who can't listen (deaf, or with other people), or don't understand English very well
<rekado>but the project never produced any subtitles
<roptat>I can do that easily, for French and English
<rekado>the assumption was that the transcripts (for recording audio) would be used as subtitles, but obviously there’s still work to be done to get from transcript to srt file
<roptat>well, looking at the transcript, it's not in a very good shape... it only breaks at slide level, so you'd get a wall of text on most slides ^^'
<rekado>yes, that’s what I meant with “work to be done” :)
<roptat>is it ok if I submit a srt file directly?
<rekado>arguably the English srt file should be the foundation of each video as it can be used to derive other timings
<rekado>but that’s not the way it was built
<dftxbs3e>cbaines, hey, I'm not sure how and why it failed here:
<dftxbs3e>it looks to have succeeded but says it failed to import data
<cbaines>dftxbs3e, it just took too long, there's a 24 hour timeout. I've doubled the timeout and set the job to retry, hopefully most of the relevant store items haven't been GC'd yet
<dftxbs3e>cbaines, oh okay! I hope so!!
<dftxbs3e>cbaines, really close to setting up the guix-build-coordinator-agent in a VM
<dftxbs3e>cbaines, can I have a second token for a second machine?
<cbaines>dftxbs3e, sure, here's the ID, I'll message you the password ef7b280a-18c6-4df5-9585-b1f8488b7da5
<dftxbs3e>cbaines, thanks, just updated the other x86_64 agent and it works now, no more errors
<cbaines>great, that's good :)
<dannym>Gah, with guix master (commit af55e2aad6abaf1efb60366796fcfb7867e296fb), right after guix system init, the first guix system reconfigure fails with: /root/.config/guix/current no such file or directory
<dannym>That's because the directory /root/.config/guix does not exist and apparently is not being created either
<dannym>the first guix pull fails
<dannym>so guix system init ..., then guix pull, then error /root/.config/guix/current no such file or directory
<dftxbs3e>cbaines, is there a live log feature for the Guix Data Service?
<cbaines>dftxbs3e, there isn't, but there could be
<roptat>rekado, just noticed, the video says "note that we are running as an unprivileged user", but the command ends by suggesting to extend $PATH with /root/.guix-profile/bin :)
<roptat>(that's the first one, on the installation script)
<rekado>roptat: I’d be happy if these videos got a make-over
<ngz>Hmmmm. I think we need different versions for rav1e package since it is a Rust package.
<ngz>Currently rav1e is at 0.3.5, but a yet-to-be-packaged Rust package (ravif) requires it to be at 0.4. Moreover rav1e 0.5 is on its way.
<ngz>So we need to freeze rust-rav1e-0.4 somehow.
<ngz>Maybe we can add "rust-rav1e-0.4" to "crates-io.scm", and make "rav1e" an alias for it in "image.scm". How does that sound?
<ngz>I mean in "video.scm"
<lfam>dannym: That's been reported as #46269
<lfam>It's weird, I think it's a new problem
<lfam>ngz: Can't we use the same version of rav1e everywhere?
<ngz>If we do, this is going to break at some point. In this case, when rav1e will be updated to 0.5, rust-ravif-0.6 will still require rust-rav1e-0.4.
<lfam>That's a normal situation though. Packagers should check that things don't break
<ngz>What do you mean?
<lfam>It's normal for there to be a variety of version constraints
<lfam>Typically, we deal with that by waiting a little while, for all the dependent packages to be ready to use the newer version of the dependency
<lfam>Since rav1e is written in rust, we also have to consider its own dependency graph, which will suffer the same problems
<ngz>I'm not sure this is optimal in Rust world.
<lfam>I think we can keep rav1e at the version required by other rust packages, and let ffmpeg use whichever version is available
<lfam>The tricky thing with Rust is we would also have to maintain separate dependency graphs for the two versions of rav1e
<ngz>Non-leaf Rust packages typically have multiple versions to handle this. Why wouldn't it work with rav1e?
<lfam>I do think it would work
<lfam>I just don't think it's ideal
<lfam>Can you clarify why it would be better to have multiple versions of rav1e?
<ngz>It will help us keep up with Rust development without preventing updates from rav1e
<lfam>Okay, if you think it's better then go ahead. It's definitely a case where the person doing the work gets to decide :)
<lfam>I think that, for ffmpeg, it's not critical to keep up with rav1e updates. It's not the first-choice AV1 encoder in ffmpeg, and not even really useful at this point
<ngz>Then we can simply add a rust-rav1e package in "crates-io.scm" with #:skip-build #t, and keep regular and fully-built rav1e in "video.scm" as-is.
<ngz>rust-rav1e would only be used as a Rust dependency.
<ngz>Fair enough, then.
<lfam>By the way, do you have an easy way to update the rav1e dependency graph? I tried it recently but didn't find a good workflow
<lfam>I thought I could use a recursive `guix refresh` but it only changed a single package
<ngz>Not an easy way. rust-rav1e was a dependency of a Rust package I'm currently working out. So I packaged everything it needed along the way.
<ngz>(if that makes sense)
<lfam>I had hoped I could use `./pre-inst-env guix refresh -u -t crate -r rav1e`
<lfam>Otherwise... it seems impractical
<ngz>Yup, Rust updates are not great.
<lfam>It kind of makes me hope that it doesn't catch on :/
<lfam>Like, "in industry"
<ngz>Moreover, rust-rav1e updates introduces a cyclic dependency: rust-rav1e -> rust-image -> rust-ravif -> rust-rav1e…
<lfam>Ugh lol
<lfam>Already, it seems like every major computing business is creating their own AV1 tools
<ngz>So you need to update them all at once.
<lfam>Google -> libaom
<lfam>Intel -> svt-av1
<lfam>Netflix is behind svt-av1 too
<lfam>Chromium, which is basically a company -> libgav1
<ngz>Interesting. What is so… important… about AV1?
<lfam>It's royalty free
<lfam>The video industry was revolutionized by h264, which was expensive but at least the costs were predictable
<lfam>h264 was improved in h265, but the royalty costs were unpredictable, so nobody uses it
<lfam>AV1 was created by a coalition in order to realize some gains (evidenced by h265) but without the cost
<lfam>You get significant bandwidth reductions, and it handles certain edge cases like film better
<lfam>rav1e is the encoder that is not "from" a corporation, so it's interesting for that reason
<lfam>But, the software ecosystem around it is very challenging, since it is in rust
<lfam>It's a shame
<ngz>Everything related to av1 is in Rust?
<lfam>Just rav1e
<lfam>Everything else is C / C++ / asm
<lfam>The encoding is extremely complex, so performance is critical
<lfam>In the long run, it will be offloaded to hardware, since it's not really possible to do in software on most devices
<ngz>That seems logical, indeed.
<lfam>But, since AV1 will represent the next decade or so of digital video, everyone wants to "own" the space
<pkill9>what's AV1?
<pkill9>oh a codec
<lfam>It's a digital video encoding
<lfam>If you watch new videos on youtube and are using a major browser, you might get served av1 video
<pkill9>when i hear codecs, I think Alan Resnick
<lfam>The only answer is h264 / aac
<pkill9>lfam: i don't know how to get qtwebengine to use system openh264 D:
<lfam>Oh yeah, speaking of h264
<lfam>You can't get the configure phase to succeed?
<lfam>Did you check what other distros do? Sometimes that helps when you get stuck
<zdm>Is there a way to tell if youtube is sending me an AV1 video besides downloading it locally?
<lfam>zdm: Right-click on the video and select "stats for nerds"
<lfam>You might get something different if you download it
<zdm>lfam: that works, so does youtube-dl -F
<zdm>youtube-dl -F | grep av
<zdm>I'm assuming avc1 is av1, yes?
<lfam>Oh, cool feature
<lfam>No, that's h264 ("Advanced Video Coding" is the proper name)
<pkill9>no i forgot to look at other distro's packages, thanks for reminding me
<lfam>I forget what the codename of av1 is
<zdm>well, -F lists everything
<lfam>This video is offered in AV1:
<zdm>youtube-dl shows it, cool
<lfam>It does look... really good
<lfam>A bit cartoonish but that's what AV1 looks like for now
<ngz>Now I'm waiting for Eww to grow an av1 plugin ;)
<lfam>If it uses a media framework like gstreamer or ffmpeg, it should have support in guix
<lfam>Oh, maybe not yet with gstreamer. I should look into that
<lfam>I suppose it could come through gst-libav
<zdm>Does anyone run guix (or well, linux-libre kernel really) using a high resolution and/or high refresh rate display? I'm currently planning on buying an Intel NUC as it seems the most appropriate platform for me to install Guix on and use my 1440p 165hz display. What I'm wondering is if anyone has had any issues in terms of resolution and also importantly high refresh rate?
<lfam>zdm: It has integrated Intel graphics support?
<zdm>lfam: The NUC yeah, that's the point of me getting one
<lfam>I think it should work, since support for that is usually built in to the kernel, unlike with discrete GPUs from nvidia or amd
<zdm>Intel NUC NUC10i5FNK
<lfam>But you should wait for more advice. I'm sure you wouldn't be the only person using a NUC
<zdm>Integrated and all
<dftxbs3e>hey, anyone feels well involved with GNU Guix and has a sourcehut account? I'm willing to share maintainership of an awesome-guix list so it's durable
<zdm>I should join sourcehut, keep running into and liking what I'm seeing.