IRC channel logs


back to list of logs

<vagrantc>axd-v: set up NAT and port forwarding as appropriate
<vagrantc>axd-v: which networking method is virtualbox using? it's almost certainly possible to configure the network in a similar manner.
<vagrantc>axd-v: but yes, most wireless access points will drop traffic from unassociated mac addresses
<axd-v>vagrantc: I wish I could respond to your questions. All of my use of VMs in the past was a simple gui point and click set up and then working within the emulated environment. Things just worked without me thinking about it. This is the answer that dismissed my efforts:
<axd-v>vagrantc: from what I could tell setting up a network bridge is the way to get networking for guest OSs, couldn't see another option, but admittedly haven't read the manuals.
<axd-v>vagrantc: would you be able to suggest any good guides for "setting up NAT and port forwardsing as appropriate"? A lot of info comes up during a search and I'm afraid I don't have hours upon hours to waste on reading this mostly unrelated to me material and trying to find the stuff that's applicable.
<vagrantc>i haven't ...
<nckx>ACTION pokes repeatedly with a stick
<nckx>mbakke: Has staging begun yet?
<Copenhagen_Bram>Does bluetooth work with pulseaudio in guix?
<brendyn>I discovered that in guile, top level defines aren't optimised fully, but can be if they are wrapped in let. Does guix incur any performance loss by not doing this?
***dmc is now known as cd
***cd is now known as cmd
***cmd is now known as cd
<nckx>brendyn: My entirely unscientific opinion is that any (probably slight) performance gains through such cleverness wouldn't be worth the (even slight) increase in code complexity.
<nckx>More generally, we'd probably be better off if we managed to make Guile optimise *less* rather than more. ‘guix pull’ (i.e. compilation) is horribly slow ATM, while the actual execution speed is... fine.
<nckx>ACTION → beddy-byes
<brendyn>nckx: I find guix quite slow for a package manager. 'guix package -s' is slower than any other package manager I've seen. It's even slower than searching the raw git repo with ag to find a package.
<brendyn>'guix package -s blender' takes 2.7 seconds. 'ag blender ~/guix' takes 0.09 seconds, and searches a lot more files it doesn't need to.
<vagrantc>ACTION has been known to use 'git grep PACKAGE'
<brendyn>If I was a more experienced programmer, I'd try to figure out how to make it faster.
<OriansJ>I'm honestly surprised that guix pull doesn't update a local sqlite database with the currently available packages to enable faster searching
<g_bor>hello guix!
<g_bor>What is guix-register?
<g_bor>Recently it shows up in my git working tree sometimes as an untracked file
<slyfox>$ guix-register --help
<slyfox>guix-register -- register a closure as valid in a store
<g_bor>I have a feeling that guix-register should be gitignored WDYT?
<efraim>g_bor: it can be deleted, it was recently depreciated
<g_bor>efraim: thanks!
<g_bor>I've packaged prometheus-node-exporter. I'm pulling the sources from git, and the latest tag is 0.16.0, so no stable release yet. I decided to use the current tip of master instead of the tag. Is it ok to do this. If I get it right we usually package released software only. What is the policy in this case?
<g_bor>Sorry, is it ok to do this?
<brendyn>How come I run guix environment autoconf, non of the autotools are in my path?
<g_bor>How do I know if a branch is frozen?
<civodul>Hello Guix!
<g_bor>How do I know if a branch is frozen?
<civodul>hi g_bor!
<civodul>you need to ask :-)
<civodul>we don't currently maintain a status page or anything like that
<civodul>if you have ideas on how to improve on this, they're welcome!
<g_bor>ok, then I will ask :) Is staging still open?
<g_bor>civodul: I guess if we have a workflow for freezing branches we might integrate this functionality to cuirass. WDYT?
<g_bor>Also, when do we close bugs? If the fix lands on staging or core-updates is that enough, or we close them when the fix lands on master?
<g_bor>If the latter, how do we keep track of this?
<civodul>g_bor: i think staging is open, but please email guix-devel to be sure :-)
<civodul>re closing bugs, it depends: sometimes it's better to wait until the fix is in master (it it's a serious bug, or if it's bound to show up again), sometimes it's ok to close it right away
<civodul>at your discretion
<g_bor>ok, I've sent a patch to a bug,and added STAGING to the subject. I would like to have it reviewed, but I'm pretty sure it's ok :)
<snape>is there a way to avoid *.fr.texi being modified?
<snape>it's a very tiny bit annoying :-p
<snape>because when they are modified, git pull doesn't work anymore, one has to 'git checkout -- .' manually, etc
<g_bor>snape: I've already talked about this to roptat. I guess that we need a more streamlined workflow to handle this correctly. The current situation is that the files are checked in, and gets modified whenever the po files or the manual is updated.
<snape>g_bor: so why don't we update them when we update those po files?
<g_bor>a possible working solution would be to update them whenever the manual or the po files get updated.
<brendyn>guix environment doesn't seem to be working for me. 'guix environment autoconf -- autoreconf' fails to run. It doesn't seem to actually put any of the binaries into my path variable
<g_bor>However this would result in partially translated fr manuals.
<g_bor>Better would be: keep a manual that is the copy of the manual when the po files were last updated, and depend on that. This also has it drawbacks...
<g_bor>I'm currently not sure about the correct way to handle this.
<g_bor>Another easy solution would be to simply gitignore these files...
<snape>brendyn: guix environment will provide only autoconf's dependencies to you. If you want autoconf in the environment, you need to type 'guix environment --ad-hoc autoconf'
<g_bor>However, then it might be possible to not have these in a fresh git checkout.
<snape>yes... is there a bug opened about it?
<snape>I think I saw one discussion on the ml about it
<snape>among other things
<brendyn>Hmm ok but that doesn't work for the inputs of said package. How can I create an environment with everything required to build a certain package?
<snape>if you want everything required to build hello: 'guix environment hello'
<snape>if you want everything requires to build hello plus guile: guix environment hello --ad-hoc guile
<brendyn>That doesn't work. I made a package that has autoconf as a native input, but guix environment PACKAGE doesn't put autoconf in the path
<g_bor>snape: I don't think so, but maybe there should be. The situation is much better than it initially was, when make clean removed these files, thus breaking bootstrap.
<snape>I don't think so. At least ./bootstrap could be automatically rerun.
<snape>This is not the case anymore: a manual step is required.
<g_bor>snape: I also see guix-register reborn from time to time as an untracked file.
<g_bor>snape: originally bootstrap failed with error after make clean.
<snape>yes, but if your workflow is: make || (./bootstrap && make), it's not a problem
<snape>oh got it sorry
<snape>I never experienced ./bootstrap failing though
<snape>I thought you were saying that 'make' was failing
<snape>brendyn: do you modify the PATH in your .bashrc?
<brendyn>snape: no
<snape>brendyn: can you try 'guix environment motion' and tell me if autoconf is in the PATH?
<brendyn>snape: It's not
<roptat>hi guix!
<snape>brendyn: what about 'guix environment -C motion'?
<snape>hi roptat
<roptat>re, I think I forgot to push the modifications when I last pushed the po file
<snape>ha ;-)
<roptat>I think an easy fix is to push whatever is now
<roptat>I'm not completely sure though
<snape>what about not updating it with 'make'?
<brendyn>snape: It works in that case
<roptat>for make, *.fr.texi depend on the po file only, so a modification to the English manual shouldn't modify it
<brendyn>What does this mean?
<g_bor>roptat: I also think that pushing the current content will work.
<roptat>ok, I can't do that right now though
<snape>brendyn: -C means --container. It
<snape>'s in a container, so it is not bothered by your .bashrc and co
<snape>If my understanding is correct
<snape>brendyn: there may be an issue with how you setup your environment though (.bashrc, .bash_profile)
<roptat>if we remove the rule to make *.fr.texi, it will be difficult to regenerate it I think
<snape>brendyn: do you source .bash_profile in your .bashrc?..
<roptat>but the current situation is also quite error-prone...
<snape>roptat: I imagine a 'make texi' rule that would not be called upon 'make'
<brendyn>nope but I source /etc/profile
<brendyn>not sure why i did that
<brendyn>If I run guix environment --pure motion, it doesnt work either. Should --pure provide autoreconf?
<snape>brendyn: --pure isn't in a container, so it should behave more or less like normal environments
<roptat>snape: makes sense
<brendyn>.bash_profile is only loaded on login though so it should polute the environment produced by guix should it?
<snape>you don't log on guix environment
<snape>so it's not called
<snape>but .bashrc is read
<snape>so .bashrc shouldn't source /etc/profile IMHO
<roptat>we need to make sure *.fr.texi are regenerated by guix pull and before every release
<roptat>I think it's better to have a partially translated up-to-date manual than a fully translated manual that doesn't apply anymore :)
<snape>(except in particular cases like ssh)
<g_bor>Is shepherd automatically restarting a process if it dies?
<snape>g_bor yes
<roptat>g_bor: not if it dies repeatedly I think
<snape>roptat: try to mess up with your Slim conf, you'll end up in an endless slim-trying-to-start loop
<snape>which prevents to modify the conf :p
<roptat>is that because it doesn't die quick enough?
<roptat>I've had situations where herd status told me the service is dead and it would be restarted
<snape>yeah I'm not sure maybe there are situations where services are not restarted
<snape>brendarn: you could try to source /etc/profile only in specific cases, as GuixSD's default .bashrc does:
<g_bor>Ok, thanks! And how do you test when you have written a new service definition? (This is my first service)
<snape>g_bor: make sure the service is stopped + guix system reconfigure
<roptat>or start a VM with that service
<g_bor>fine, just what I thought...
<snape>g_bor: guix-register is different because it's untracked. So it doesn't prevent 'git pull' to work
<brendarn>snape: yeah I've fixed it thanks, I hadn't realised it'd edited my .bashrc like that
<snape>cool, yw :-)
<rekado_>Is it possible to replace the “r-minimal” package used for building *all* R packages programmatically?
<rekado_>i.e. replace the r-minimal used by the build system for a manifest.
<rekado_>I remember that there was a patch draft for allowing to override build system packages, but I think it was never applied.
<rekado_>I suppose one could fold over the packages and substitute the #:r argument.
<rekado_>but how would I do this for all dependencies as well?
<rekado_>“package-mapping” maoybe?
<rekado_>oh, r-build-system does not pass #:r down to the “lower” procedure.
<efraim>Couldn't you use --with-input=r=r-minimal
<efraim>Its been a while since I tried but I thought doing that with bash would rebootstrap the system
<civodul>--with-input won't work because R is an implicit input
<civodul>package-mapping with a different #:r would do, rekado_
<rekado_>changing the r-build-system to support the #:r-gument would result in rebuilding about 590 packages.
<rekado_>is that okay for the master branch?
<rekado_>according to contributing it would be more appropriate for staging.
<rekado_>I guess I could just push a new branch and have it built on berlin.
<pkill9_>ACTION wants to try this
<g_bor>rekado_: I guess I would do it on staging.
<g_bor>rekado_,civodul: I'm not sure about GSoC rules, but I guess our interns know by now the results of the first eval. I that correct?
<rekado_>maybe no rebuilding needs to happen at all. It’s just a change to private-keywords on the host side.
<civodul>g_bor: we'd need to check the GSoC timeline on the web site
<civodul>rekado_: these are small packages though? maybe ok for master, or maybe another incentive to get staging merged :-)
<rekado_>looks like it does not cause a rebuild.
<rekado_>but yeah, most of them are simple packages that don’t take a long time to build at all.
<rekado_>I saw that Mr Rescue has been removed because it is not compatible with the current version of Love. Can it be made compatible?
<rekado_>(we have very few games)
<jlicht>hey guix
<sneek>jlicht, you have 1 message.
<sneek>jlicht, snape says: mu4e-conversation looks good! It's not yet in Guix though :-)
<civodul>rekado_: i wondered what that meant, too!
<civodul>heya jlicht!
<Rukako>hi guix!
<civodul>heya Rukako!
<civodul>how's everything?
<Rukako>things are going well, I am currently toying with fibers
<civodul>Rukako: excellent!
<civodul>the idea i had was to make an incremental move towards Fibers
<civodul>step 1 would be to use signalfd(2) instead of actual signal handlers, and have a big select(2) loop at the top level
<Rukako>to move shepherd into a more event-drived approach?
<civodul>does that make sense?
<civodul>so this step 1 involves writing bindings to signalfd(2), using (system foreign)
<Rukako>never tried the foreign interface before :p
<civodul>there's already a couple of bindings in modules/shepherd/
<civodul>hopefully they can serve as an example
<Rukako>does it use libffi or something? I used it in the past for my own mini-language thing
<civodul>(system foreign) uses libffi under the hood, yes
<civodul>signalfd(2) is probably a bit more involved than the other bindings in, but i can help
<civodul>or probably other people on #guile could help as well ;-)
<civodul>so let me know how it goes
<civodul>step 2 will be switching to Fibers instead of the select(2) loop
<civodul>but let's focus on step 1 for now ;-)
<Rukako>I have come to like shepherd, it feels quite elegant
<civodul>heh, it's very simple, if not simplistic ;-)
<jlicht>hey all, just read online irc log: I have some signalfd bindings already
<jlicht>they are kind of rough (and possibly incorrect), but I could put them online somewhere if someone could use them as a starting point for a good shepherd hacking session
<Rukako>jlicht: that would be helpful!
<jlicht>apologies for the state of the code, the semi-relevant stuff should be in signalfd/utils.scm
<Rukako>thank you, I will take a look at it!
<jlicht> A problem I ran into is that guile has an... interesting way of handling signals currently, so there was some problem with signalfd-based handler not being called consistently (and different behaviour on repl vs non-repl)
<Copenhagen_Bram>ugh i'm getting the system: command not found issue
<roptat>Copenhagen_Bram: yesterday someone had this issue. it was fixed by running guix pull once more
<jlicht>Copenhagen_Bram: another `guix pull' might fix your issue. Guix now depends on the guile-sqlite bindings being available, and you might still be running an older version.
<roptat>hey, I won :)
<Copenhagen_Bram>ACTION runs guix pull again
<g_bor>hello guix!
<Copenhagen_Bram>Hello g_bor !
<g_bor>I'm trying to create a service definition. I guess I got it right, but it seems that I'm missign something.
<g_bor>Do we haev to register a new service-type somewhere, like we do it for patches?
<snape>g_bor: no
<snape>once the service-type is defined in a module, people can use it in their config.scm
<snape>as long as they 'use' that module
<snape>(there is this 'use-service-modules' macro)
<g_bor>actually, I've included it in my config, reconfigure worked without problem, but herd status does not show the service
<snape>and the program isn't running?
<snape>what does ps say?
<snape>well I guess it's not
<snape>what does 'reconfigure' says about it? It should say 'service foo has started'
<snape>or 'service foo could not be started'
<g_bor>:) oops wrong terminal :)
<snape>:-) it's useful to run 'ps auxww | grep program' sometimes
<snape>to see if it's running
<g_bor>no, actually it's not running.
<snape>yeah, and what does 'guix system reconfigure' say?
<g_bor>I will try to havee a look at the reconfigure output.
<snape>if it says 'it could not be started', it means there was an error
<g_bor>actually the service is not metioned in the guix system reconfigure output...
<civodul>jlicht: ooh nice, thanks for the signalfd bindings!
<snape>he :-) that means the Shepherd didn't even try to run it
<snape>g_bor: it would be helpful that you provide your config.scm and your service definition
<g_bor>:) ok, I will paste it.
<jlicht>civodul: yw
<civodul>"interestingly", commit 32eb44240db23b2320a68a3ab17370531945587f (adding #:r) causes a rebuild of a large subset of the 'guix pull' derivations
<rekado_>it doesn’t cause a rebuild of R packages, though.
<rekado_>does this mean that the guix pull derivations accidentally depend on too much of Guix?
<civodul>no no, everything works according to the plan :-)
<civodul>i'm just trying to see whether that's the case
<civodul>i mean, often enough we don't get substitutes for 'guix pull' and we end up rebuilding the world
<civodul>(the world of guix pull, i.e., "guix-core", "guix-extra", "guix-packages", etc.)
<civodul>so i'm trying to run it regularly to see whether all that rebuilding is justified
<g_bor>hi, I've pasted it to, as service and config. I've got to go now, but it would be nice if you could leave me a message about what is rong with that.
<jlicht>snape: a patch for inclusion of mu4e-conversation in Guix seems to be in the pipeline :)
<snape>yes, it arrived recently, I saw it too!
<snape>g_bor: your service-type should extend 'shepherd-root-service-type' with the shepherd-service that you defined (but did not use)
<snape>otherwise it's just a Guix service, but not a Shepherd service yet :-)
<snape>civodul: is there an hydra guix-modular jobset? I can find only one on the web interface and it seems disabled for months.
<mbakke>g_bor: Your staging patch LGTM. If you're around, feel free to push it.
<sneek>Welcome back mbakke, you have 1 message.
<sneek>mbakke, efraim says: the ldb patch should include mips64el in 64-bit targets
<mbakke>g_bor: It lacks a proper commit message, though :-)
<mbakke>I wonder if Hydra can manage two evaluations at the same time.
<civodul>snape: the guix-modular jobset doesn't work on Hydra because (IIRC) Hydra systematically adds "." to the load path, meaning that build-aux/hydra/guix-modular.scm ends up using the checked out Guix modules instead of the ready-to-use Guix modules
<civodul>see what i mean?
<civodul>this in turn means that it rebuilds every .scm file, as can be seen in
<civodul>maybe we could around it by explicitly removing "." from %load-path
<snape>civodul: Yes I see.
<snape>civodul: is there a way to see the hydra configuration somewhere? Specifically the argument list that is sent to the "nix expression" for evaluation.
<snape>which are the inputs, IMUIC
<pkill9_>what's the most linux-friendly tablet PC available?
<pkill9_>other than the thinkpad tablet version
<civodul>snape: in this case it's a "Guile expression" :-)
<civodul>you can see the "Inputs" tab on the web UI
<civodul>that is passed as an alist to the 'hydra-jobs' procedure
<civodul>the 2nd parameter
<civodul>inputs can be checkouts, strings, or byproducts of other jobsets
<snape>civodul: I was looking for some other inputs like 'subset (in gnu-system.scm)
<snape>or 'systems
<snape>the only input that I can see on is named 'guixSrc' and doesn't seem to be used within the evaluation
<snape>I understand that it's used indirectly because the nix expression is taken from the input, but I was looking for examples of how other inputs could be used
<civodul>snape: see
<snape>civodul: oh great, thanks :-)
<civodul>and for "systems" you'd just specify a list of strings IIRC
<g_bor>mbakke: I will push it in a few minutes.
<mbakke>g_bor: Excellent, I'll (try to) start Hydra shortly after.
<g_bor>Ok, I've pushed it. rekado_ said to expect minor breakage on java, because tests were effectively ignored, so we will see how it goes...
<g_bor>hello guix!
<g_bor>Do you know where is the current shepherd log? And what is logged by shepherd?
<g_bor>Thanks to savannah-hackers our git repos now show correctly on the guix group page! The cuirass repostiory would need a description update.
<civodul>g_bor: woohoo, thanks for reporting the issue!
<civodul>shepherd now logs to syslogd, which writes to /var/log/messages by default
<civodul>Python 2 deprecation is discussed on LWN:
<civodul>maybe that's what prompted lfam to raise the issue on guix-devel
<g_bor>civodul: I can't see in the log what shepherd is trying to execute. I think it would be a useful addition WDYT?
<snape>g_bor, you talk about the programs's output while civodul talks about the Shepherd's output
<snape>g_bor: there is a bug report about it:
<lfam>civodul: I'd been meaning to start the Python 2 discussion for a while, but that article did remind me to go ahead and do it :)
<snape>g_bor: according to the bug report, it should be in tty1. I never tried though, I usually start the program manually to see it's output.
<civodul>lfam: heh :-)
<lfam>I figure it will be a gradual and informal process, but it's good to get some feedback from everyone about what they are using
<civodul>yes, definitely
<civodul>ACTION uses very little Python
<civodul>well i certainly use applications that use Python, but i don't use Python directly
<civodul>so my use case is very simple
<civodul>the bioinfo use case may be much trickier :-)
<civodul>ACTION has to go
<lfam>c ya!
<pkill9_>does guix have libc++?
<pkill9_>oh nevermind
<pkill9_>oh actually where?
<lfam>pkill9_: I believe it's part of LLVM
<Copenhagen_Bram>Where do I install stuff I've compiled or downloaded?
<pkill9_>doesn't appear to be lfam, thanks anyway
<snape>pkill9_: isn't it libstdc++?
<snape>in gcc
<pkill9_>hmm probably
<pkill9_>hmm no
<snape>description is "GNU C++ standard library"
<pkill9_>i'm looking for a which isn't in libstdc++
<snape>indeed it's
<snape>Copenhagen_Bram: you package it :-p
<nckx>Copenhagen_Bram: If you really don't feel like packaging it for Guix: ~, /usr/local, /opt, … wherever you want, really.
<nckx>ACTION prefers ~ since it's ‘me-generated’, even if I just typed ‘make’.
<nckx>~/.local/bin seems to be conventional.
<roptat>so my system boots and tell me to run fsck manually before dropping me in a guile shell
<roptat>how do I run fsck from there?
<nckx>roptat: e2fsck -y /dev/foo
<roptat>from guile?
<nckx>Sure you're not in bournish?
<nckx>Otherwise (system or (system*, I forget which.
<roptat>oh yes indeed
<nckx>ACTION has long since patched Guix to just run ‘e2fsck -y’ unconditionally because they don't like such theatre.
<nckx>Is anyone else's mu4e complaining that html2text is deprecated?
<nckx>And is this my problem, or upstream's?
<snape>nckx, Copenhagen_Bram: Yes of course. I didn't mean packaging them so to release them to the community, it could be a personnal package too.
<snape>but I guess it depends of your use case
<mbakke>I wonder if gnu-pw-mgr can be moved to (gnu packages password-utils).
<lfam>mbakke: +1
<bavier>mbakke: have we been moving away from putting GNU programs in their own modules?
<nckx>bavier: Oh? When & why were own modules preferred?
<bavier>nckx: afaik, "since the beginning", or at least that's the impression I received from civodul quite a while ago.
<nckx>bavier: Ohkidoke. Why only GNU packages though?
<bavier>as far as "why?", I assume to give the GNU packages a place of honor, or such
<lfam>I don't think we need to rush to move packages around, but there are lots of GNU packages consolidated with other related packages in bigger modules
<nckx>bavier: OK, thanks for the explanation.
<roptat>that was expected, but fsck removed every instance of the guix binry
<roptat>I think I can't recover from that ^^'
<nckx>I wonder how Guix copes with entries in /var/guix missing from /gnu/store, although I guess that's rather moot if Guix is missing...
<roptat>and the iso I generated from a recent commit kernel panics :/
<roptat>(attempted to kill init)
<nckx>...crikey. So no backups, I hesitate to ask?
<roptat>yes I have backups :)
<nckx>ACTION breathes.
<roptat>I'd like to say complete backups, but you never know :p
<nckx>I'm about to be kicked out of the library. Good luck, roptat! o/
<rekado_>ACTION is annoyed by some messages on guix-devel
<rekado_>I guess I need a long vacation without computers.
<mbakke>nckx: By the way, the Zathura plugindir patch was accepted upstream. Now I just have to fix up the meson stuff and we can remove all the hacks with the next releases.
<efraim>thats always exciting
<Copenhagen_Bram>okay I'll package it :)
<Copenhagen_Bram>where's the packaging tutorial
<nckx>Copenhagen_Bram: There's section 4.1 (Defining Packages) in the manual.
<nckx>rekado_: ...or people?
<nckx>sneek: computers are our friends.
<vagrantc>so i've got an aarch64 system, and "guix pull" is reasonably current ... but my user has no profile, and so i have to manually add .config/guix/current/bin to PATH every time i login
<mbakke>sneek: What are computers?
<sneek>Its been said that computers is our friends
<nckx>Damn it sneek you had one job.
<nckx>sneek: what is staging?
<sneek>staging is none of your business
<nckx>Cheeky bot.
<mbakke>sneek: The staging branch is live on Hydra!
<sneek>Got it.
<nckx>That went about as well as expected.
<mbakke>sneek: How is your unicode support?
<nckx>joshuaBPMan: Yep.
<nckx>sneek: help
<nckx>^ will send you deets.
<nckx>Mainly used as a message bot for bouncerless peasants, to be honest.
<nckx>vagrantc: I'm probably missing the point, but... isn't that the desired behaviour if your user doesn't have a profile?
<vagrantc>nckx: i'm not sure what expected behavior. my expectation is that "guix pull" would bring in new versions of guix
<vagrantc>it did up until the new change to create a profile for guix itself
<vagrantc>though, admittedly, users without any profiles seems like a bit of a corner case
<nckx>I'm afraid I'm not at all familiar with those changes (I don't ever use ‘guix pull’) or how they interact with [the lack of] your other profile[s].
<mbakke>I too wonder what the "best" approach for dealing with the new `guix pull` on a foreign distro.
<mbakke>For now I added `export PATH="~/.config/guix/current/bin:$PATH"` to /etc/profile (or equivalent).
<vagrantc>overall, the new guix pull is really great ... it's so much easier to revert in case of a broken guix.
<vagrantc>hrm. elfutils failing to build on aarch64
<vagrantc>which blocks linux-libre from building...
<vagrantc>fails in the testsuite: FAIL:
<mbakke>vagrantc: That's odd, I have /gnu/store/7bwiq4h7y5dgm2ybiwvwsxaa6lj3f6h3-elfutils-0.170 on aarch64. Perhaps it's an indeterministic error?
<efraim>i have it on mine too
<vagrantc>it happened on the second run too
<mbakke>vagrantc: I tried rebuilding elfutils on a rk3399 firefly, which still worked. Can you file a bug report?
<vagrantc>mbakke: will dig a little deeper first, but sure, can follow up with a bug
<rekado_>vagrantc: adding ~/.config/guix/current/bin as the first item on PATH is the recommended way of using the new “guix pull”.
<rekado_>there’s no more confusion with some old Guix executable loading another set of modules from ~/.config/guix/latest.
<vagrantc>on another machine, that somehow gets added to PATH automagically
<vagrantc>both running guixsd, but one has nothing in ~/.guix-profile
<thorwil>hmm, looks like garbage collection removes stuff that `guix environment guix` has to restore, then
<thorwil>wonder if i should add all those dependencies to my manifest
<rekado_>nckx: yeah, no people would be even better; my computer is mostly used as a gateway to people, though.
<rekado_>thorwil: if you want the result of “guix environment” to be persistent you can register a so-called garbage collector root with “-r”.
<rekado_>“guix gc” removes everything that cannot be reached by following links from garbage collector roots.
<civodul>so, under which circumstances can the kernel decide not to dump core?
<thorwil>rekado_: yes, it behaves as expected. registering such a root looks like a clean solution, thanks!
<civodul>i know of: the rlimit too low, or not enough disk space
<civodul>but there seems to be something else preventing the kernel from dumping core in my case
<civodul>it dumps core for a trivial program but not for a full-blown guile
<rekado_>civodul: here’s a checklist under “WHY DO I NOT GET A CORE DUMP?”:
<civodul>thanks, rekado_!
<thorwil>so i just created a new gc root in current dir, which is kinda unfortunate
<thorwil>can i just mv it to /var/guix/gcroots?
<cbaines>I'm fighting to get lollypop working on Debian, the package seems to work ok on GuixSD... I've manually installed glib, gsettings-desktop-schemas, dconf and gstreamer, which helped, but I'm still getting an error
<cbaines>Are there any tricks for debugging Glib GIO things (<- whatever that is)?
<cbaines>Wahoo, I needed to manually install gst-plugins-base as well
<cbaines>I have broken icons, but at least it starts!
<civodul>success! :-)
<cbaines>I installed some more packages, and I even have icons now
<civodul>icons are overrated anyway ;-)
<civodul>i just realized we were potentially no longer getting substitutes for 'guix pull' due to a buglet in (guix self)
<wigust>I wonder should we get substitutes for package objects?
<civodul>you mean for gnu/packages/*.go?
<rekado_>“buglet”, heh :)
<wigust>Yes. (I couldn't find such a question several days ago.)
<civodul>so yes, builds the same thing as 'guix pull'
<civodul>except that lately it was potentially not building the exact same thing, so you would possibly not get substittues
<civodul>basically code that builds guix/config.scm was leaking variables from the current (guix config), which could differ
<vagrantc>is it possible to get the log file from a failed build? I tried: guix build --keep-failed --log-file elfutils
<vagrantc>but it doesn't make it obvious where to find it
<mbakke>vagrantc: I think --log-file only works for successful builds.
<mbakke>For debugging I typically just use shell redirection.
<civodul>mbakke: it works for both failed and successful builds
<civodul>vagrantc: do you get a URL or an error from 'guix build --log-file'?
<vagrantc>ACTION tries "guix build --keep-failed --log-file elfutils | tee elfutils.log"
<civodul>vagrantc: note that --log-file works only for completed builds, though
<civodul>so you could do "guix build -K elfutils", and *then* "guix build --log-file elfutils"
<civodul>that's a hint that we should clarify the doc :-)
<vagrantc>civodul: not sure the difference between failed but completed, and failed but incomplete ... or the other various permutations
<vagrantc>awesome, tee didn't work.
<vagrantc>what redirections do i need to capture this?
<civodul>what i mean is that "guix build --log-file foo" won't work if no attempt was made to build 'foo' (either locally or by a substitute server)
<civodul>does "guix build --log-file elfutils" return something useful now?
<janneke>vagrantc: |& tee ? /me is not sure
<vagrantc>civodul: it just starts the build over again
<vagrantc>civodul: and doesn't give me any URL to the log
<civodul>and "guix build --log-file elfutils --no-grafts"?
<vagrantc>that produces a log file :)
<civodul>aaaah, see? :-)
<vagrantc>i would be lying if i said i saw and understood. heh. :)
<mbakke>civodul: Oh, thanks for the clarification :-)
<vagrantc>but i now have a log file i can attach to a bug report. :)
<civodul>the "--no-grafts" option disable grafts since grafting would require to build the ungrafted version first
<civodul>in your case you know the ungrafted version fails to build in the first place
<civodul>rekado_: not much success regarding introductory videos :-)
<vagrantc>my understanding of grafts is admittedly limited
<vagrantc>wow. .guix-profile/bin is just a symlink when there's only one package in it
<civodul>yep, that happens if you profile contains only one package providing bin/
<civodul>ACTION -> zZz
<civodul>good afternoon/night!
***apteryx is now known as Guest12551
<Copenhagen_Bram>Which process do I kill to shut down my locked up graphical session so that it goes back to the login where I can pick another window manager?
<Copenhagen_Bram>The desktop environment is xfce4 and it's frozen at some time during a really hillarious scene from Dragon Ball Z Abridged playing in mpv
<Copenhagen_Bram>Also I tried changing my shell to "screen" but "screen" doesn't exist so I couldn't log in as my user. Whoever said it's not a good idea to change the root shell, I can definitely see your point now. I've changed my shell to "/run/current-system/profile/bin/screen" in my config.scm, but guix system reconfigure is now very, very slowly downloading a 2GiB texlive package, which won't finish until midnight. I've
<Copenhagen_Bram>fixed the shell problem temporarily by editing /etc/passwd, now I just need to kill my locked up graphical session
<Copenhagen_Bram>I guess I'll try killing whatever program starts xfce4
<Copenhagen_Bram>ok actually i'm not sure which program to kill