IRC channel logs


back to list of logs

<nckx>podiki[m]: I'm all about professionalism, and so is Guix®.
<podiki[m]>...I can't even make that (R) without copy/pasting, shows you how professional I am!
<nckx>podiki[m]'s typing notification reminds me why I don't use [m].
<nckx>Can one disable that?
<podiki[m]>not to get too off-topic, but I remember when that was a new thing back in the days of AIM and the like, with a plugin that would say something like "you feel a tremor in the force" before someone messaged you for the first time
<podiki[m]>you probably won't see mine now (just turned it off)
<florhizome[m]><mekeor[m]> "jgart: nice patch submission..." <- There are definitely gnu projects that don’t stick to GNU solutions only
<nckx>podiki[m]: I am Element Web peasant, and don't see it in the settings.
<podiki[m]>nckx: at least on Element you have control over whether you send them and if you want to see them; scroll down in preferences
<podiki[m]>did the nheko update make it in guix? there were patches and I wanted to try out some new clients too
<jgart>podiki[m], I've been working on gomuks here:
<jgart>Only three deps left and then I'll send to upstream
<nckx>podiki[m]: Thanks.
<podiki[m]>jgart: cool!
<podiki[m]>I should try out the emacs matrix client....
***nckx[m] is now known as matrixlurkerbot
<jgart>matrixlurkerbot, botsnack
<florhizome[m]><podiki[m]> "I should try out the emacs..." <- It’s pretty good :)
<excalamus>newb question, when is the "[m]"
<excalamus>what is*
<podiki[m]>indicator for a matrix user (connecting with the bridge for
<excalamus>okay, thanks
<podiki[m]>(depends on some bridge/client settings how it appears, on the matrix side you don't see it probably)
<nckx>It's only a default, though; you can change your nick (and use completely different names on both sides of the Matrix/IRC bridge for ultimate confusion:
<xelxebar>After much blood, sweat and tears, I have a small procedure that takes a package object and builds its output. Is this reasonable-looking at all?
<xelxebar>The actual script sits in a git repo, and defines a package sourced from the local working directory. I want to make changes and ensure the build outputs are binary-equivalent.
<xelxebar>The method yak I have successfully shaved so far is a guile script that programmatically builds the package, hashes the contents (with (guix hash)'s 'file-hash*' proc), and then compares that to a known good hash.
<singpolyma>xelxebar: you may be interested in comparing with the strategy I use at the bottom of guix.scm in
<Newfangled>Hello, Guix. I'm trying out Guix System for the first time on a VM. I'm not new to GNU/Linux, but I wouldn't say that I'm a power user or fluent in doing everything via the terminal.
<Newfangled>I am reading the GNU Guix Reference Manual and tinkering with Guix System. I have to say, I really love the beautiful simplicity of package management in Guix. Every operation being a transaction that you can roll back if you break anything is brilliant.
<excalamus>Hello, Newfangled
<excalamus>cool, glad you like it. The people here like it, too :)
<xelxebar>singpolyma: Wait what?! First, that family of projects looks like something I've been wanting for years! Second, are those Japan number prices real?! Third, eval... how?... I have no idea what is going on.
<singpolyma>xelxebar: Japan prices? Oh you mean from Vonage? They came from the Vonage website, I doubt anyone has tried that
<jgart>singpolyma, is that git repo using BYOD or are you self-hosting sourcehut?
<jgart>oh BYOD is only for
<singpolyma>xelxebar: in the guix.scm basically I double escape the package definition and then eval in stages, so it can both be used directly or written out in CI to reference a particular built git hash
<singpolyma>jgart: neither, it's a lazy HTTPS rewriting proxy
<singpolyma>If drew adds BYOD I'll probably switch to that
<jgart>ah ok cool!
<jgart>is the https rewriting proxy something cool you built?
<singpolyma>It's basically 8 lines of Apache config
<jgart>oh ok
<singpolyma>Rewrites some of the HTML so the links work out etc
<xelxebar>singpolyma: Oh. I thought eval was somehow magically building. But you're still passing to the 'guix build' cmdline. Okay.
<jgart>nice open-pipe* on l639 for the version
<singpolyma>Using the same trick for
<singpolyma>xelxebar: yes
<jgart>re: soprani todo: very nice
<singpolyma>If you look in the .builds/guix.yml in the same repo you can see how the CI baking works
<jgart>singpolyma, what do you do with the `plzip cheogram.nar`?
<singpolyma>jgart: I unzip in on our production server and guix archive --import
<jgart>got it
<singpolyma>Then install the package using the baked scm and it does no building
<jgart>so to some debian machine?
<singpolyma>Just use the store items CI built
<singpolyma>Yes, a Debian machine
<jgart>singpolyma, is the https rewriting proxy code online anywhere by chance?
<singpolyma>guix copy would be more efficient but then (a) CI would need to access the server and (b) guix copy has a bug where it ignores --no-grafts right now
<singpolyma>jgart: it's not, but I can grab it one sec
<jgart>oh sweet, thanx!
<jgart>That's much appreciated
<jgart>singpolyma, are you interested in caddy server at all? I'm trying to round up some guix peeps to mob package it with me:
<Newfangled>Hello, KE0VVT!
<jgart>singpolyma, thnx!
<singpolyma>jgart: hmm, I've been curious about caddy but so far our plan is to move to nginx
<jgart>very cool
<singpolyma>I've been sending in some patches to improve the guix go importer that might help you though
<jgart>I've mostly used nginx. I'm less familiar with apache but I should maybe learn it better
<jgart>singpolyma, re: go importer: Oh cool!
<jgart>singpolyma, can you link me to that issue?
<KE0VVT>Newfangled: hi
<jgart>has it been merged?
<singpolyma>I think nginx could do this to, but the old server where it's still running is apache
<singpolyma>jgart: bug number 52362
<jgart>I'll check it out
<singpolyma>I want to package headscale and/or flyctl, but post have a massive dep list so I need the importer in good shape to have a hope
<jgart>yup, I think that will help out with packaging hugo
<jgart>hugo has a huge amount of deps
<jgart>ryanprior[m], has been working on hugo
<ryanprior[m]>I'd love to have flyctl singpolyma
<ryanprior[m]>Hugo has been a bear, I packaged a ton of stuff but that was all before the go importer
<ryanprior[m]>Might be less grunt work now, but there's still a huge list of packages to grind through even if you're just verifying them for correctness/integrity
<singpolyma>flyctl has 2162 deps, so I think I'll get it to working, but getting anyone in guix to review might be a no go 😅
***jonsger1 is now known as jonsger
<ryanprior[m]>Yeah Hugo is in that vicinity as well.
<jgart>That's when I say: `nix-env -iA u.flyctl`
<singpolyma>I figure that for packages where I'm not in a hurry (read: don't need for work) I'm better off improving importers rather than fixing their output is skipping
<jgart>That sounds like a very smart thing to do.
<jgart>I hope 52362 gets reviewed soon
<jgart>I'm trying to test composer-build-system (php support in Guix) here:
<jgart>If anyone would like to help out by reviewing that code it would be much appreciated. It's an effort to resolve this long standing issue:
<jgart>Then we can finally say "Guix 💛️ PHP"
***califax- is now known as califax
<Andrew>Hmm, when I was compiling dwm it couldn't find libx11
<Andrew>installed libx11 both as root and as user
<jgart>Andrew, how were you compiling dwm?
<jgart>`guix build dwm`?
<jgart>or you mean compiling it with make in a guix shell?
<gnoo>guix shell --check --development emacs gives: guix shell: warning: variable 'PKG_CONFIG_PATH' is missing from shell environment
<gnoo>how can i fix it?
<AndrewYu>Oh, I just used 'make' in bashs
<gnoo>instead of installing as the user, you can use guix shell
<AndrewYu>ill see what that is
<gnoo>guix shell --development dwm
<AndrewYu>*opens info*
<gnoo>then make inside that
<AndrewYu>guix shell not found
<gnoo>what if you just do 'guix shell coreutils'
<AndrewYu>guix: shell: command not found
<gnoo>foreign distro?
<AndrewYu>Guix System
<AndrewYu>(If it was a foreign distro I'd install libraries with the native package manager)
*AndrewYu checks the 'environment' command
<AndrewYu>seems to half-work
<SeerLite[m]>AndrewYu: Have you run guix pull/when was the last time you pulled?
<SeerLite[m]>If you don't have guix shell it means you're not up to date with guix master
<AndrewYu>hmm, that's probably it
<AndrewYu>what the heck is the guix shell --development magic? :D
<AndrewYu>fatal: no ft2build.h
<AndrewYu>I guess I'll guix install dwm; then do stuff to my own build afterwards
<sam_>well, that's the point, yeah
<sam_>just customise the derivation or whatever
<AndrewYu>Still doesn't fint ft2build.h
<SeerLite[m]>Even with guix install? Then it's probably an issue with the package definition
<AndrewYu>It works with guix install
<AndrewYu>I guess I'll customize the derivation
<AndrewYu>well designed package manager, getting used to it lol
<Gooberpatrol66>jgart: good luck with that importer
<Gooberpatrol66>i have yet to migrate some computers to guix because i need PHP packages
<AndrewYu>In a perfect world you'd avoid PHP
<jgart>Gooberpatrol66, roptat, wrote the php importer already but I haven't added it to that branch yet.
<AndrewYu>And use Lisp and Haskell instead
<AndrewYu>Haven't installed youtube-dl yet
<AndrewYu>currently pulling and upgrading packages
<AndrewYu>yt-dl is really slow nowadays
<AndrewYu>yay, getting weechat 3.4 this update
<AndrewYu>s... how do i install a packkkage for the whole system?
<SeerLite[m]><AndrewYu> "yt-dl is really slow nowadays" <- AFAIK rhe project was kind of abandoned and left a bug that made the download slow. The popular active fork with this bug fixed is yt-dlp (not abbreviated), so check that one out
<Andrew>Oh, thanks :)
<nckx>Does mpv use yt-dlp by default/if it's available, now?
<nckx>Oh, explicitly so even.
<xelxebar>Interesting. It's an explicit input.
<nckx>SeerLite[m]: ‘Bug’ might be a bit of a loaded pro-Google term from the version I heard.
<nckx>More like ‘fails to account for the latest malicious throttling tactic’.
<abrenon>hello guix
<Andrew>Okay, I finally found the problem. I did not reconfigure my system after the first guix pull. I reconfigured before pulling, silly me.
<xelxebar>Hey abrenon. Hope the presentation prep is going well.
<abrenon>oh thank you xelxebar
<abrenon>almost done, I'll be able to fight with the theme then : )
<xelxebar>Nice. Need to get the pesky schoo work done so you can play with Guix! :P
<abrenon>exactly ! :D
<xelxebar>Pretty interested in anything you dig up. I've had strange issues trying to typset stuff from within a 'texlive-union' environment (now called 'texlive-updmap.cfg'?).
<abrenon>ok, I'll be sure to let you know if and when I find something
<xelxebar>BTW, what's your presentation on?
<abrenon>can you read french ?
<abrenon>ok never mind I can't find a link on the conference's website
<abrenon>it's automatic classification applied to encyclopedic articles
<abrenon>we've done a sort of benchmark of existing vectorisation and classification methods
<abrenon>on the Encyclopédie by Diderot and d'Alembert
<xelxebar>Oh, whoa that 18th century beast?
<xelxebar>Unfortunately, I do not read French. Sounds like an interesting testbed, though.
<abrenon>yeah, that beast : ) the Enlightenment, all that… we talk a lot about D&d'A, but actually Chevalier de Jaucourt is also responsible for a lot of the trouble ^^
<abrenon>it's a good testbed because it's available in reasonable quality, and many articles (5/7) have been manually classified by the authors themselves
<abrenon>many entries start with the headword followed by a domain of knowledge between parenthesis, like: LONDRES (Géog. mod.)
<abrenon>french for "London" (modern geography)
<kocio>Hi all, I'm an Ubuntu user for years and I try to play a bit with Guix - I have found nice replacement for gnome-control-center, . Basically I thought that I would just change the source URI and corresponding SHA sum, which would be a few lines in my new SCM
<kocio>file, but it was not enough. How to make it the simple way?
<abrenon>why wasn't it enough ? have you been able to build your own gnome-control-center from that URL ?
<abrenon>(plus, I'm not sure the hash used is SHA, I think what guix hash does is slightly more complex)
<kocio>guix download was enough to get right control sum
<mothacehe>hey guix!
<kocio>I didn't try to compile it on my own, I wanted just to drop changed source for guix buid
<kocio>first I just created small scm file with just the lines which I wanted to change and guix package -m told me about unbound variable
<kocio>and hinted to use (use-packages (guix-packages))
<kocio>and when I added it, it gave me an error about missing field initializers
<kocio>do I have to copy the whole gnome,scm file and edit it?
<kocio>I did it and it still asks me about unbound variable
<abrenon>no copy it, actually there's an inheritance mechanism
<abrenon>but it amounts to redefining the package you're trying to override, yes
<kocio>I try to use that mechanism, because the change is small, but looks like I don't know how to do it
<abrenon>not necessarily the whole gnome, I don't know gnome but I assume there's a package only for gnome-control-center
<kocio>no, it's gnome.scm
<abrenon>hi mothacehe
<abrenon>but gnu/packages/gnome.scm is a guile module that contains many packages
<kocio>yes, so what should I do to chenge only two variables and make my "derivative" I suppose?
<abrenon>if you guix search gnome-control-center, it indeed shows that this package (which isn't the whole of gnome) is defined in gnu/packages/gnome.scm
<abrenon>I reckon you should first learn how to define your own gnome-control-center-custom or something like that
<kocio>where should I learn this?
<abrenon>by inheriting gnome-control-center and changing the source / hash
<abrenon>it's really like defining a new package
<gnoo>what do you want to change exactly?
<kocio>where can I read howto?
<abrenon>and it would work to simply copy and edit the existing definition
<kocio>source URI+SHA sum for this
<abrenon>well guix' manual about defining package should be a good start
<abrenon>especially section 8 Programming interface
<abrenon>it should help you understand the unknown values errors you've been getting
<gnoo>i just copy-paste the define-module sexp and change the name
<kocio>I copied the whole gnome.scm, changed these variables and tried to use guix package-m gnome-whatif,scm, but it asks me about unbound variables
<gnoo>so, copy-paste from line 84 to 229
<gnoo>in a new file
<abrenon>no, really, I insist on that point, there's no need for you to copy the whole of gnome.scm
<gnoo>and then copy only the needed part
<abrenon>gnu/packages/gnome.scm doesn't define the GNOME package, it defines all the packages related to the GNOME ecosystem
<kocio>I made also a file with just the whole gnome-control-center definition and the result was the same
<abrenon>guix edit gnome-control-center takes you directly to the right place
<gnoo>it's better if you ,,paste,, the file
<abrenon>don't worry, I think you just need to read about the (use-modules …) import in the relevant section of the manual
<gnoo>hmm, no fsbot?
<kocio>I found the gnome-control-center definition, now the problem is what should my scm file look like
<abrenon>essentially the block that you copied, plus a couple import statements at the top
<abrenon>gives a good example
<abrenon>hmm actually no, sorry, this syntax would really be to define the package in a module, but if you just want to guix build it
<rekado>xelxebar: what problems do you have with texlive?
<kocio>I added guix-modules and guix-download because it was proposed, but after that it does not propose anything more, so I'm stuck
<abrenon>you'll want to add (in the online example) a single "hello" at the end of the file to "return" the value just defined
<gnoo>kocio: here's how i defined smtube and as you can see the easiest but not so right way is to copy the define-modules sexp:
<abrenon>ohhh that's too bad, the error messages I get are usually pretty useful, so maybe there's something interesting to dig
<gnoo>i think you can get away with using inherit but it'd be nice if you give the url to replace so people can try
<xelxebar>rekado: An old issue:
<xelxebar>Recently tried again, got a different, but similar-looking error, and set aside for now.
<kocio>sure, the url is
<kocio-guix>I made it (uri
<kocio-guix>because simply (uri (string-append did not work
<abrenon>(string-append …) is a function to concatenate strings so it should be useless when you have only one complete string anyway
<kocio-guix>that's why I moved it to just uri
<kocio-guix>kocio@guix ~$ guix package -m gnome-control-center-whatif.scm
<kocio-guix>hint: Did you forget a `use-modules' form?
<kocio-guix>kocio@guix ~$ guix package -m gnome-control-center-whatif.scm
<kocio-guix> /home/kocio/gnome-control-center-whatif.scm:11:19: error: unbound variable
<kocio-guix>hint: Did you forget a `use-modules' form?
<abrenon>kocio-guix: you can use a past service like if you have error messages and snippets you want to share
<nckx>kocio-guix: You forgot "" around the URL.
<kocio-guix>ok, I have to learn the tools, sorry
<nckx>No prob.
<nckx>Guix does not have a special notation for URLs like Nix does.
<nckx>They are simply strings.
<abrenon>the -m option is to build a manifest, those are a specific file format holding a collection of files to install in a profile or something, you probably just want to build the content of your file with -f
<abrenon>hi nckx
<nckx>Hi abrenon!
<nckx>How goes the TeXing.
<gnoo>kocio-guix: can you try this?
<abrenon>kocio-guix: of course you have to learn, there's no shame in that, and the toolset is pretty different from what you may have been exposed to so far
<abrenon>oh dear me everyone is asking about my beamer presentation I must have bored half the channel with my issues ^^'
<abrenon>not that bad, I managed to forget about doing things right and concentrate on the content at the moment, and I'll try guixing things up later if I still have time before the conference
<abrenon>I'm a big yak shaver
<rekado>xelxebar: have you tried the wip-texlive or version-1.4.0 branches?
<kocio-guix> - this is the file gnome-control-center-whatif.scm
<rekado>I fixed font discovery there.
<gnoo>kocio-guix: did you try the above paste?
<gnoo>by above i mean:
<xelxebar>rekado: Oh nice. Will give that a try! Curious what the issue(s) were. Mind giving a pointer to discussion?
<kocio-guix>gnoo: just trying, thanks....
<rekado>xelxebar: I also think that 40558 has been fixed much earlier. The problem, IIRC, was something to do with sort order.
<rekado>xelxebar: the solutions are in commit 2a5ed25c412e162505b2b371d00987fd158a91d4 and following commits
<kocio-guix>gnoo, both -f and -m give me errors
<nckx>abrenon: Focussing on content sounds like the best way forward TBH. Yaks aren't like sheep (…I think?), they won't mind, and they'd only get stuck in rabbit… holes… nope, this is going nowhere.
<gnoo>kocio-guix: guix build -L ~/.cache/guix/my-packages/ gnome-control-center
<xelxebar>rekado: Sweet. Really glad to hear it's sorted. Must have been absolute bundles of fun tracking everything down.
<gnoo>i store that file in ~/.cache/guix/my-packages/gnome-control-center.scm
<kocio-guix>kocio@guix ~$ guix package -f gnome-control-center-whatif-short.scm
<kocio-guix>guix package: error: cannot install non-package object: #<unspecified>
<gnoo>try building it first
<kocio-guix>how to do it?
<gnoo>guix build -L gnome-control-center...scm
<gnoo>guix build -L gnome-control-center...scm gnome-control-center
<gnoo>okay, so -L only takes directory?
<kocio-guix>ok, it starts to do something
*gnoo didn't want to actually build GNOME-things on this old thang so he skipped that part
<kocio-guix>it just gave ma a mesage about that this is not a directory, but dowloads something
<rekado>gnoo: yes, “-L” tells Guix to load additional Guile modules from the given locations; these locations must be directories.
<gnoo>oh, thn kocio-guix try guix build -L . gnome-control-center
<gnoo>Control-C the previous build
<rekado>“-L .” is often a bad idea
<abrenon>or, you can still just add gnome-control-center at the end of the file
<rekado>especially if you’re in a location that contains a clone of the Guix sources
<abrenon>(but you'll have name conflicts when you actually import the (gnu packages gnome) module you'll need
<abrenon>so I'd also suggest renaming the object defined in the (define-public …) to gnome-control-center-whatif
<gnoo>yeah, i just keep them at a separate directory so wasn't a problem before
<rekado>kocio-guix: “cannot install non-package object” means that your file doesn’t end on a package value, but likely a definition, which has a return value of #<unspecified>.
<abrenon>and returning that instead at the end of the file, that way you don't need to -L anything and you can just build
<gnoo>yes, the paste is only the package definition
<rekado>kocio-guix: to change that just end the file with the variable name that you defined above
<gnoo>it's annoying that you have to change the file depending if you want to use guix build or guix install
<rekado>or change the file so that you don’t define at all, i.e. don’t do (define whatever (package …)) and do (package …) instead.
<kocio-guix>guix build -L . gnome-control-center
<kocio-guix>guix build: warning: failed to load '(gnome-control-center-whatif-short)':
<kocio-guix>no code for module (gnome-control-center-whatif-short)
<gnoo>kocio-guix: keep that file in it's own directory to have 'guix build' happy
<gnoo>then use the same name for file
<rekado>gnoo: guix install offers a convenient short-cut with its “-f” switch. “guix build” doesn’t, but that’s no inconsistency.
<gnoo>i.e. gnome-control-center.scm
<rekado>gnoo: you can also end a module file with a plain package value, which doesn’t bother “guix build”.
<gnoo>oh, i didn't knew that. thanks!
*gnoo still hasn't finished sicp let alone guile
<rekado>kocio-guix: Guile modules have a defined name (in the “define-module” clause) and that name must correspond to the module’s file name.
<rekado>SICP wouldn’t have helped you with that :) It’s perfectly fine to learn by falling repeatedly.
<gnoo>just a lot frustrating ;-)
<rekado>kocio-guix: so if you have a file $HERE/my/packages/test.scm, where $HERE is the location you add to “-L” or GUIX_PACKAGE_PATH, then the module name must be (my packages test).
<rekado>to me frustration due to learning is preferable to frustration due to restriction
<rekado>but I guess you can’t avoid frustration when using computers one way or another
<gnoo>true that :^)
<kocio-guix>frustrating, I can't remove package it dowloaded lately:
<kocio-guix>kocio@guix ~$ guix remove gnome-control-center
<kocio-guix>guix remove: error: package 'gnome-control-center' not found in profile
<gnoo>well, it's not installed?
<kocio-guix>now I have gnome-control-center.scm ina directory gnome-control-center
<gnoo>so, you have ~/gnome-control-center/gnome-control-center.scm ?
<kocio-guix>kocio@guix ~/gnome-control-center$ guix build -L . gnome-control-center
<kocio-guix>guix build: warning: failed to load '(gnome-control-center)':
<kocio-guix>no code for module (gnome-control-center)
<kocio-guix>hint: File `./gnome-control-center.scm' should probably start with:
<kocio-guix>     (define-module (gnome-control-center))
<kocio-guix> /gnu/store/nijfaihbzl5rxc985d3cbwyizccqclal-gnome-control-center-40.1
<gnoo>it looks like what i pasted and what you have are different
<kocio-guix>I pasted your code, but it dowloaded package along others in one of the previous -L steps
<gnoo>you stopped those with Control-C ?
<kocio-guix>it stopped before I tried that
<gnoo>then it should be fine
<kocio-guix>downloading was fast
<gnoo>hmm, it's downloading dependencies for me so it should build fine
<kocio-guix>I'd like to remove the downloaded package first
<gnoo>guix gc
<gnoo>also since it turns out you don't actually need the (define-public, you can just remove that
<gnoo>i.e. remove '(define-public' and then the last ')' of the file
<gnoo>oof cleaned 1GB!
<abrenon>also, I don't think you really want to "remove" downloaded packages
<abrenon>that doesn't really make sense in the context of guix
<kocio-guix>ok, removed define-public part, but it did the download agan. now if I try that again I get:
<kocio-guix>kocio@guix ~/gnome-control-center$ guix build -L . gnome-control-center
<kocio-guix>guix build: warning: failed to load '(gnome-control-center)':
<kocio-guix>no code for module (gnome-control-center)
<kocio-guix>hint: File `./gnome-control-center.scm' should probably start with:
<kocio-guix>     (define-module (gnome-control-center))
<kocio-guix> /gnu/store/nijfaihbzl5rxc985d3cbwyizccqclal-gnome-control-center-40.1
<kocio-guix>that's after guix gc
<gnoo>does it just stop or are you C-c'ing it
<abrenon>while you're building and playing and everything, nothing gets installed
<gnoo>it emits those warnings but you can just ignore them
<abrenon>it does land in your /gnu/store, but that's not something to be concerned with, and it won't interfere with your future attempts at building the package
<gnoo>it's concerning if you have a small / like i do but for that you can 'guix gc' for the most part
<gnoo>and then remove old versions of profiles which i haven't done yet
<kocio-guix>ok, I see, still it ignored my file and tries to download the binary
<gnoo>it's probably downloading the dependencies to build it
<kocio-guix>no, it downloads everything and stops
<gnoo>if it stops then that's good
<gnoo>did you remove the '(define-publice' and the last ')' ?
<kocio-guix>I did it
<gnoo>then guix package -f ~/gnome-control-center/gnome-control-center.scm
<gnoo>you didn't need to build it before installing as it will build if it's not built yet but i like to do those steps explicitely
<kocio-guix>kocio@guix ~$ guix package -f ~/gnome-control-center/gnome-control-center.scm
<kocio-guix>The following package will be installed:
<kocio-guix>   gnome-control-center 40.1
<kocio-guix>substitute: updating substitutes from ''... 100.0%
<kocio-guix>The following derivations will be built:
<kocio-guix>   /gnu/store/pk4a5w2ldf8fidz0z2fm9gihamk9jhhj-profile.drv
<kocio-guix>   /gnu/store/sxg9xyk4bg7205nxss4mkr9044dp1g2b-gnome-control-center-40.1.drv
<kocio-guix>   /gnu/store/8llbrrfknf3xh00p47y87zsq142h1yir-gnome-control-center_40.0-1ubuntu10.tar.xz.drv
<civodul>Hello Guix!
<efraim>hello civodul!
<abrenon>kocio-guix: yes, not guix package, guix build, you don't wanna install something when you're not even sure you have properly packaged it
<gnoo>kocio-guix: please use a pastebin like
<abrenon>hi civodul
<gnoo>and if that command ran successfully then you should have gnome-control-center in your PATH
<kocio-guix>OK, so the file now is
<gnoo>did it not install?
<kocio-guix>i try guix build -f ~/gnome-control-center/gnome-control-center.scm
<gnoo>and, the full output was...?
<gnoo>(in a pastebin)
<kocio-guix>still going
<gnoo>then that's good
*gnoo gets some tea
<kocio-guix>you deserve it :)
<kocio-guix>I thought extending the existing package would be simpler...
<kocio>I already have gnome-control-center as part of my installation
<rekado>note that this does not change the existing package at all
<kocio>Yes, i know about multiple versions possible in Guix
<kocio>however this is quite hard for the newbir to know what is exactly going on
<rekado>what *is* going on that is hard to understand?
<kocio>which version is building now (my or original one)
<kocio>and which one will be in PATH after the build
<alMalsamo>Hmm why is Guix doing an online conference in February instead of having a presence at FOSDEM?
<jpoiret>alMalsamo: there are multiple conferences on Guix or Guix-adjacent at FOSDEM
<mothacehe>jpoiret: i'm testing your installer patchset, works really well :)
<jpoiret>Guix days is more meant as a gathering for the community to think and reflect about Guix (and also hack :) )
<jpoiret>mothacehe: Great! I have to admit it took me longer than I would've liked
<jpoiret>if you want to test failing commands, i recommend "while true; do killall cryptsetup; sleep 1; done" in the background :)
<jpoiret>do you think we should squash the dump-related commits before merging?
<kocio-guix>Now it built /gnu/store/rhlzlgka41k8iq1r61wjgkhb1pfkn57k-gnome-control-center-40.1 and gnome-control-center in my PATH looks the same as before
<jpoiret>`guix build` only builds a package, nothing more
<jpoiret>it doesn't install it to any profile, doesn't add anything to pack
<jpoiret>path *
<kocio>ok, so how to install it and use?
<jpoiret>`guix package -i` or its shorthand `guix install`
<kocio-guix>I did it and the app looks like before
<mothacehe>jpoiret: i'm using "mkfs.ext44" to cause an installer error. No I think we can proceed without squashing. I changed a few minor things, so I'll a diff before pushing.
<kocio-guix>I'm not sure if it built fromnew source or not
<jpoiret>haha, good old adding a bug to the installer. I was worried one of them was going to slip into a commit
<jpoiret>kocio-guix: guix is a source-based distribution, (it builds everything from source), but you can use substitutes which downloads the output without locally building
<jpoiret>most likely you downloaded a substitute
<jpoiret>how are you launching the app?
<jpoiret>are you on guix system or on a foreign distro?
<kocio-guix>my build proces went like this:
<kocio-guix>I build on guix, but chat also from host as kocio
<jpoiret>that pastebin was removed apparently
<kocio-guix>jpoiret kocio@guix ~$ gnome-control-center
<jpoiret>can you use
<kocio-guix>too big for Debian
<jpoiret>as long as it built it should be okay
<kocio-guix>Length of code is not allowed to exceed 150kB
<jpoiret>what does "readlink -f $(which gnome-control-center)" output? is it equal to the `guix build -f ` output?
<gnoo>did it end with 'building profile with N packages' ?
<gnoo>if so then it should be installed
<jpoiret>(not equal but is the store directory the same)
<kocio-guix>copying from that chat is somewhat hard...
<kocio-guix>it ended with line:
<kocio-guix> /gnu/store/rhlzlgka41k8iq1r61wjgkhb1pfkn57k-gnome-control-center-40.1
<gnoo>just to be sure, you did do guix package -f, right?
<kocio-guix>and it started like this:
<kocio-guix>kocio@guix ~$ guix build -f ~/gnome-control-center/gnome-control-center.scm
<kocio-guix>The following derivation will be built:
<kocio-guix>   /gnu/store/sxg9xyk4bg7205nxss4mkr9044dp1g2b-gnome-control-center-40.1.drv
<kocio-guix>building /gnu/store/sxg9xyk4bg7205nxss4mkr9044dp1g2b-gnome-control-center-40.1.drv...
<gnoo>building will only build
<gnoo>you need to install it
<gnoo>with guix install -f
<gnoo>guix package -f
<kocio-guix>then I installed it
<gnoo>guix package -f ~/gnome-control-center/gnome-control-center.scm
<kocio-guix>ok, let's try that
<gnoo>use 'guix package -f ~/gnome-control-center/gnome-control-center.scm' to install
<kocio-guix>I did it and it looks the same as before
<kocio-guix>so maybe it did build with original source
<gnoo>well maybe that's not the package that changes the appearance then. does gnome-control-center have an 'about' section that shows the version?
<gnoo>the version will probably be 40.0 if it builded from source
<gnoo>hmm, shouldn't it be 40.1 or 40.0 ?
<jpoiret>does `readlink -f $(which gnome-control-center)` give you something under the directory given by `guix build -f ./yourpackage.scm`?
<kocio>I'm confused
<gnoo>oh, it's 'gnome-control-center --version'
<kocio-guix>gnome-control-center 3.34.2
<efraim>how can I refer to gcc-final:lib from somewhere else?
<rekado>kocio-guix: when you built the package it ends up in /gnu/store.
<rekado>your current gnome-control-center is also somewhere in /gnu/store
<rekado>which exactly is used depends on who’s calling it
<rekado>you can, of course, manually invoke anything by using its absolute file name.
<rekado>on your Guix System (if that’s what you use), gnome-control-center is installed as part of the gnome service
<rekado>so if you want to change that you’ll need to tell the gnome service about it
<rekado>by design none of this is mutable
<rekado>so adding a new package is not going to change anything about your system or your system services
<xelxebar>rekado: Man, I'm getting all kinds of errors trying to build texlive-bin from the current tip of wip-texlive.
<xelxebar>Looks like the build errors are different each time (because of the -j8 flag?).
<xelxebar>Are build failures expected on this branch?
<kocio-guix>kocio@guix ~$ /gnu/store/rhlzlgka41k8iq1r61wjgkhb1pfkn57k-gnome-control-center-40.1/bin/gnome-control-center --version
<kocio-guix>(process:10119): Gtk-CRITICAL **: 11:34:38.199: gtk_style_context_add_provider_for_screen: assertion 'GDK_IS_SCREEN (screen)' failed
<kocio-guix>gnome-control-center 40.0
<kocio-guix>now it looks like new version!
<abrenon>of course, because it's not the same binary
<kocio-guix>thanks for all the help
<abrenon>guix is about building stuff and allowing you to link to it a reproducible way
<kocio-guix>I know the theory and I like it a lot, the problem was doing something in practice
<abrenon>I hope you had fun and get a clearer view of how it all works, and why you need what you do
<abrenon>always a big gap, yeah : )
<gnoo>kocio-guix: should use (version "40.0") so the path says 40.0
<gnoo>inside (package)
<kocio-guix>Yes, a birt of frustration, a lot of fun of doing something new after years of using Linux and a lot of gratitude for you to help me get through this bizzare idea, which might fail early at the compile tinme
<florhizome[m]>hm what’s up with the kde substitutes? basically rebuilding the whole plasma frameworks rn –.–
<abrenon>: )
<xelxebar>kocio-guix: Yeah! Guix feels a bit disorienting at first, especially if you have lots of prior Linux "bias", but once you get the hang of things, it's pretty darn slick. Hope you're having fun :D
<rekado>xelxebar: no, there should be no build failures.
<rekado>I suggest sticking with version-1.4.0, though, because that’s more up-to-date and actually will have substitutes
<xelxebar>Is most of the wip-texlive stuff on that branch?
<rekado>all of it
<rekado>but tell me: what build errors did you get?
<xelxebar>Various ones that I failed to note. Here's one I did: /tmp/guix-build-texlive-bin-20210325.drv-0/cczVMHh9.s:156452: Error: unbalanced parenthesis in operand 1.
<rekado>is that all the output?
<xelxebar>Oh, not at all. It's always some random error burried within the copious gcc output. Actually even segfaulted once, so might be a local machine problem.
<xelxebar>The above error output was just that one line though, yeah.
<xelxebar>Since it's so non-deterministic, I'll might play around with it later, to try and suss out some reasonable information.
<kocio>xelxebar Yes, it's fun, to be a newbie again :)
<gnoo>when using (local-file './file-name') on /etc/config.scm is it relative to /etc ?
<xelxebar>rekado: Okay, tried building metamath on top of version-1.4.0, but getting a font-related error: ! Font TS1/cmtt/m/n/10=tctt1000 at 10.0pt not loadable: Metric (TFM) file not found.
<xelxebar>FWIW, here's the patch, which 4 ctan packages along with the metamath update:
<xelxebar>(Rather, building the metamath *pdf* is erroring out.)
<rekado>that font ought to be provided by the “ec” package.
<rekado>can you add texlive-fonts-ec to your environment?
<rekado>xelxebar: a non-deterministic segfault that I haven’t encountered in any of my builds of texlive-bin sounds like it might be a problem on your end, though I can’t guess as to what might be the cause.
<jgart>I sent a patch for sxmo-st from
<jgart>Sxmo is a minimalist environment for Linux mobile devices, such as the pinephone.
<jgart>I can send the others in the sxmo distro if upstream wants them. They are almost all packaged
<xelxebar>rekado: Ah! That's painfully simple. Rebuild encounters a similar for a different font I guess. Could you give me a pointer or reading material for how to make these errors to the appropriate font/package/ctan name?
<xelxebar>s/make these errors/map these errors/
<xelxebar>In particular, I'm seeing this now: ! Font U/euf/m/n/10=eufm10 at 10.0pt not loadable: Metric (TFM) file not found.
<mothacehe>jpoiret: the installer tests failed because they couldn't umount the cow-store
<xelxebar>After a bit of fumbling around with searches, I'm guessing Euler Fraktur?
<mothacehe>i guess some overlay file is kept open, i'll try to find which one.s
<xelxebar>euler fonts should be in texlive-amsfonts, I am guessing, but that's already included in the union. Hrm...
<xelxebar>Yeah, blinding adding every font package I could find didn't seem to have an effect.
<rekado>the amsfonts package should have that tfm file
<rekado>I always look things up in the texlive.tlpdb file, which is included in texlive-bin
<rekado>xelxebar: I also suggest using “guix shell -C” to be sure that your environment isn’t breaking things.
<attila_lendvai>adding guile-srfi-189:
<jpoiret>mothacehe: ah, great work on the newt UI :)
<mothacehe>thanks :) The installer tests are failing because they try to build stuff (such as linux-libre): They shouldn't build anything as we make sure that a closure of what's needed at install time is part of the installation image.
<mothacehe>i'm bisecting the patchset because i can't see what could cause the regression.
<jpoiret>by the way, I got rid of of the (dynamic-wind (const #f) ... (lambda () (destroy-form-and-pop form)) in the run-textbox-page because it's clearer that way
<teddd>Is it possible to automatically solve collisions by choosing the latest version of a package ?
<teddd>is this what "--allow-collisions" does ?
<civodul>hey mothacehe & samplet :-)
<civodul>teddd: --allow-collisions means that, if two packages in the profile "collide", then guix will keep going
<civodul>hey zimoun
<civodul>teddd: "collide" means: two packages with a different version or different build options, etc.
<civodul>--allow-collisions is risky in that you don't know what you're going to get
<civodul>it does not resolve the collision, just ignores it
<zimoun>samplet: cool for the last PoG report. :-)
<samplet>zimoun: Thanks! It’s not the most exciting one... but I figure it’s good to keep reporting.
<samplet>BTW, I used the new ‘guix hash -S git ...’ stuff, and it was pretty handy.
<zimoun>Cool! I would also add ’-S swh’ :-) I have not found the time to dive in Disarchive.
<mothacehe>hey civodul!
<mothacehe>jpoiret: the test failure is located between 76c27a5792 and 917e94b29f
<mothacehe>i suspect 946420276f
<jpoiret>oh, i was just about to ask you updates on that (my laptop isn't fast enough to bisect system tests i'm afraid
<mothacehe>yeah they are not offloaded sadly so my laptop is also giving everything it has
<mothacehe>building guix which is the expensive part in running those tests
***zimoun` is now known as zimoun
<jpoiret>so, the `guix init` should come from the guix package of installer.scm#338
<jpoiret>whereas before it was coming from /run/current-system/profile/bin/guix i think
<jpoiret>that might be the difference
<mothacehe>mmmh true, those two guix would be guix and guix_n-1?
<jpoiret>hmmm, no, since the guix package is from the build side
<jpoiret>but rather, since system tests use the checkout, maybe there was an update to linux-libre between the guix package's commit and the current one
<jpoiret>yeah, looks like it is the case
<j`ey>is everything from in a single .scm file?
<jpoiret>mothacehe: i'm not sure how the "use guix from checkout part works or where it's applicable", but I think that the system profile installed one is the checkout guix, and the one used by the installer is the packaged guix, so the newer linux-libre is in the closure but the installer tries to install the older one
<apteryx>civodul: were you OK with merging the version-1.4.0 back into master?
<mothacehe>jpoiret: yeah that's definitely something like that. I have a train to catch but let's talk about it again later on!
<jpoiret>i'll look into it in the meantime :)
<mothacehe>the tests are introducing a "current-guix" package btw
<apteryx>it has 49% coverage vs 51% for master right now, but it seems there are 23609 pending builds that are not going to happen (mostly ARM) (not sure why)
<mothacehe>see ya!
<jpoiret>see ya
<civodul>apteryx: yup, merging's fine with me
<civodul>i want the texlive fixes and all that :-)
<apteryx>alright, doing it
<civodul>thank you!
<civodul>so you were right and i was overly pessimistic regarding our ability to provide binaries quickly enough!
<apteryx>the age old risk/reward tradeoff. worked in our favor this time around.
<civodul>yup, well done
<kraai>Icedove seems to forget my account information each time it's upgraded. Is there a way to prevent this?
<zimoun>mothacehe, apteryx: about version-1.4.0, ocaml-boot is failing because a timeout. «building of `/gnu/store/pvicydjwzn66zy2cswcz62xiqdcj35qa-camlboot-0.0.0-1.45045d0.drv' timed out after 3600 seconds of silence»
<jonsger>kraai: I'm not aware of one, but happy to review patches which fixes the issue
<jonsger>start icedove with --ProfileManager and delete all other profiles apart from the one you are using
<zimoun>apteryx: do we restart because it should pass?
<jpoiret>kraai: might interest you
<jonsger>ah, no one CCed me this interesting bug :(
***kraai_ is now known as kraai
<zimoun>apteryx: why so much red? :-) For instance, I remember fixing many ghc-* for i686 in core-updates-frozen. What changed since then?
<kraai>jonsger: Thanks for the link.
<jonsger>the link was provided by jpoiret :)
<zimoun>the root is the issue is «ar-1.34/bin/tar: /gnu/store/n1kzba52c58jpm7pivhrl4a36b55xh4q-gcc-10.3.0.tar.xz: Wrote only 2048 of 10240 bytes»
<zimoun>Not enough space?
<kraai>Oops, sorry, thanks jpoiret.
<jpoiret>aha don't worry about it
<apteryx>zimoun: gfortran; indeed it seems to be the culprit, and the error suggests a transcient failure due to space exhaustion perhaps!
<apteryx>I've retriggered the build
<zimoun>cool, thanks!
<apteryx>zimoun: if you give me the link of ocaml-boot I can restart it too!
<psyklax>Hello there
<zimoun>apteryx: I did. :-)
<psyklax>I've got a fresh install, with MATE desktop, and policykit is asking for a password every time I try to adjust the brightness with the hotkey. Trying to figure out why that is, doing a websearch but also assuming someone just knows off the top of their head.
<dongcarl>Looks like mingw-w64-{x86_64,i686}-winpthreads packages are failing... Will investigate soon
<jpoiret>i can't find the thread about the Guix package having to be updated twice (from this week or a week ago), anyone have the message ID?
<jpoiret>i think civodul was thinking about using current-guix to make the installer image
<psyklax>It's got to just be a line in a config file somewhere..
<apteryx>zimoun: ah, sorry I had missed it (I see it now)
<jpoiret>psyklax: do you login through GDM?
<jpoiret>looking briefly at the mate-power-manager package, polkit should let you adjust the brightness if you're in an active session
<jpoiret>what does `loginctl list-session` tell you?
<jpoiret>list-sessions *
<jpoiret>uhhh, maybe `loginctl session-status` would be more descriptive
<psyklax>it's showing gdm
<psyklax>So the behavior I'm getting isn't normal.. ok
<ennoausberlin>Hi. Short question. I am on mobile. Is it possible to install guix on another partition from an existing guix installation or do I need an install iso
<apteryx>zimoun: hmm, ocaml-base had a test failure:
<jpoiret>psyklax: maybe someone else has this same problem, I was just looking at the polkit config of that package. I don't use MATE myself
<psyklax>What's the guix way to edit config files in /etc/ ? Apparently it's got no write permissions even for root.
<ennoausberlin>I want to duplicate my working guix (sd card) on nvme
<jpoiret>you shouldn't edit them, all configuration should be done through your config.scm
<ennoausberlin>with slightly adjusted config.scm
<jpoiret>ennoausberlin: you can completely install guix on another partition with your current guix install
<jpoiret>i myself installed guix through a foreign distro guix
<ennoausberlin>jpoiret: So. If I do all steps of manual install it will work?
<jpoiret>it should, just remember not to format the partitions you don't want to format :)
<ennoausberlin>jpoiret: Do I have to start the cow-store?
<johnhamelink>Hey there :) I'm currently an Arch user who's looking to migrate to GNU Guix! My plan is to start by moving all my Emacs & its dependencies and peripheral applications (Emacs packages, mu, isync/mbsync, vdirsyncer, etc) inside a guix foreign install, and then work my way from there. I was using setup.el + straight, so after installing the emacs packages with guix install, and then removing the
<johnhamelink>straight references so that setup.el is just configuring and not managing packages, my Emacs boots up without any configuration issues! However, the default cursor theme for Emacs is very dark. How can I have Emacs inherit the cursor theme that non-guix apps use? And how would I fix this problem in a 100% guix install down the line?
<ennoausberlin>jpoiret: the partitions are labelled and I use labels in config.scm. Should be fine. Thank you. I will just run guix install then
<teddd>civodul: ok thanks for the answer! So what would be the best way to go ? For example I have some conflicts between numpy versions in a profile of mine. Can't I just tell guix to choose the latest by default ?
<zimoun>apteryx: about the ocaml failure you pointed, it is because ’ld’, which raises a warning.
<zimoun>«was expected to be empty […] but it is not:»
<zimoun>the file contains: «ld: question.o: warning: relocation against `camlQuestion' in read-only section `.tex»
<Andrew>Ah, finnally got Guix System working for me
<zimoun>apteryx: What changed in ’ld’ to now raise a warning?
<apteryx>binutils-next was absorbed by binutils on the version-1.4.0 branch
<Andrew>As a newbie, I went through the graphical installer, got the config file, saved it, and performed a manual install with --subsitute-urls
<psyklax>Hm... I can't just start adding text into config.scm without knowing what I'm doing. I just want to add some config for polkit.
<jpoiret>Andrew: that's a good workflow in case you need to change something to the final guix system init invocation
<jpoiret>maybe we could add this in the graphical installer
<zimoun>apteryx: ah ok, version-1.4 is an half core-updates. :-)
<zimoun>apteryx: about trytond, for instance python-simpleeval fails because «error in simpleeval setup command: use_2to3 is invalid.»
<apteryx>that's due to going to Python 3.9.9, whose bundled setuptools removed that option
<apteryx>it means the sources are still in Python 2 format...
<apteryx>you could call the 2to3 python script in a phase
<apteryx>or a source snippet
<civodul>teddd: i'm aware of the issue with numpy (two different versions are currently packaged), but i'm not sure what the recommendation is
<civodul>you should maybe bring it up on if nobody else here knows
<zimoun>apteryx: thanks! Do you know if other python packages are affected?
<apteryx>I haven't stumbled on some that'd prevent me from reconfiguring my system or profile, no
<zimoun>civodul, teddd: now, the collision with Numpy should be solved. teddd: could you say which packages collide?
<teddd>civodul: yes just a sec
<zimoun>apteryx: when do you plan to merge version-1.4.0 and master? For x86_64, it would be ok but people using i686 would have a degraded experience.
<teddd>The conflict emerges whenever I have on one side python-numpy which propagates numpy@1.21 and on the other side any of scipy, ipython, jupyter, matplotlib
<teddd>the latter propagated version 1.20.3
<zimoun>teddd: what is your revision of Guix?
<teddd>where can I check that ?
<zimoun>guix describe and then the commit hash :-)
<teddd>here is the first line of guix --version : d627fbad8f4e157103251b07d7543dd2f5647cea
<psyklax>Hm... I'm trying to get my answer from the docs, but I keep getting sidetracked with things that are not currently relevant to me.
<teddd>zimoun: ah ok. It's the same
<psyklax>I see "Invoking guix edit" and I think "That looks like a way to "edit" config files" So I go read that section. No, that's not what it does, and on to the next.
<teddd>zimoun: is it too old ?
<zimoun>teddd: yes, you are using a revision from Dec. 17th and the bug (collision) is fixed on Dec. 31srt. :-)
<zimoun>just run “guix pull” and then all will be fine.
<teddd>ah that sounds nice :) thanks !
<apteryx>is closing a bug by appending "-donenotabug" to the bug # a thing in Debbugs?
<jpoiret>psyklax: what exactly do you want to edit?
<jpoiret>on guix system, every single service is defined in your config.scm file
<jpoiret>along with their configuration
<psyklax>I want to make polkit passwordless
<teddd>I get an error when running guix pull : something goes wrong when building guix-package-cache.drv
<teddd>(exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (lttng-ust)) (value #f))
<psyklax>I just want to do that...
<dongcarl>mingw-w64 problems seem to arise from the new configure flags added by binutils-next (now merged into binutils)
<dongcarl>Anyone know where I can look up the rationale for these flags?
<civodul>hi dongcarl! apteryx, what's the rationale for these flags?
<civodul>it'd be great to have comments like for the other binutils flags
*dongcarl waves
<apteryx>dongcarl: hello! The flags were originally added to binutils-next, which was used to workaround an issue where enable-64-bit-bfd was not enabled
<psyklax>Mk... I'm done trying this.
<gnoo>hello, how can i reload a module's definition in shepherd ?
<apteryx>dongcarl: the other flags were added after inspecting what Fedora uses in their binutils RPM package description (
<apteryx>"--enable-compressed-debug-sections=all" reduces the size (via compression) of the debug symbols
<dongcarl>apteryx: I see, I'm seeing that mingw-w64-x86_64-winpthreads fails to build with these new flags, so trying to determine best course of action
<dongcarl>If I were to guess, --enable-threads is the culplrit?
<rekado>FYI build node 119 had in fact a bad CPU; it’s now fixed and once we’ve updated all firmware I’m going to install/update Guix System.
<gnoo>ok, i figured that one out, it was herd stop module and herd load root ~/.config/shepherd/file.scm
<apteryx>rekado: wow! Bad CPU. Thanks for handling it.
<rekado>all praise goes to Madalin; he arranged for the service tech to swap every part until they had to accept that the CPU was dead.
<apteryx>--enable-threads is useful to at least binutils-gold (
<rekado>next up is flaky node 130 with weird disk problems
<apteryx>rekado: my thanks go to Madalin as well then :-)
<teddd>ok my problem was fixed when updating all my channels.
<gnoo>can i depend on the 'networking' module defined by root shepherd to use on my user shepherd? or some way around it?
<dongcarl>apteryx: I think perhaps for flags which only make sense for certain architectures/kernels, perhaps we should guard them with a check?
<apteryx>from what I gather they are not architectures/kernel specific?
<apteryx>zimoun: python-simpleeval could be fixed by a minor update from 0.9.10 to 0.9.12 :-)
<apteryx>version-1.4.0 has now been merged into master
<apteryx>hopefully we don't catch other world rebuilding changes in our testing
<zimoun>apteryx: cool! :-)
<hasjplante03[m]>hello, does anyone know how i can append a line of text to a file in a package declaration?
<hasjplante03[m]>either in a snippet or in the patch phase
<apteryx>hasjplante03[m]: you'll want to open the file port in append mode, such as with "(open-file some-file "a"); then you could use call-with-port on it
<apteryx>refer to 'info guile' for the a reference to the APIs
<podiki[m]>apteryx: woo! nice work!
<apteryx>podiki[m]: hey! thank you!
<hasjplante03[m]>apteryx thanks, i always forget to RTFM. there's a good example at 6.12.1
<hasjplante03[m]>hmm ok, but im getting permission denied on the file im trying to modify
<apteryx>hasjplante03[m]: perhaps you need make-file-writable
<hasjplante03[m]>apteryx thanks, that worked
<lfam>Something changed the librsvg derivation on 'master'
<lfam>I just built the substitute for it on berlin, but it seems like a mistake/
<lilyp>rust being rust again
<lfam>apteryx: Did you mean to merge the 1.4.0 branch to master without building substitutes for it yet?
<apteryx>that wasn't meant, no. The version-1.4.0 was fully built prior to the merge; perhaps a resolved conflict invalidated part of the graph?
<apteryx>(fully built for x86_64, that is)
<lfam>Yeah, must be
<lfam>For what I'm doing, at least none of Rust is built
<lfam>So, that will take some time
<apteryx>that's bad
<lfam>Actually, I think I'm mistaken
<lfam>Maybe the substitutes just weren't baked yet
<lfam>Yes, I think that the compilers are built, but the substitutes weren't built
<lfam>I mean, the substitutes weren't baked
<lfam>Okay, so false alarm, more or less
<lfam>Sorry about that
*apteryx keeps struggling with "substitute: Wrong type (expecting exact integer): #f" from their personal substitute server
<apteryx>berlin seems immune to it at least
<mbakke>apteryx: the merge resolution for 'python-platformdirs' seems wrong to me, none of the new arguments or inputs from 1.4.0 are needed
<apteryx>I admit I was rather confused by the diff of that conflict, so that's likely :-)
<mbakke>similarly for 'python-os-testr' (sorry!) :-)
<mbakke>I'm surprised by the number of build fixes from that branch, such things should reach users and co-developers ASAP IMO :)
<avp>Hello everybody. I updated my patch that adds libtree:
<lfam>What's the "canonical" installer system test?
<lfam>Like, if you can only run one of them, which should you run?
<unmatched-paren>hello, guix; the epiphany package's hash is wrong, is this known?
<unmatched-paren>expected hash: 0r7m34xzz3shdfxf2abxb069izak3yv3ijlg29qy4pfmyawkilfs
<unmatched-paren>actual hash: 0k7b22zq3z1kllzqxgwsvwb1lp0j6rjb3k1hvhna3i573wc4mpji
<lfam>Indeed, I can reproduce this on current master
<unmatched-paren>thanks, should i send a patch?
<lfam>We need to understand what's happened
<lfam>Otherwise, there would be no reason to name sources by hash
<unmatched-paren>right, ok
<lfam>I guess it's part of the version-1.4.0 merge, apteryx? That the Epiphany hash doesn't match upstream?
<lfam>Do you have this tarball still?
<unmatched-paren>the old epiphany's tarball?
<lfam>Yes, I'm asking apteryx
<lfam>He is the one that updated epiphany to this new version / hash
<lfam>It would also be nice to be able to search the Guix codebase for these hashes but allowing for a single-character difference
<lfam>Because, changing a single character in the hash is probably part of a typical workflow
<lfam>Anyways, we have to try to figure out: Did we use the wrong hash? Or did something happen upstream?
<apteryx>lfam: re canonical system test; TESTS=basic?
<lfam>Yeah, basic!
<lfam>I'm downloading all the Epiphany tarballs from the 40 through 42 series and will compare their hashes
<lfam>This is the hash of epiphany-40.3.tar.xz
<lfam>So, it's a familiar mistake when trying different versions of the package
<lfam>I'll push the fix with explanation now
<lfam>Oh, I see!
<lfam>It's a merge resolution mistake
<lfam>We already had 40.3
<unmatched-paren>lfam: thank you! :D
<lfam>For me, doing big Git merges requires some of the highest levels of concentration of any task I do. It's on the same level as my day job which is live video work
<lfam>Dealing with the merge resolutions correctly requires extreme attention to detail and contextual understanding
<apteryx>I thought epiphany was at 41 on version-1.4.0 no?
<attila_lendvai>is anyone using qbittorrent on Guix? it cannot connect to peers post c-u-f merge for me:
<unmatched-paren>apteryx: yeah, it is
<lfam>I think the merge resolution seleceted the wrong hash apteryx
<apteryx>without a conflict?
<lfam>I pushed the fix
<lfam>I don't know if there was a conflict :)
<apteryx>the ones there was (that I resolved badly to some extent at least -- thanks to marius for pointing out) are visible in the merge commit
<lfam>Merges are very tricky, both during and after. It's not trivial to make Git show the changes. It's actually the ideal way to sneak changes into the codebase
<lfam>In any case, your update of Epiphany was correct, but then somehow the update of the hash was reverted
<lfam>Probably because of this commit: f7afefba00b65e94d073af3af2278a076c89dbc1
<apteryx>if you do "git show 276f40fdc3" you can see the changes slipped in as part of the merge (resolving conflicts)
<lfam>Yes, I'm familiar with that view
<unmatched-paren>are there any technical barriers a `guix import melpa` for importing emacs plugins from MELPA? seems like more packages are on there than GNU/nonGNU ELPA. i'd like to give it a go, but i want to know if it's been tried before
<unmatched-paren>s/barriers a/barriers to a
<lfam>But try `git log -p gnu/packages/gnome.scm`, apteryx. You'll observe that Git never shows this hash being reverted
<lfam>However, it was
<lfam>It's a scary area of Git
<lfam>And a reason that I am a proponent of a rebasing workflow whenever convenient
<lfam>When I do long-running branches, I always try to avoid using merges. It's not always possible of course
<lfam>I think there might be a way to make Git show this type of change, but it's not shown by default
<lfam>Over the years we have had many similar issues after big merges
<apteryx>perhaps --full-history
<lfam>A big one is that deleted patch files re-appear in the tree
<lfam>No, full-history doesn't do it
<lfam>If it's possible, it's quite obscure
<lfam>Periodically, I check the tree for orphan patches. It's a good time to do it now
<bricewge>Hello Guix!
<apteryx>lfam: hmm, tricky!
<lfam>Yes, very!
<lfam>So remember my advice: for small-ish long-running branches, try rebasing if it's at all convenient
<bricewge>I sent email several times to populate the patchset but none arrive
<lfam>With our guidelines about package rebuilding on master, it's not always possible or convenient
<bricewge>Are they blocked in moderation?
*lfam looks
<cbaines>It's really ironic that a main use of is building things for long running branches
<cbaines>you don't have long running branches if you're doing CI (continuous integration)
<lfam>It's true, our use of it is still rather primitive cbaines
<cbaines>it's not how it's used, more how it's named
<lfam>bricewge: No, they are not being held for moderatoin
<lfam>Can you expand on what you mean cbaines?
<lfam>bricewge: I have to assume the mail server is simly rejecting your emails
<cbaines>lfam, just that continuous integration refers to merging frequently in to master
<bricewge>lfam: Thanks. That's odd
<lfam>Does that paradigm make sense for a distro, cbaines, in your opinion?
<cbaines>lfam, CI is more of a corporate perspective, useful in a work environment, but I think it's definately valuable to try to make small intentional changes, test them individually, and merge them frequently
<cbaines>as opposed to having changes being made in non-master branches, then merged together less frequently
<lfam>Right, and I think that would definitely work well in Guix for the leafier ends of the package graph (I've even advocated for it)
<lfam>I'm more curious about changing the core of the graph. Our workflow is basically determined by a build farm that doesn't exist anymore (the old Hydra build farm)
<lfam>After the upcoming release, I'm planning to start a discussion about the workflow
<lfam>But the discussion could end by reinforcing the status quo. Maybe it's good enough, after all. We will see
<unmatched-paren>what were the biggest changes with the merge, btw?
<lfam>bricewge: I don't know how to check if your emails are being filtered
<lfam>bricewge: I recommend trying to send your patches in a different way. Like, if you are using `git send-email`, instead send them as attachments. Etc
<lfam>Sorry it's not better
<bricewge>No worry, I'Il try sending them as attachement.
<ytc>how can i know which packages' substitutues are missing before i invoke `guix upgrade'?
<drakonis>ah it is all fixed now.
<ytc>`guix weather' checks all package derivations. i just want to check what's i installed.
<bricewge>lfam: It worked, thanks for the tip!
<lilyp>unmatched-paren: the biggest issue regarding melpa is its versioning
<lilyp>it breaks package.el too, not just guix
<lfam>bricewge: Huh, it would be great to figure out what was wrong before
<lfam>ytc: You can export your profile (aka installed packages) as a manifest, and then pass the manifest to `guix weather`
<unmatched-paren>lilyp: you mean things like 20170309.509?
<lilyp>i think enabling melpa shouldn't be that problematic for just user stuffs, but forcing users to use GNU or melpa-stable is good praxis imo
<old>Anyone know how to fix `__FILE__` for a build so that it's relative.  The package I'm making is using `srcdir` in its makefile and this makes GCC emit `/tmp/guix-build*` as a prefix to `__FILE__`.  I'm looking at `-fmacro-prefix=` to change it but maybe there's a better alternative?
<bricewge>lfam: I used 'git send-email' in emacs to create the bug, and again to send the actual patchset. And then tried 2 times on the cli with 'git send-email', no errors, no bounce from the mail server
<lfam>bricewge: Can you try sending a patch directly to me in that way?
<lfam>I'm curious to compare it to what `git send-email` creates when I run it
<bricewge>lfam: Yes, I'll send you the patcheset
<lilyp>old: replace `srcdir` in the makefile by the empty string :)
<unmatched-paren>lilyp: those versions are set with the ;; Package-Version comment, right?
<ytc>lfam: thank you. but still it doesn't show which packages are missing. it just the percentage of it. :/
<lfam>bricewge: I guess that Deluge needs that bash-minimal for a script wrapper or something?
<lfam>Oh ytc
<lfam>In that case, the --dry-run argument *should* work, but in practice it can be unreliable
<bricewge>Yes, I was tipped of by "guix lint"
<bricewge>lfam: I just send you the patchset directly
<unmatched-paren>lilyp: well, like at, there's a ;; Package-Version comment; but there's also a ;; Version comment with the correct version... but i know nothing about how package.el/guix import elpa work...
<unmatched-paren>lilyp: a version like 0.3.1 wouldn't break the importer/package.el, right?
<lilyp>if we could reliably get the base version, that'd be great, yes
<unmatched-paren>and then patch out the melpa version?
<lilyp>no, construct a git-version from melpa using "0.3.1" as base and a default "0" as revision
<unmatched-paren>well, that package i linked to had a ;; Version: 0.3.1 comment in its source (below some other data fields like Author and Keywords), but i think i understand now that we're not downloading from melpa, we're trying to construct a git uri from melpa data
<lilyp>yup, and that's significantly harder :)
<ss2>hello, anyone wanna look at my snippet?, I think I'm not getting the g-exps quite right there.
<ss2>I'd like to pass a set list as arguments, and expand them with format, and pass it to the binary as arguments.
<unmatched-paren>importers download tarballs and try to generate a package definition from certain files (e.g. Cargo.toml for guix import crate), right?
<lfam>bricewge: Do you host your own email? Or do you use an email service?
<lilyp>i think it's safe to assume they download the tarball to get the hash
<bricewge>lfam: I do not selfhost (yet), I'm using Gandi ATM
<bricewge>What did you find ?
<unmatched-paren>i think i'd better check the source of some other importer before i proceed and see how they obtain versions -- i hope they do it from the tarball, and not from the repo's api
<unmatched-paren>but if they do it from the tarball, i guess we can untar it and extract the version from the ;; Version: comment
<lfam>bricewge: So, I'm not an expert on email at all. I don't self-host nor do I intend to. I compared the headers of your message with a message from myself and anothe person on guix-patches. Your message doesn't seem to have used any of the anti-spam technologies such as ARC, DKIM, or DMARC
<lfam>Like I said before, I have no visibility into what happened to your messages. But it's probably not helping them to not use these things
<unmatched-paren>hm, the crate importer at least uses the service's API :(
<lfam>I also use a custom domain with an email service, but I did set up SPF for my domain
<unmatched-paren>oh, guix/import/go.scm looks promising, it looks like it checks out the source
<lfam>Oh, I see you have something related to SPF in a txt record, bricewge
<lfam>Hm, I dunno
<unmatched-paren>sooooo i guess it's acceptable to check out the source in an importer if the service has no public API? lilyp?
<bricewge>lfam: Dammit! I did touched this DNS record for years, but It go renewd a few days ago, maybe something went wrong
<unmatched-paren>since go does it
<lfam>I don't really know why my email works. I just hope it keeps working
<lilyp>I'm pretty sure that you need to checkout the source anyway for hashing purposes, but feel free to correct me
<unmatched-paren>lilyp: then we can just extract the package version straight from the elisp file that matches the package's name on melpa, no?
<unmatched-paren>unless the version data isn't mandatory
<unmatched-paren>(in case it isn't obvious, i've never made an emacs package :))
<bricewge>lfam: Thanks again. I'll have a look, I should managed to debug it since it's part of my day job nowaday
<lfam>bricewge: If you ask on <> you might be able to reach someone with more visibility into what happened to your email, from our end
<unmatched-paren>hm, actually it looks like the go importer uses hacks way worse than this... it tries to guess the root repo's url
<bricewge>What's odds is that I can still open bugs
<unmatched-paren>what's the (memoize) procedure?
<unmatched-paren>s/\?/ for\?/
<lilyp>unmatched-paren: you can always raise an exception if you feel things are going wrong :)
<unmatched-paren>by 'going wrong', do you specifically mean 'the version field isn't found in the elisp file'?
<lfam>Does anybody use Guix with an HTTP proxy?
<lfam>I'm wondering if this old bug report is still valid: <>
<lilyp>lfam: Does amd64 imply AVX or only SSE?
<lfam>I don't know about those things lilyp
<lfam>Mark Weaver knows, and probably some of the other older Guix contributors
<lfam>If you search the mailing lists for "AVX" and "SSE" and his name, you will probably find some discussion
<lfam>It would be great to document where the line is
<unmatched-paren>so it looks like to get the entire melpa repo, you can wget, which is an elisp-like data file; we can then parse it and retrieve the correct package, and the relevant data: the commit and repo url. we check out the repo with the commit, then try to find a <PACKAGE-NAME-THAT-WE-WANT>.el file in the tree. we parse the file if it exists, and extract the actual package version from the ver
<unmatched-paren>comment/annotation. does this sound like it would work?
<lilyp>only way to test is to try :)
<unmatched-paren>or we could check ALL the relevant el files for a version annotation
<lfam>lilyp: In practice, the line seems to be "whatever the Core2Duo supports"
<unmatched-paren>lilyp: one thing: is there some way to cache the archive-contents file in the store so we don't have to download it every time we import from melpa?
<lfam>Since that is the chip in all the ancient laptops used by Guix users
<lfam>The Thinkpad x200 and the old Macbooks
<lilyp>Found it:
<lilyp>Nothing on AVX, though
<lfam>I'm sure that Mark would be happy to clarify. But I would assume that means no AVX
<ss2>sorry that I asking again. I'd really like to solve this at the moment: The result of it is, that it is not a valid G-expression, or a wrong type is to be applied.
<civodul>lilyp: x86_64 is SSE2-only
<civodul>the baseline
<civodul>AVX came later
<podiki[m]>if anyone has a chance to review that would be most appreciated (some nontrivial changes; I'm aware at least the gexp format isn't consistent)
<PotentialUser-97>How do you keep `guix search` from using a pager?
<unmatched-paren>PotentialUser-97: pipe it to cat
<podiki[m]>ss2: I'm not sure, but seems you might be doing too many quote/unquote gexp equivalent, did you already see ?
<unmatched-paren>PotentialUser-97: <thing> | cat should work on any <thing> that outputs to a pager by default
<unmatched-paren>if it doesn't, it's probably a bug in <thing>
<jgart>sneek, later tell singpolyma:
<sneek>Will do.
<PotentialUser-97>Thanks; that works. Though it is a bit annoying with eshell
<unmatched-paren>PotentialUser-97: yes, i noticed that too
<unmatched-paren>works fine with :term/M-x term, though
<podiki[m]>if you are in emacs, you can try emacs-guix for a nicer interface
<jpoiret>ss2: gexps roughly follow the same pattern as the usual quasiquote/unquote in lisp
<PotentialUser-97>Yup, will be setting up emacs-guix once I got the rest configured
<jgart>jpoiret, but the meaning is very different from , and ,@, right?
<podiki[m]>(though I mostly do stuff from a terminal anyway)
<jgart>I'm still trying to flesh out my mental model for gexps
<ss2>podiki[m]: I've got the page open.
<jgart>Read throught the known references for gexps but haven't used them as confidently
<ss2>jpoiret: yeah, I think I'm just being confused at which level..
<apteryx>PotentialUser-97: probably, PAGER= guix search
<podiki[m]>analogous as in what is being evaluated as a gexp or not, like a quote for not evaluating an expression (and then unquoting part of an sexp to evaluate that part)
<jgart>as I'd like. still struggling to fully understand them
<unmatched-paren>the M-x guix elisp function pops up a magit-esque keybinding panel, then when you press 'pn' an autocompletion prompt with all the packages appears using, in my experience, whatever completion framework you throw at it (helm, ivy, etc.)
<unmatched-paren>it's really neat :)
<jpoiret>jgart: no, I think #$@ is the same as ,@ #$ is , and #~ is ` of course
<civodul>out of context, "of course" would look ironic :-)
<ss2>If I have it as such:, I have wrong type to apply, but if I make interface to (#$interface), I get an invalid g-exp.
<ss2>I'm basically just trying out all combinations now. ^^
<Noclip[m]>Does a FOSS License inside a git repository only affect the working-tree or does it also affect the contents of the .git directory?
<jgart>Does #$@ resemble unqote splicing in that it "splices" objects out of a list into another? But, when talking about gexps is the unit that is being spliced into still a list? or list is something else when talking about gexps? Or, am I confused?
<viivien>Oh, so libera is censoring curse words nowQ
<jgart>I know there are major differences as the manual says
<viivien>Oh sorry it’s the gexp syntax
<jgart>gexp syntax is being censored too by libera? jk
<ss2>I just felt like cursing, and realised that that there's a typo in my code.
<ss2>no it wasn't.
<ss2>I think #$@ is really confusing.
<civodul>i think #$@ looks like Perl (which to me means it looks confusing)
<lilyp>Noclip[m]: it'd say it's the working tree, .git can hardly be licensed
<lilyp>but again, file headers matter
<lilyp>build system metadata (e.g. meson or cargo) are also good pointers
<lfam>Noclip[m]: What do you mean? Are you asking if the license in the source tree covers the historical code in contained in the Git history?
<Noclip[m]>lilyp: If I commit a License to an already existing git Projekt, will the License also affect previous versions of the code?
<lilyp>obviously not
<lfam>Not unless you explicitly relicense the old code
<lfam>As the owner of the copyright, you can do that
<lilyp>Still, to effectively do so would probably require a patch release or something of the sort
<lfam>However, any licenses that previously covered that code will still cover it for old users
<lfam>Overall, I'd say it doesn't matter unless there is a lot at stake. This is probably never going to be litigated
<lilyp>unless you want to reissue tarballs and make Guix hate you forever
<Noclip[m]>Do I need to rebase the repo for that or could I just add a new commit which states that the License should also affect older versions?
<lfam>Don't rebase your entire Git repo
<lfam>Just make a statement that the new license covers the old code, and be explicit about *what* old code it covers
<lfam>However, anybody who received your code with another license will still be able to use your code under the old license
<lfam>That is, you cannot retroactively "unlicense" your code
<lilyp>well, you can if you're doing proprietary "pay us or we will bork your program" licenses, but I assume that's not the case here
<lfam>Right. I mean that if you distributed your code under free license A, you cannot prevent people from using and redistributing it under license A just because you changed to license B
<jgart>re: #$@ confusing: I have a soft spot for perl but admit that every day I'm humbled when I try reading me some perl code. Just never really learned perl seriously. Maybe, I should some day...
<jgart>would be nice to have a more intuitive symbol that is less than 3 characters for that gexp in the future though, I agree
<unmatched-paren>maybe just #@
<jgart>unmatched-paren, that looks nice
<jgart>civodul, would that conflict currently with anything in the reader?
<jgart>anyways, this is mostly cosmetics. I need to get to grips with gexp, ungexp, and ungexp-splicing first
*jgart reads 8.10 yet again
*unmatched-paren has never even tried learning gexps and doesn't know what their use case is
<jgart>Does text-file* use gexp, ungexp, and/or ungexp-splicing in its function body?
<jgart>I think that will be my first investigation
<Noclip[m]>lfam: "However, anybody who received your code with another license will still be able to use your code under the old license"
<Noclip[m]>There is no old license 😆
<jgart>if so, that will by my first try at understanding how to use gexp, ungexp, and ungexp-splicing
<jajr>Hello, I'm trying to use Guix on a Braswell laptop (Lenovo N22 Chromebook) however the integrated keyboard doesn't work on boot, I have to plug in a USB keyboard.
<jajr>After doing some research it looks like I need to compile a kernel with CONFIG_PINCTRL_CHERRYVIEW built into the kernel instead of using a module (as referenced here and also mentioned on the Arch forums).
<jajr>Due to the low power of the machine could I compile a custom linux-libre kernel using my desktop and somehow use that? I've tried compiling a number of kernels from this desktop and copying them to /boot/ just to test them but I'm not getting anywhere with that unfortunately
<lfam>Noclip[m]: I figured :) Then, you can indeed retroactively release that old code under a free software license
<ss2>I think I need to understand splicing in the first place.
<lfam>jajr: Can you send an email about that to <>? We can build this into the kernel, I suppose
<jajr>That would be great, thank you very much. I'll send something over now :)
<jgart>answer to self: yes text-file* uses ungexp-splicing, ungexp, and gexp
<lfam>jajr: It's definitely weird, as the Nix people say. But we should get your keyboard working
<jgart>has anyone tried using gexp->derivation at a repl?
<jgart>or instantiating a bag at a repl?
<jgart>two unrelated questions
<jgart>I guess they can relate..
<jgart>(gexp->derivation name builder)
<civodul>jgart: at the REPL, you can try: ,run-in-store (gexp->derivation "foo" #~(mkdir #$output))
<jgart>ah cool! I remember reading about that meta command
<jgart>civodul, thnx! I'll that
<jgart>much appreciated
<civodul>i wasn't sure but the meta-command is mentioned here:
<jgart>Yup, I came across that one before
<jgart>civodul, Would it make sense to have meta commands for some of the cli subcommands?
<jgart>like `guix build` ...
<jgart>or `guix upgrade`
<jgart>`guix install`
<ss2>okay, I've got it this far now:, but the error is: wrong type to apply: (“enp3s0” “wlp2s0”), That’s all what I want to do: apply that list in (lambda …)
<Noclip[m]>lfam: The reason why I came up with my question is because .git is located in the repo's root directory where usually also the license gets declared. So I assumed that the license might also affect all user owned files within the .git directory. In that case it should also affect the entire git history and other branches since all of that is stored inside '.git'. But my experience with copyright law and licensing is extreme limited therefore I
<Noclip[m]>can just come up with assumptions.
<jgart>`,install emacs-evil-collection`
<civodul>jgart: for these i do, for instance: ,use(guix scripts upgrade) and then (guix-upgrade)
<lfam>Overall, licenses don't work like that. Licenses are about the law, not about computer code. Things do not happen automatically in that way with the law. It's important to be explicit
<civodul>ss2: maybe you need to quote the result of (interface), like so: '#$(interface)
<jgart>but guix-upgrade is not a meta command right? but it is short :)
<civodul>just guessing though, i miss context :-)
<civodul>jgart: true! i'm not sure meta-commands would be appropriate for these, but it's easy to try
<jgart>(guix-upgrade) is "traditional code", a function
<civodul>one can take inspiration from (guix monad-repl) for instance
<jgart>re: meta: ok
*jgart reads
<ss2>civodul: alright, I was wondering where I could place the quote. But it didn’t help.
<jgart>re: ,run-in-store (gexp->derivation "foo" #~(mkdir #$output)): civodul, is there a reason why I get "Permission denied" when trying to open it even with root access?
<jgart>oh I mean not open but ls
<jgart>sorry ignore above
<jgart>I get: No such file or directory
<jgart>so I guess whatever I ran at the repl is not persistent...
<jgart>oh silly, right
<jgart>it only makes a derivation
<jgart>civodul, but that derivation has not been actualized/realized?
<nckx>Morning, Guix. o/
<jgart>and therefore, there is no output yet in the store
<nckx>Sounds legit.
<jgart>nckx, botsnack
<jgart>jgart, botsnack
<jgart>raghavgururajan, botsnack
<porcupirate>Trying to package easyrpg-editor. No tags :(
<porcupirate>Stable branch. Better to use commit?
<porcupirate>Commit or branch name?
<lfam>A branch name is not satisfactory
<lfam>You have to use a commit
<porcupirate>oops. wrong project. No branch name or tag. I'll use commit.
<lfam>To be clear, there is *always* a branch name
<lfam>Or rather, if there is a branch, it has a name
<porcupirate>No stable branch. Just master.
<porcupirate>I was looking at easyrpg player earlier. It has releases and all that. But not editor.
<civodul>jgart: ah that's because it's not built yet
<civodul>BTW, i recommend installing guile-{readline,colorized} instead of using rlwrap :-)
<jgart>Yes, I was just being lazy
<jgart>I've used it before but I just have rlwrap always available
<porcupirate>I'm not familiar with cmake-build-system.
<jgart>civodul, I'm not crazy about guile-colorized but I usually install guile-readline when not using rlwrap
<jgart>I feel like guile-colorized should be something installed as optional instead of pre-baked in Guix System
<jgart>guile-readline can stay though
<jgart>what do people think?
<ss2>Okay, one last try: This is what I’m trying to do. That one section is the last bit before I can complete this service definition for publication.
<ss2>code’s still messy for obvious reasons.
<ss2>I only wan’t to expand interface with --interface $1 --interface $2. I thought I'd get this done in an hour.
<jgart>I just feel the colors in guile-colorized to be distracting usually
<jgart>If a vps provider like this one: already supports Guix System then using guix deploy should be trivial with that vps provider?
<civodul>ss2: you're missing a #$ in front of (interface)
<civodul>(i'm assuming "interface" is a thunk that returns a list of strings)
<jgart>The code for is free software
<ss2>It's a (list "eth0" "eth1") in my system config.
<jgart>I'm brainstorming integrating `guix deploy` API into their web app
<ss2>and I get a: error: ungexp: unbound variable
<jgart>They have a WIP API coming
<ss2>I must be doing something wrong at a different spot then.
<apteryx>ss2 you need to add (use-modules (guix gexp) ...) perhaps?
<ss2>already there.
<ss2>but not in my system config?
<porcupirate>cmake error
<porcupirate>package definition draft
<porcupirate>Yes, it has a lot of artifacts from easyrpg-player package
<porcupirate>I'll clean it up later.
<jgart>If anyone is interested in working on spago see this issue:
<jgart>bower will be phased out in about a year
<jgart>and spago will be bower free
<jgart>but spago can currently be packaged without bower for Guix. It's only currently used if you need to publish a library.
<jgart>All the other core functionality of the spago package manager works without bower
<tribals>hi, folks
<tribals>Is it possible to `guix shell --container guix` to interop with host guix daemon?
<tribals>jgart: how to do that?
<porcupirate>cmake can't find Qt5::QSvgIconPlugin
<jgart>tribals, `guix shell --container -N coreutils -D guix --share=/var/guix/`
<jgart>tribals, -N is short for --network
<jgart>allow containers to access the network
<vagrantc>hrm. guix pull on aarch64 seems to be a world-rebuild with limited substitutes ...
<tribals>jgart: is it safe to share whole /var/guix?
<jgart>I wouldn't be the person to ask about what is safe ;)
<tribals>jgart: :D
<vagrantc>not sure when i last attempted to "guix pull" ... guix describe says Jan 01 1970 ... pretty sure i updated more recently than that :)
<jgart>sometimes you might want `--expose/etc/ssl/certs` also
<jgart>tribals, if you get an SSL error or something
<cbaines>vagrantc, hasn't started building things post version-1.4.0 merge yet, so the substitute situation for non x86_64-linux and i686-linux is pretty dire
<vagrantc>cbaines: makes sense
<vagrantc>cbaines: well, at least i can do some "guix challenge" checks after it's done :)
<vagrantc>hrm. i wish i could point guix challenge at a system revision or manifest or something
<cbaines>vagrantc, cool, will probably be at least a few weeks before there's reasonable coverage
<vagrantc>well, it's cold, so running this server for a bit is kind of like a 60-watt space heater :)
<vagrantc>although a bit on the noisy side
<porcupirate>aggregate ‘QPainterPath clip’ has incomplete type and cannot be defined
<porcupirate>I'm close to giving up for now...
<cbaines>vagrantc, by the way, if you have machines to hand, they could maybe build things for
<vagrantc>cbaines: would it be ok if they were sporadically available?
<cbaines>vagrantc, yeah, that's fine
<vagrantc>cbaines: currently have one apm mustang with 16GB of ram and 8 cores running Guix System ... would need to also set up a vpn or something as it's not publicly available
<cbaines>I only run my Power9 build machine part of the time
<cbaines>vagrantc, with the Guix Build Coordinator, the agents don't need to be publically available
<vagrantc>cbaines: they poll and push ?
<vagrantc>cbaines: maybe we should get this thing running, then :)
<vagrantc>can they re-use existing items from the store?
<cbaines>vagrantc, yes (I actually want to get some kind of hash checking in place eventually, so the build starts with a specific set of inputs by hash, not just store filename)
<vagrantc>well, i'm currently running guix pull, which is still downloading ~750MB of mostly source tarballs
<vagrantc>though my proxy is having troubles downloading from
<cbaines>I'm hoping to start better addressing the eurocentric substitute server situation this year
<cbaines>I'm really busy at the moment, but I want to try and keep going with the mirroring stuff, and get mirrors in places like the US
<vagrantc>yeah, that would be very nice :)
<podiki[m]>I have my old desktop just sitting next to me (I'm in the US), was wondering how easy or not it would be to run in my (university) office
<podiki[m]>presumably getting access from the outside would be difficult, but I could tunnel out probably? not sure how it would work
<cbaines>podiki[m], I've heard of wireguard being used for that kind of thing
<chipb>not necessarily, depending on the university network.
<vagrantc>yeah, wireguard is really cool
<podiki[m]>I've only briefly played with wireguard
<podiki[m]>but okay, I will investigate
<podiki[m]>it is not a beefy machine for compiling, but has a ton of ram (24gigs?)
<podiki[m]>only 4 cores (4 threads total I think?); x86_64
<cbaines>vagrantc, I should really go to bed, but if you are interested in building things, join the guix-sysadmin mailing list (if you're not already a member) and we can coordinate the setup (it's minimal, but the agent needs an ID creating and a password)
<vagrantc>cbaines: thanks!