<Rovanion>Is there a way to use a python projects requirements.txt as an input to a Guix package definition? I have an existing project made by a friend here, and I would like to as unobtrusively as possible use Guix as the package manager when trying to develop in it. <baryluk>Rovanion: guix import pypi xyz --recursive ? maybe. if it is in pypi. It is probably trivial to write a awk script to convert your requirements.txt into proper form too. *raghavgururajan often thinks Guix needs a LTS branch <lfam>How do you envision it, raghavgururajan? <baryluk>roptat: Thanks for the website fix. it shows architectures correctly. <lfam>I saw your comment about the progress bars baryluk <vagrantc>raghavgururajan: it seems like the kind of thing one could easily do if they provide all the human resources, build machines, and so on ... :) <baryluk>lfam: I am still impressed by other stuff ;) <vagrantc>e.g. anyone can make substitutes available, and you can build your substitutes against whatever branch you want <lfam>The reason I asked for their vision is that I think different constituencies want different things to be "long term" vs changing <lfam>I think that in order to fix it baryluk, we need someone who understands how other progress bars avoid the problem <lfam>It's definitely an opportunity, vagrantc <baryluk>lfam: I would check for example wget. It responds to resizing pretty well. Not sure if it listens to SIGWINCH, or check stuffs every time it tries to update it, but it manages to remove the previous progress in most of the cases. <baryluk>In my tests, guix, would produce a enormous triangle of #s in terminal after resize :D <lfam>It doesn't recalculate the number of characters it needs to print <miskatonic>a difference between base packages, who ciould prrofit from LTS, and ports (in the sense of *BSD) would be useful <mbakke>Derp, I made a thinko in the ungoogled-chromium update, so now it will always use 8 parallel processes at the final linking step. Will fix at the next update, I doubt it makes much difference in practice. <roptat>alright, I can parse all of the hundreds of Android.bp in android sources now :) <roptat>actually, thousands, find returns 5863 files :) <roptat>the grammar is pretty simple, but I still had to fix some corner cases, like a few files had "\r\n" in them <nickdaly>Aside from language, is there any reason to prefer guix or propellor? Has anyone tried both? <theduke>which provides extensive user-environment configuration with typed settings. <nckx>theduke: Not that I'm aware. <theduke>roptat: interesting. a read-only home directory is a little bit too extreme for me though <roptat>well, if you are ok with reconfiguring every time you want to test something new ^^ <theduke>there's way too much software that doesn't respect XDG vars for cache, config, data dirs <theduke>I'd probably go insane pretty quickly ;) <chipb>nickdaly: you mean, like Joey Hess' propeller? <nckx>Interesting thing, but more like another puppet/ansible/... but with Haskell. <chipb>nickdaly: I guess I can see some overlap, but I think they're pretty differently aimed tools. <vagrantc>i really wanted to like propeller, but i couldn't wrap my head around haskell <vagrantc>instead i've apparently ended up stumbling into this guix thing... <euandreh>propellor is much closer to Ansible than it is to Guix <chipb>I haven't looked at it in quite some time, but my impression is it's more like "puppet (with similar distro agnosticism), but haskell". <nckx>vagrantc: xmonad made me grudgingly appreciate it, but that wasn't easy. <theduke>also: since Nix has a type system for module settings, I can see all module options with `man configuration.nix` or with the web search, which is absolutely brilliant <chipb>guix is more if you did puppet in scheme and built a distro around it. <chipb>not to say you can't use guix as a standalone package manager on another distro, but then you aren't using the system configuration interfaces it provides. <euandreh>I haven't worked with Puppet, but Ansible (and also propellor) is much more mutable than Guix is <euandreh>As in update-in-place, instead of os = f(config) <nckx>Yeah, they're more like your robot sysadmin buddy. <nckx>‘Go twiddle these knobs.’ <chipb>I used puppet as comparison intentionally. ansible is inherently sequential. puppet is sequential in that it applies changes in some order, of course, but to get a defined order you would need to notate that ordering. <nckx>Guix Deploy is your robot buddy with a flamethrower. <nckx>And he *really* likes to use it. <chipb>I...think I recall propellor being similar in that regard. <chipb>nickdaly: of course, I don't know if that analogy is helpful to you. :-) <euandreh>Regardless of the order, it is still way more stateful that Guix. There was a nice talk on NixConf 2019 (I think) that someone categorized things like that between convergent, declarative and X configuration manager. I liked the terminology, I'm searching for it now <chipb>yeah, it builds a full system snapshot then switches to that atomically. it kindof needs some sense of distribution support to do. <chipb>guix/nixos aren't the only way to do that, but they're ones I happen to like. <euandreh>It only needs to own the full tree of packages it will use, so it can have full agency over them <chipb>you could do something similar with another distro by mashing it with ostree. <euandreh>Sure, I agree with you that is harder without distro support or something that gives it such power <chipb>yeah, the ability to extend derivations and capture the extensions is extremely nice. very good reason to use a distribution on that model. <euandreh>I'll watch it again, I remember liking it at the time <euandreh>it is "divergence, convergence and congruence", and there's actually a paper about it <euandreh>The paper is from 2002! It looks like a great candidate for a papers-we-love meeting <dftxbs3e>nckx, hello! after looking at that libffi patch, mine is different, it's another one, so still good to merge <dftxbs3e>however yes, (search-patches ..) will cause all platforms to include the patch <dftxbs3e>I think that GNU Guix should get conditional patching first before doing this kind of trickery inside package definition <dftxbs3e>AFAICT right now GNU Guix requires that source is always identical <vagrantc>swear i've seen some sources that patch differently per-architecture <vagrantc>but maybe that's conditional monkey-patching in phases <nickdaly>chipb, thank you, that gives me stuff to think about. <wleslie>cross-base does some patching conditional on *target* architecture <dftxbs3e>wleslie, vagrantc, yes, but monkey-style always <dftxbs3e>(patches ..) keyword argument wouldnt support it AFAICT <vagrantc>in gnu/build/linux-modules.scm: (define (module-soft-dependencies file) ... (let-values (((pres posts) ... what is "pres" ? <vagrantc>debian's lintian flags it as a typo for "press" ... but i have no idea what it actually means or is doing <wleslie>partition is returning two lists, and let-values is unpacking them for you into (pres posts) <apteryx>interesting problem; I'm trying to set "-DCMAKE_CTEST_ARGUMENTS=-E expensive -L -tests?-" as the #:configure-flags argument, but it gets expanded as '...bin/ctest --force-new-ctest-process -E\ expensive\ -L\ -tests?-' when it gets run. CMake doesn't seem to like the escaped spaces. <apteryx>ah, the doc says a 'semicolon list of separated arguments'; that explains it. <wleslie>I have a build that succeeds, but I'm not capturing the correct outputs <wleslie>can I perform a build and force it to fail so that I can examine them? <apteryx>sure, you can put (error 'stop) in any of the phases for example, and run with guix build -K <apteryx>or just build with -K and Control-C somewhere you like <apteryx>it'll leave the current build under /tmp/guix-build-yourpackage[...] <wleslie>apparently make found nothing to do for 'all' (: this is going to be fun <baryluk>use -GNinja; cmake --build . , maybe? :D <baryluk>(of course with ninja in build deps) <wleslie>I suspect the most recent newlib release predates ninja <baryluk>newlib? newlib doesn't use cmake. /confused/ <vagrantc>wow, i can almost get guix to build reproducibly if i disable parallel building! <vagrantc>it still has a build-path issue, although guix building guix is in the same path <vagrantc>only thing that embeds a build path is gnu/ci.go <apteryx>the .go have reproducibility problems when built in parallel, don't they? <vagrantc>oh, if you can find it that would be very nice <vagrantc>i think it might actually be different than 20272 ... <vagrantc>i see references to .scm modules other than the one being compiled ... is it plausible that multiple invocations of guile shares some memory ... or when guile builds in parallel is <vagrantc>is it a single binary running all the compiles? <vagrantc>just one the benefits of packaging guix for debian :) <vagrantc>107 gnu/packages/lisp-xyz.scm 107 gnu/packages/ocaml.scm 108 gnu/packages/music.scm <vagrantc>now if i can just figure out what is embedding the build path in gnu/ci.scm ... i think we'll be able to build guix reproducibly... <apteryx>it returs the path relative to the current-filename (of that source file). <vagrantc>but would that get embedded in the actual resulting .go file ? <vagrantc>e.g. is that determined at compile time or run time? <apteryx>it's a macro, so it gets expanded at load time, then when it compiles it it could have a reference to it I guess! <vagrantc>as, i think that's the only thing standing in the way of it being reproducible on debian <vagrantc>i'm not much of a schemer, even after using guix for a couple years now :) <vagrantc>i guess i'll report it as a bug, and scheme to get other people to fix it :) <apteryx>actually it'd expand to the file name, which should be constant. The canonicalize-path would get the absolute path, which is would change, right? <apteryx>vagrantc: yes it's a good thing to report it! *vagrantc will follow-up to the parallelism bug too <PotentialUser-49>hello everyone, just installed guix on this laptop here and following along the (absolutely excellent) manual, and "time guix install emacs-guix" reports 2m29s. Is this typical performance of the package manager or am I doing something wrong? It seems to download a package and then sit a while, download another, sit a while, etc. in a very sequenti <bavier[m]>PotentialUser-49: That's not out-of-the-ordinary. <PotentialUser-49>downloads seem to go fast fwiw, it just the fact that its all happening one thing at a time kind of way <bavier[m]>PotentialUser-49: the `-M` option is sometimes useful for download parallelism ***davidpgil1 is now known as davidpgil
<wleslie>PotentialUser-49: do you know if you set up substitutes? <wleslie>these speed up installation of most packages significantly <PotentialUser-49>bavier[m]: " time guix install -v 9999 -M 8 emacs-guix" after "guix remove emacs-guix && guix gc" took a relatively cool 1m4s now <PotentialUser-49>wleslie: judging by the verbose output it is indeed using substitutions, however i am running latest and didn't set up anything here yet <peanutbutterandc>Just read the latest blog post. Wow. And man! is that music super super groovy! <wleslie>substitutes are less verbose than source builds <PotentialUser-49>now i wonder how high i can take that "-M" parameter, 4 core 8 thread thing here, hence the 8 above [shrug] <PotentialUser-49>wleslie: well in the verbose output it says things like "substitution of /gnu/store/qka01vz54bdcrgbx3f9db0dv3yaggp4h-gdk-pixbuf+svg-2.40.0 complete" so im assuming its all binaries <PotentialUser-49>bavier[m]: thank you for pointing me to the flag, i tried a few other values for -M, number of cpu threads seems to be sweet spot indeed. Its more than twice as fast as the default. <ryanprior>I still haven't figured out a good way to deal with mutually-dependent packages. <ryanprior>My original plan, to define the origins in a let-form and then define the packages inside there, has ended up being a mess and I can't get it working so far. <vagrantc>can you build a minimal variant of one of them first, and then build out the full variant later? <ryanprior>My backup plan is to define a source-only package for package A, use that as an input for B, and then define a full version of A that relies on B. <baryluk>nice indeed. hope you can enable it for more archs later. just for guix, even if there is no repos for it, and probably bugs here and there to support it ;D <wleslie>ryanprior: is the circular dependency anything like hurd, where the cross compiler requires headers from hurd and gnumach, but you can't build hurd without the compiler? <vagrantc>baryluk: well, they'll need support in upstream guix before adding more ... arm64/aarch64 doesn't build on debian because guile-gnutls with guile-3.0 didn't successfully build for arm64 <ryanprior>wleslie: I don't think it's that tangled. Basically these two packages want to have the others' source at build-time. So practically speaking it's one package source, but with split names, outputs, metadata, upstream repo, etc <db48x>ryanprior: why not just make a single package then? <ryanprior>Because then users would need to know about the relationship between the packages, which I don't know how you make that discoverable. <ryanprior>For example, the go package apex/log depends on tj/go-kinesis. If you want one, there's no reason you'd search for the other or assume any relationship. Many apex/log users will probably never use kinesis. <ryanprior>But yet there is a relationship between those packages where in order to build either one you need the source code for both. <Rovanion>leoprikler, baryluk: If the package is not in pypi but something unpublished? Is there anything that can help me there? <xelxebar>Is there some baked-in way to check the word size of a build target machine? I need to do different build steps depending on whether it's 32- or 64-bit <wleslie>is there a way I can get host /usr/bin/glxinfo and .guix-profile/bin/glxinfo to agree on available features? <wleslie>how do the elements of package-outputs map to the contents of the build directory? <xelxebar>wleslie: If I correctly understand your question, then the "out" output goes to /gnu/store/<hash>-<pkg>-<version> and all others go to /gnu/store/<hash>-<pkg>-<version>-<output>. <xelxebar>See `guix build glibc` for a good example. <efraim>have ve decided if gnupg gets updated in master despite having more than 300 dependencies? <wleslie>of where they go I am familliar, but where they come from, I am not <vits-test>1.2 announce tells that now some --flags have a permament effect (why so?). should i stop use --flags just to not make something permament accidentally? ***apteryx is now known as Guest92284
***apteryx_ is now known as apteryx
<civodul>efraim: i noticed "guix time-machine --commit=66f769122f -- build grub-minimal --target=i586-pc-gnu" works but it's broken in later revisions <civodul>not sure why though because the freetype change looks right to me <civodul>efraim: could you explain how to reproduce what 34a6f123514b5677d442ed7cd609ff01534904b8 is fixing? <efraim>it uses the BUILD_FREETYPE vars for compiling build-grub-mkfont, but only under certain circumstances. I thought i was being clever with (or native-inputs inputs) but apparently I was too clever <civodul>because --target=mips64el-linux-gnu should be very similar to --target=i586-pc-gnu <civodul>it's surprising that one can work and not the other <efraim>civodul: I was running 'guix build --no-grafts grub --target=mips64el-linux-gnu' while trying to build a disk image <efraim>on mips64el it fails if you try to build it without the build-grub-mkfont <civodul>removing freetype from native-inputs in grub-minimal "fixes" the problem <efraim>grub-minimal is still broken for i586-pc-gnu? <civodul>oh i see, without freetype in native-inputs, it has: <civodul>Build-time grub-mkfont: No (freetype2 library unusable) <efraim>I suppose we could just add freetype as a native input when its (%current-target-system) for mips64el <civodul>mothacehe, cbaines: by looking at Cuirass, i wasn't able to tell when the "childhurd" test started failing <efraim>haven't tried natively compiling grub on mips64el yet to see if it still builds correctly <civodul>ideas on how to get that info, either from Cuirass or the Data Service? <efraim>right now I'm the only user of grub for mips64el, so either it was building natively fine before and should continue, or it wasn't before, worked with my patch and might break again when only adding it for cross compiling <cbaines>civodul, at the moment, the Guix Data Service doesn't have build information on system tests. Cuirass is building different derivations to what's associated with the system test, and I haven't got an instance of the Guix Build Coordinator building them yet <efraim>we could just add it for (or (%current-target-system) (%current-system)) mips64el-linux <cbaines>but I'm hoping to start building system tests soon <civodul>efraim: what triplet are you using? mips64el-linux-gnu? <mothacehe>and nothing after that, which is probably a Cuirass bug <efraim>looks like grub-minimal also was failing for mips64el-linux-gnu <civodul>mothacehe: yes, but that doesn't tell if it then started failing :-) <efraim>/var/log/guix/drvs/mm/vlp47fp3xw6vv1br17rnx03m2k7xk6-grub-minimal-2.04.drv.gz on bayfront <civodul>mothacehe: so yes, it looks like it's filtering out failed builds <civodul>ah yes, and failed builds "never complete" in its view (?) <mothacehe>that could be a reason, adding it to my Cuirass fixing list :p <civodul>i could have taken a look myself but i wondered if you already knew the answer <civodul>mothacehe: yesterday i was telling cbaines that we could have weekly meetings to discuss offload/dynamic-offload/coordinator/CI progress <civodul>with the goal of making sure we make progress towards better CI and that we find ways to converge <mothacehe>I think it's a great idea, I also thought about it during Guix Day. <civodul>yeah 1h was too short to really get into the details :-) <mothacehe>sure, I'm mostly home so it shouldn't be too hard to find a time slot! <civodul>looks like in 2020 we're all mostly home ;-) <civodul>if we keep Fridays for patch review, then we need another day <mothacehe>hehe, what about thursdays in the afternoon? 30 minutes could be nice at first? <cbaines>this week works for me, even though I'm also at home, I'm working during the day, so after 17:00 CET would be best for me, unless you want to start early like today <civodul>early in the morning may be easier for me <leoprikler>Rovanion: (guix import pypi) has a parse-requires.txt, but the format is probably different from requirements.txt, idk <civodul>as a first topic i'm interested in hearing about your experience running the Coordinator on berlin, mothacehe <mothacehe>fine by me, maybe we could use the bbb instance? <civodul>each can pick one thing they'd like to discuss/show <vits-test>> 1.2 announce tells that now some --flags have a permament effect (why so?). should i stop use --flags just to not make something permament accidentally? <l1x>hi folks, where can I find more documentation on how guix builds a kernel and a package? *rekado_ drafts a blog post about music production with Guix <vits-test>idk what happen, but w3m stop opening guix.gnu.org for me. <vits-test>l1x: basically, gnu/packages/linux.scm provides the 'make-linux-libre*. <vits-test>l1x: also i use a slightly customized kernel <l1x>vits-test: do you have any post/blog/comment/doc/html/txt about it? i need to create a slightly modified kernel for a project <vits-test>l1x: please see above, messy, bad style, but works. <l1x>vits-test: excellent this is exactly what i need! thanks a million!! <vits-test>should admit, 'custom-local-file works only sometimes. <nckx>vits-test: Because it's the right thing to do. Imagine you ran ‘guix install emacs-no-x’, then one day ran ‘guix upgrade’ and Guix silently replaced it with the full emacs. Wrong, right? Transformation options are the same: ‘guix install --with-debug-info emacs’ installs a different package from than ‘guix install emacs’, and Guix now remembers that fact. So this change actually fixes --flags and you should use them more often now 😉 <vits-test>nckx: but it is easy to forget about once applied flag? arn't manifests superior? <nckx>vits-test: It's exactly the same as forgetting you once ‘guix install libreoffice’. <vits-test>civodul: haha. i cannot w/o calculator most of the times. <nckx>Manifests are certainly superior (er, IMO, of course ☺) but this improves the CLI side. <vits-test>nckx: if flags stored like .config/guix/packages/customizations/scheme/8aseihfa/gnu/packages/emacs.scm, then i'll just rm it all once in a time. <nckx>That's your prerogative, but you're changing the nature of the package you once installed. <civodul>you can "forget" package transformations by running "guix install the-package" <nckx>vits-test: You're doing the rough equivalent of ‘guix remove --transformed blah && guix install blah’ by using a very private API. <nckx>I mean s/rough/roundabout/. <vits-test>civodul: if this happiness applies only to upgrade command it's far better, thank u. <civodul>mothacehe: on berlin, we just consumed 400G in /gnu in 2h <nckx>vits-test: This sounds a bit like an X-Y problem to me personally. You were counting on a bit of a bug: a small part of your profile was less permanent than it should have been. But ‘guix install’ is supposed to be permanent. Use environments if you want Guix to do your forgetting for you, and get that ‘clean’ feeling when you exit. <nckx>vits-test: What else did you think it applied to? (Curious.) <nckx>Oh, I think I know. No, ‘guix install --with-debug-info emacs’ won't set some magic horrible state flag somewhere that suddenly makes any mention of ‘emacs’ on the command line the debug-emacs. <mothacehe>civodul: terrible. It would be nice to have a breakdown of those new store elements. I guess most of them are images related to system tests. <civodul>mothacehe: yes, we could check cuirass.log actually <civodul>yeah, partition.img (many of them!), image.iso, qemu-image <mothacehe>Yes, or extract it from the database. Even though we save those items only as nar files, it will still take a lot of space. <civodul>in fact, looking at that log, it looks as if Cuirass builds nothing but images <mothacehe>it means that we need a new strategy for system tests <nckx>Hey that's not fair, it also builds some packages as a side-effect. <efraim>civodul: i like the grub-minimal fix, I was looking at something similar <efraim>l1x, vits-test: the custom kernel config stuff is a bit rough, it's probably time to re-do it and make sure it still works <civodul>mothacehe: this is coming from the installation tests i guess, and perhaps also from the image jobs? <civodul>efraim: yeah sorry, i went ahead as this was preventing me from rebuilding my childhurd :-) <efraim>civodul: no problem :) better fixed than broken <nckx>I'm (eternally) catching up on listmail and the Guix Build Coordinator sounds like an absolute treat. Can't wait to see where it goes. Thank you, cbaines! <vits-test>abcdw: great; possible some hidpi owners will switch to wayland. <mothacehe>civodul: there are only 3 image jobs vs 14 installation tests <mothacehe>plus maybe other system tests requiring image production <civodul>so yes, like you write, we may have to run them less often <civodul>yes but those are not rebuilt at each commit <abcdw>vits-test, yep, that's the point) Hope this fork will be merged in emacs in the near future. <mothacehe>civodul: right, I'll think about some strategy that we can discuss on thursday <PurpleSym>Is it possible to somehow introspect Guile modules, i.e. get a list of all exported symbols? Trying to build all packages in a file without knowing their names in advance. <PurpleSym>leoprikler: I can’t find any documentation on that function :/ <xelxebar>leoprikler: Holy crap! That's insanely useful. I need to actually read the guile docs. <xelxebar>Oh, dang, ,apropos doesn't search through unloaded modules for you. <leoprikler>Apropos gives you the type (quasi) and describe the documentation <l1x>efraim: could you give me a link where can i find the code for the kernel stuff? <l1x>i would be interested in reading it <wleslie>gcc is looking for system headers in /gnu/store/*-capos-newlib-*/include, but newlib has placed them in /gnu/store/*-capos-newlib-*/i386-unknown-capros/include. is there a nice way to chop off the /i386-unknown-capros folder in the output? <leoprikler>wleslie: passing some #:configure-flags hopefully, otherwise patching the build system <wleslie>I've been making guesses about what configure flags might chop it based on the configure file and makefile templates, but no luck yet <wleslie>I currently have --with-sysroot=/ and --with-target-subdir=. <wleslie>tbf it might be worthwhile overriding the default gcc configure flags myself <wleslie>I don't think I'll ever be up to scratch with this stuff. <wleslie>I guess I can movl all I like, I just better not think about pushling or popling. *civodul test-drives Ivy + Counsel (instead of Helm) <civodul>next time we have an in-person Guix meeting, it'll be useful! <civodul>one thing to pay attention to is that substitute lookup cost is +/- proportional to the number of URLs in substitute-urls <mothacehe>oh could be nice to add a maximum number of substitute urls then! <civodul>so if everyone at your workplace uses Guix and you find 20 publishers, substitute lookup could perform very poorly <civodul>also, assuming locally discovered publishers are untrusted (usually the case), they should be added in front of the URL list <civodul>(i haven't checked if that's what the patch does) <mothacehe>yes, it what it does, following the blog article you wrote few years ago <civodul>regardless of whether or not they're trusted, actually <civodul>publish could publish its signing key in a "txt" property too <mothacehe>yup + guix version and other informations maybe <civodul>i would also be nice if we could avoid inversion of control in Guile-Avahi, but maybe not a blocker <civodul>i'd call the options "avertise" rather than "enable-avahi" <civodul>not a proper patch review, but that's a start :-) <mothacehe>hehe glad to have such fast feedback :) Yup "advertise" sounds better. Not sure what inversion of control you're referring to though. <civodul>the "Hollywood principle" ("don't call us, we'll call you back") *civodul should be doing boring stuff but seems to have entered a reciprocation/evaluation/procrastination loop <GewaltDisney>i'd like to give guile emacs a spin, but it gets stuck in the build phase everytime i try to: guix package -i guile-emacs <GewaltDisney>i'm using guix from PopOS (ubuntu), and i havent had any problems with other packages <GewaltDisney>but i'm pretty new, and haven't "dived in properly" to guix yet, so any advice would be appreciated <civodul>GewaltDisney: hi! note that the build phase probably takes a while (maybe it's not stuck?), and more importantly, guile-emacs is still very much experimental <civodul>the code hasn't been touched in a while, i think <GewaltDisney>thanks for the response! if the progress indicator slows to a near halt, is it still building? i had it running overnight, and it was like that, which made me imagine it froze <GewaltDisney>and i understand that its still experimental, but the idea of hacking emacs in scheme is too good :D <civodul>damn it, i find myself whistling "Ode to 1.2.0" <mroh>made the jump from helm to ivy/counsel some weeks ago. In <mroh>looking back, I realized how "brutal" helm is/was ;) <civodul>OTOH, i know i miss a few things, like git-grep from find-file <civodul>but so far i don't seem to miss it too much <zzappie>I think you can use ivy-set-actions for that <mroh>only issue I have so far is: if a tramp buffer is opened, M-x ivy-switch-buffer (and counsel-switch-buffer) is very slow for some reason. <civodul>i've sort of internalized the fact that using Tramp has undesirable side effects :-/ <zimoun>civodul: did you finally switched from Helm to Ivy/Counsel? <civodul>i don't know yet if i'm staying, i'll see how it goes :-) <euandreh>Hmm, what are the selling points? I'm with helm for some time already <civodul>essentially it's more lightweight, more discoverable, and i'd say "less weird" <zimoun>civodul: I did the same, try it and see how it goes… now it is several months :-) <efraim>nice work on the mupdf update, I've changed etui to link against upstream mupdf instead of my hacked copy <dissoc>is there a modsecurity package? I thought i've seen one in the past. maybe im remembering incorrectly <nckx>jackhill: That's probable, thanks. <sneek>Welcome back nckx, you have 1 message! <mroh>I try `guix deploy` for the first time and it looks like the target machine doesn't like my initrd. Perhaps, a skip-checks? (and maybe no-bootloader?) boolean in the machine-ssh-configuration would make sense? <g_bor[m]>I also have the feeling that it would not be so hard to do. <g_bor[m]>I believe roptats's idea about fixed output packages goes along the same line. <civodul>drakonis: thanks, i did see the Tweak posts, hard to avoid ;-) <civodul>it's interesting; i find the solutions discussed a bit complex though, but that's probably the price to pay <g_bor[m]>I am aware that in Elco's thesis there was a method to strip the self references. <g_bor[m]>The main problem there seemingly was reproducibiility. <g_bor[m]>What do you think about a hibrid approach, where we only content address reproducible packages? <civodul>yes, most of the work was in Eelco's thesis, with the exception of a way to gradually migrate from one model to the other <civodul>g_bor[m]: to me, as it stands, the cost/benefit ratio doesn't cut it <g_bor[m]>The main benefit I see is from the bootstrapping perspective, where we can stage the bootstrap layers on a content addressed set of packages. <g_bor[m]>That wa different projects with different needs can choose their trustbase without too much work to be redone. <g_bor[m]>Actually there seems to be not too much problem with allowing to live the store items in two locations, one with the current scheme, and one on the cas location. <rekado_>g_bor[m]: didn’t we discuss and explore the use of ORIGIN to avoid having to hardcode references in lots of places? <g_bor[m]>But actually the do not cause too much problem. <g_bor[m]>We have all the tooling needed to make this work already, even if they are hardcoded. <civodul>i'm not sure i understand the motivation <civodul>using ${ORIGIN} some more would be nice <civodul>we'd need to study what fraction of self-references come from RUNPATH though <civodul>there are self-references for locale data, for example <rekado_>aside from the CAS stuff (my position on this can be described as an enthusiastic “meh.”) I think it would be great if we could think up a better hack than RUNPATH for library lookups. <rekado_>there’s a noticeable delay in starting complex applications due to searching. <civodul>(which is ok on my SSD, but much less on NFS or spinning disks) <civodul>the only solution i can think of would be to create a union of all the things that appear in the RUNPATH, and change the RUNPATH to contain that one entry <civodul>but it's not entirely clear to me that it'd be faster <civodul>because resolving symlinks also induces i/o <rekado_>maybe we could use a per-application ld cache? <civodul>ah ha, yes, that's probably smarter! <civodul>it probably requires changing ld.so though <civodul>in Helm find-files, i could C-j to view a file without leaving the list of candidates <kozo[m]>Is the guix website suffering from the release of 1.2? =P <civodul>of course we put a huge amount of resources behind it so it would be able to support the load <zimoun>civodul: I do not know, I haver never tried to do it with ivy <phil>hello, I'm running into a lot of confusion installing emacs packages via guix <phil>from what I understand I can just require the package from my init.el after installing it right? <phil>in this case i'm trying to install emacs-geiser <phil>so I put (require 'geiser-install) in my init.el but emacs couldn't find it <phil>I should add that /run/current-profile/profile/share/emacs/site-lisp is in my EMACSLOADPATH so I don't think that that is my problem <phil>does anyone have any experience installing emacs packages via guix? <kozo[m]><civodul "dunno, works for me! why?"> I haven't been able to connect to it for 2 days. I wonder what's wrong on my end then <vits-test>phil: `guix install emacs-...`, start new emacs-session. also there was some guix-command to not restart the emacs to get new things. <abcdw>phil: you do not need to require geiser-install I think. <vits-test>phil: my init lacks any 'require, and geiser works (just as w3m). <kozo[m]>civodul Yes, guix is loading up on my phone on LTE. I'm guessing quad9 isn't resolving to the site... Thanks for letting me know it's working <abcdw>phil: geiser-install is necessary for manual installation from source code as I can see from manual. You can just require 'geiser itself. <phil>vits-test right so I have emacs-geiser installed and I restarted emacs but none of the geiser commands are available <phil>abcdw: Hmm, I get "cannot open load file 'no such file or directory 'geiser''" <abcdw>check the load-path variable value <phil>yup, basically there's /run/current-system/profile/share/emacs/site-lisp <phil>and /run/current-system/profile/share/emacs/27.1/* <jsoo>also did you install those packages in the packages field of an operating system definition? <phil>emacs-geiser I installed directly <jsoo>via guix package -i emacs-geiser? <phil>emacs itself I think is isntalled in an operating system definition <jsoo>what is the value of $GUIX_PROFILE? <phil>If I understand what that mean correctly <jsoo>i think you do understand <phil>GUIX_PROFILE isn't defined <phil>is that something I should add to my bash profile <jsoo>when you installed emacs-geiser, did you follow the instructions to set $GUIX_PROFILE and source /etc/profile? <jsoo>well if you installed as your user, your profile is probably in ~/.guix-profile. do you see the lisp libraries there? <phil>nope I don't recall seeing those, I'll uninstall and reinstall it to see if that pops up <jsoo>ok cool. another test you can try is something like: guix environment --ad-hoc emacs-geiser -- emacs <jsoo>in that emacs process, you can check if geiser is available <phil>Oh that's where they are! <jsoo>it's possible that you just need to source /etc/profile like the instructions from guix package say, then <jsoo>that should setup the path variables that you need <phil>ok I think I'll most likely be able to figure it out from here <phil>thank you all for your help <pineapples>Hello Guix. Today I've got a peculiar error during guix reconfigure: "File system check corrected errors on /dev/sda1; continuing" and "In procedure mount: "mount /dev/sda1 on ///boot/efi: Device or resource busy". Running the command again yields a similar result, but the "File system check corrected errors" message is gone. Is this possible that the file-system-/boot/efi service could corrupt the ESP? <pineapples>It should be noted that this is in a virtual machine <kozo[m]>guixy I've done it to 3 stations at once <guixy>What are the requirements for the target machines? <kozo[m]>you need guile-ssh installed on client, root access to client <vits-test>guixy: note that kozo only said "I've done it..", but not specified the result :P <kozo[m]>I also made a (simple-service) that copies the deployed config.scm to the client <guixy>I want to do it to 3 machines, but I'm not sure where to begin... <guixy>They would all need different bootloader configurations... <guixy>If I'm successful, I'll make a vid for guix to show how it's done. <kozo[m]>Would you like to use my code as a base? <guixy>Right now I'm putting guix installer on some microsd cards so I can install a base system to hack later. <guixy>There are a lot of things I'm surprised nobody has added services for. Like all these games with headless servers. <guixy>clamav-service is on my todo list as well. <luis-felipe>rekado_: Nice song, I'm listening to it several times a day :) <user_oreloznog>Yes, nice song, and congrats, luis-felipe for the nice picture :-) <lfam>I hadn't seen the picture. It really is good <lfam>It would be great for a t-shirt! <luis-felipe>rekado_: I'd like to see a post describing what you use to make your music. <lfam>Does anyone know the status of XFS on Guix? I see there is a kernel panic related to XFS in 5.9.9 <luis-felipe>thanks user_oreloznog, lfam, I'm going to use it on some apparel. <lfam>luis-felipe: Does that mean we can buy something? :) <luis-felipe>lfam: Yes, on my store (I don't promote here because it sadly uses non-free JS and mainstream tracking). <lfam>Okay. I think you should feel free to promote it here. At least, I don't want to miss it <nly>./usage.scm '(srfi srfi-26) file.scm -> <nly>((#f cut) (#f cute)) ;; file.scm does not use srfi-26 <civodul>luis-felipe: agreed on the music and "looooo", and big thanks for the pretty image! <civodul>can't wait to see it on mugs, tshirts, and whatnot :-) <nckx>lfam: A Guix-specific kernel panic? <lfam>nckx: No, something in linux itself <nckx>Creating/mounting/... XFS by hand should work just fine but no part of Guix System supports it yet. <nckx>We're probably the only distro that added JFS before (still missing) XFS support ☺ <nckx>Does IceCat support Geckodriver, and does anyone happen to be sitting on a package for it? <rekado_>luis-felipe: I’m flattered :) I’m glad to have been able to contribute to the cultural commons of this community <rekado_>luis-felipe: I’m working on the blog post as we speak <roptat>luis-felipe, is there a license for the illustration? <nckx>jonsger: A part of scripting the browser through Selenium. <nckx>Selenium is a library for automating browsers and Geckodriver is the Firefox back end for it. *civodul fearlessly removes trailing #t from phases on core-updates <civodul>it's a part of our traditions that will fade away <civodul>and i know many of us will be saddened to see them go <davexunit>I always say #t before I go to sleep, just in case. <davexunit>also how I did not realize the verse lyrics spelled out REPL!?!? <rekado_>if you listen carefully to the outro you’ll hear an out of breath “REPL, REPL, REPL, REPL…” looping at infinitum. <dissoc>speaking of chromedriver and selenium, do any of you know if the guix package/ ungoogled-chromium does much to reduce finger printing? <dissoc>or have any of you made a custom package? <PotentialUser-68>hello. i hate to ask this, because i respect the mission, but can someone point me to resources on how to run the vanila kernel instead of the libre kernel, firefox? life and family dictate how much friction I can permit, i have to pick my battles and start somewhere... <mbakke>dissoc: I don't think ungoogled-chromium has any built-in fingerprint resistance <dissoc>mbakke: that's kind of the impression i got from checking it. i guess i'll just work under that assumption <mbakke>dissoc: IceCat does pretty good on that front, though <mbakke>PotentialUser-68: there are Guix "channels" with those packages that you can find with a well-crafted web search <mbakke>civodul: what's the scoop on those trailing #t's? :-) <PotentialUser-68>unrelated and silly (new here), if i just want to update the system, do i run `guix pull` and reconfigure with sudo or as the logged in user? it seems to permit both? <mbakke>PotentialUser-68: that blog post is good if you want to run a custom kernel indeed <mbakke>PotentialUser-68: you can reconfigure either as root or through sudo, you choice :-) <dissoc>PotentialUser-68: that's a starting point of doing it yourself. however there are already packages to do what you are asking. you just have to add a channel (and verify the code). probably path of least resistance if you're just taking guix for a test drive <PotentialUser-68>mbakke: what is the difference between reconfigure as root vs user? thats the confusing part for me <mbakke>PotentialUser-68: with sudo, reconfigure will use your users guix (the one you get with 'guix pull'), but when you are logged in as root, it will use the root users guix (i.e. you need to run 'guix pull' as root to get the latest code) <mbakke>PotentialUser-68: the difference is in what 'guix describe' says for each user <PotentialUser-68>dissoc: im in for the long haul, with either nix or guix, because I am throroughly sick of the dependency hell that has been my career, etc etc. im not too concerned with initial time investment, but not having hardware support and not having a "standard" browser that i can use to do my job would just nudge me toward nix. i do prefer guix conceptua <PotentialUser-68>lly, the declarative language part of nix im not too keen on (seen it fail too many times) and i actually care about GNUs mission quite a bit, im at that point... just have to pick my battles as i said. im ok invensting time into doing the kernel on my own because i will learn a lot and get a true sense of the system/package manager. in other words <PotentialUser-68>mbakke: sorry for being dense, still dont see the practical difference, it sounds like root is not in any way special as a user? can root have its own kernel or something? <lfam>Reconfiguring the system requires root privileges, in all cases <lfam>The disinction is that `guix pull` is per-user, and provides the set of available packages <lfam>It's like a per-user `apt-get update`, if you are familiar with Debian <lfam>So, `guix pull` determines what packages are availabe, their versions, as well as services. <dissoc>PotentialUser-68: it might be useful to take a look at linux-libre in gnu/packages/linux.scm <lfam>Great :) Please feel free to keep asking questions! <euandreh>PotentialUser-68: There's also the very good qutebrowser, other than the frequently mentioned icecat <lfam>PotentialUser-68: Another bit of advice on this subject. The way that Guix does things "per-user" is by setting up some environment variables when the user logs in. This means that, if you want to elevate privileges to use a feature of Guix, it's important to elevate in a way that creates a login shell. That means `sudo --login` or `su --login` <lfam>But, if you wanted to reconfigure using your normal user's view of Guix, you'd want to preserve that user's environment, and so you'd use `sudo --preserve-env` <PotentialUser-68>euandreh: thank you, ill check it out, for my personal browsing need i think icecat, etc. will work great, even GNOME Web is a wonderful thing to have, the few browsers driving the entire web is very concerning to me, work stuff will go into a VM anyway... <mbakke>I don't think 'sudo -E' is actually necessary, because the 'guix' executable obtained with 'guix pull' is self-contained, i.e. it does not rely on any variables from the profile <mbakke>I sometimes invoke /var/guix/profiles/per-user/me/current-guix/bin/guix directly as a different user to avoid pulling :P <mbakke>sudo --login or su --login is definitely required though, when switching users <PotentialUser-68>lfam: that is very helpful, thank you. i did notice a treatment of the `-i` (ie --login) parameter in the manual, but your description made it clear. as an aside having an actual manual made me shed a tear of joy... <civodul>mbakke: hash-tee! well, there was, i dare say, consensus on getting rid of them, provided the value of return phases is actually ignored (which is not the case in 'master') <civodul>even though like davexunit i got used to saying "hash tee" before going to be or as a way to say goodbye <mbakke>civodul: sounds good, the requirement always seemed somewhat arbitrary to me <civodul>i am not removing all the #ts though; each one of us should have the opportunity to remove a bunch of #ts <mbakke>civodul: yes, please don't! I'm getting merge conflicts in my mind already. <davexunit>now someone needs to write "an ode to hash tee" <civodul>mbakke: should be ok to remove them from {base,commencement}.scm though? <mbakke>civodul: yes, low-level stuff is fine <adfeno>Hi all, a friend of mine is trying to use obs from guix, but he needs v4l2sink obs extension to make virtual webcam appear in obs, does anyone know how to do so? <roptat>I don't think we have it packaged <mroh>adfeno: try the v4l2loopback-linux-module <nly>you need v4l2loopback-linux-module in (packages ...) <adfeno>Does it play nice with Guix in foreign distros (non-GuixSD) ? <mbakke>adfeno: being a third-party kernel module, you would need to compile the trisquel kernel with it <rekado_>the first draft of the blog post is ready; I still need to take a whole bunch of screenshots and edit them, but at least the text is pretty much done, I think. <rekado_>should I send it to guix-devel or would it be better to send it to someone (or sometwo or somethree) else first? <mbakke>adfeno: you could try to find a similar kernel revision in guix, run 'guix time-machine --commit=$revision_with_trisquel_kernel -- build v4loopback-linux-module', and "insmod" the resulting .ko file <adfeno>mbakke: But, does Guix's obs recipe work well with system kernel (and modules) once v4l2loopback is built in Trisquel, or do I need to tell obs to do something else? <mbakke>adfeno: if you can load the module, obs should be able to find it <lfam>Does anyone know about how Qt handles user interface icons? <lfam>I'm reviewing the qpdfview package from the patch tracker, and the UI icons are all missing <civodul>rekado_: you can also push it under the drafts/ directory and send the link here if you want <mbakke>lfam: is it consistent? IIRC the wpa-supplicant-guix package sometimes loads its icon, sometimes not :/ <lfam>I haven't noticed this problem in the past, but I noticed it ~last-week while working on another Qt package, Vorta <lfam>(This is on Debian, btw) <mbakke>lfam: do you have QT_PLUGIN_PATH pointing to your profiles "lib/qt5/plugins"? ( I really don't know much about Qt either) <lfam>Thanks for the hint, I will check <lfam>I have a '~/.guix-profile/lib/qt5', but not the final 'plugins/' component <lfam>And setting the variable to point to that existing directory does not help <mbakke>lfam: try installing 'qtbase' and 'qtsvg' to the profile (or use 'guix environment --ad-hoc') <mbakke>lfam: qt-build-system unconditionally adds a wrapper with that variable and those variables IIRC <lfam>So, I need to cherry-pick that wrapper phase into this package <lfam>Or check if qt-build-system works <lfam>Is it the oldest open bug? <GNUtoo>hi, I'm unsure if it's the right channel to ask as it's more a guile question, <mbakke>at least the oldest important bug, I think <GNUtoo>When looking at certbot.scm here there is some things like (if email <lfam>Twenty-thousand level... that's a number I've not seen in a long time <GNUtoo>If I want to add a "--standalone" string to it if standalone is #t, what should I do exactly, or is there guile reference I should read before? <lfam>Would that case be independent from the (if email) part, GNUtoo? <euandreh>GNUtoo: Why not follow the pattern, and add a (if standalone "--standalone" '()) <rekado_>civodul: thanks, I’ve pushed it to the guix-artwork repository <lfam>Based on my understanding of certbot, I think that the standalone option and the email registration are independent from each other <lfam>Yes rekado_!!! You wrote the blog post I've been wishing for :) *mbakke continues reading <rekado_>lfam: it’s very much tied to the release song, so please let me know if you think I should go into any more detail or lean a little more into recommendations for generic music production purposes *rekado_ fixes typos now… <mbakke>rekado_: nice post! even though many of the terms are alien to me, I enjoyed reading it :-) <mbakke>now, those package URL's are going to 404 in a not too distant future.. <rekado_>thanks! Do you think I should define a few more terms? <mbakke>hm, wasn't there a patch somewhere to provide unversioned URLs? <rekado_>I gotta go now, but I’ll read all comments tomorrow *mbakke is all too busy these days, but can hopefully try it in the weekend <PotentialUser-70>the ISO (but compressed) took only like 1.2 sec to download.. it was incredible <euandreh>What part of the installation you're on right now? <PotentialUser-68>PotentialUser-70: once you install the OS you can add the "-M 8" flag to "guix install" which will download 8 things in parallel, that sped things up for me <euandreh>It may indeed take some time when building things :/ <euandreh>The build farm builds packages in advance so that you don't need to build them locally, PotentialUser-70. But as you have just installed the OS, the build farm may have not catch up yet <civodul>i only had a vague idea of what it entails to "produce music" with digital tools, i learned a lot <PotentialUser-70>ok I'm only complaining, but it help me to wait about all thse process :P <civodul>and... woow, congrats for getting all that done in so little time <roptat>shouldn't we have substitutes for version-1.2.0 already though? <civodul>rekado_: and it's such a pleasant read too! <civodul>i could picture you also writing a novel or a poem for 1.3 :-) <civodul>yes and even the article was written at the speed of light <roptat>PotentialUser-70, super, ça devrait bientôt être cuit :) <roptat>still, guix is very slow... we should really improve that for 1.3.0 
