IRC channel logs
2018-03-08.log
back to list of logs
<rekado>jboy: could you post your config file? <rekado>soundtoxin: I cannot reproduce this. What desktop environment or window manager do you use? <rekado>soundtoxin: is this on GuixSD or on a foreign distro? <soundtoxin>It's only been happening for about 24 hours or less <soundtoxin>Even the suggestions when typing a url only flash on-screen for a second before disappearing. <rekado>does this persist after a reboot? <soundtoxin>rekado: I haven't rebooted lately, but it persists when restarting firefox at least. <rekado>and it appeared out of nowhere within the last 24 hours? <soundtoxin>I update all the time, but it's hard to pinpoint exactly when it happened. <soundtoxin>I will say it started to happen with a firefox session that was already open, then after restarting it said it was updating to a new icecat and the issue persisted. <soundtoxin>So, it may be related to a system update I did while the browser was already open. <soundtoxin>Okay, I did 'pkill icecat' and then started it again after a few minutes and things seem to be in working order now. <soundtoxin>Ugh. It came back. It wasn't happening for a bit after restoring my tabs, but it is now. Maybe one of my tabs is breaking something. <rekado>I had a similar issue once with stumpwm, but that was on Fedora and with Firefox (not icecat). <rekado>maybe it’s a problem with tiling WMs. <nckx>ACTION uses i3+Icecat all day, but hasn't — touches wood — had that problem... <marusich>Does anyone here use Magit? I hear it's supposed to have a mode for editing commits, but when I run "git commit", I'm always in Fundamental mode. <Apteryx>marusich: I had that problem recently. Usually it hooks right into it. <Apteryx>Not sure what it's due for, I hadn't time to debug it. <marusich>Huh, OK. Good to know. I mainly was curious because I wanted the column width to be 72, and I was getting tired of setting it manually... <CompanionCube>ACTION just dug himself into a hole with updating guix on a non-guixsd system <CompanionCube>'guix pull: error: could not find bootstrap binary 'guile-2.0.9.tar.xz' for system 'x86_64-linux'' <marusich>is guix still usable after the error occurred? did it update the symlink at ~/.config/guix/latest? (you can check with 'stat ~/.config/guix/latest' and checking the mtime; if it isn't recent, it didn't flip the symlink) <CompanionCube>my regular user's ~/.config/guix/latest has the mtime of my last guix pull for that user <marusich>If the symlink's mtime is unchanged, then probably your Guix installation is still usable, since nothing was changed. <marusich>As for why it failed, do you have any more information? For example, the exact command you invoked <CompanionCube>if i run 'guix pull' or 'guix package -u' as my non-root user, I get the error <marusich>Ah, well...perhaps you "guix pull"ed into a version of Guix that is broken. <marusich>Make note of the value of readlink ~/.config/guix/latest <CompanionCube>am i unluckyy with the timing and have two different versions that disagree on what the bootstrap binaries are? <marusich>Save it somewhere. Then try doing "ln -sfn "$(readlink ~root/.config/guix/latest)" ~/.config/guix/latest" <marusich>That command will flip the symlink ~/.config/guix/latest to point to whatever your root's latest Guix is pointing to. <marusich>If you want to revert to using the old one, just do "ln -sfn $the_old_one ~/.config/guix/latest" <marusich>If you do that, then Guix ought to work, since root's Guix installation is working. <marusich>As for why it happened to you, I'm not sure. It is possible to run "guix pull" and wind up with a broken Guix installation, which is a huge bummer. <marusich>There is no easy way to roll back when that happens, yet... The best you can do is record the original symlink and flip it back manually <marusich>However, you might also be interested in knowing that "guix pull" allows you to specify arbitrary commits or URLs from which to pull, which makes it easier to get back to a working version if something bad happens. <marusich>Apteryx, I feel like I'm missing something obvious with Magit. When I press "M-x magit-status", followed by "l", the popup screen makes it look like I can select arguments, such as --graph. <marusich>But I can't figure out how to select them. Do you know how to do that? <marusich>I didn't realize the switches were changing color when I was pressing them........ <marusich>CompanionCube, FWIW, I just ran "guix pull" as an unprivileged user, and successully switched to using Guix from commit e2d0cf033eb894fa8c786d0bf039fc54685d5559. I'm building GNU Hello as a test to make sure it works, and so far there are no errors like the one you mentioned. This is on an x86_64-linux GuixSD system. <CompanionCube>marusich: maybe it's just down to me not updating user guix since january :p <snape> (define-public global ; a global variable <civodul>snape: yes it's better to keep what "guix lint -c gnu-descriptions global" gives you <civodul>and, ideally, if you think that description is bogus, submit it to the Womb <civodul>or pass it to me and i can commit it there <civodul>but no, rather submit it yourself so we don't have a bottleneck :-) <snape>Well, they probably purposely don't add GNU prefix to the GNU package names... <snape>which makes sense if all of them are GNU projects, but with Guix most softwares aren't GNU projects. <civodul>right, but global is the 2nd answer to "guix package -s code -s tagging" <civodul>which is more important than having or not having "GNU" in its description i believe :-) <snape>GNU Womb. "A collective repository for random code that isn't ready to become a seperate GNU project, or intends to be merged with an already existing GNU project." What's the point of GNU projects being there? <civodul>there's a couple of files there containing metadata about GNU packages <civodul>but yeah, that's just administrative stuff that has no better place <jboy>rekado: will do - on a different machine right now. <snape>civodul: I sent an email to the Womb :) If it's refused, I'll revert my commin in Guix. <thorwil>snape: got things working with (bootloader (bootloader-configuration (bootloader (bootloader (inherit grub-bootloader) (installer #~(const #t)))))), thanks! <thorwil>that is, mostly working, because grub took hd0 to be sdb one time, then a reboot later it was hd1 0.o <snape>thorwil: there are different way to refer to drives. You can use UUID I think, they don't change. <snape>the problem being that if you change your drive, you need to update your config :-) <wigust>Hello Guix, Could I cannot get a ‘gcc-lib’ PACKAGE in ‘guix environment’ with ‘(inputs `(… ("gcc" ,gcc-7 ("lib")) …))’. ‘guix package -p $GUIX_ENVIRONMENT -I’ doesn't show ‘gcc’ with output ‘lib’ (also no any other package output). I need a ‘/gnu/store/…-gcc-7.3.0-lib’ package in ‘guix environment’. <wigust>In other words I want ‘libgcc_s.so.1’ in the ‘$GUIX_ENVIRONMENT/lib’. <civodul>wigust: "guix environment --ad-hoc gcc:lib ..." no? <wigust>civodul: I use ‘--load=guix.scm’ <wigust->civodul: Thank you, but in my case it's a workaround, because I use ‘--load=guix.scm’. Cannot I get a ‘gcc-lib’ in ‘guix.scm’? <wigust->OK, ‘guix environment --no-grafts --load=guix.scm --ad-hoc gcc@7:lib’ works for me (the order of flags is matter, because ‘guix environment --ad-hoc gcc@7:lib --no-grafts --load=guix.scm’ doesn't work). <civodul>wigust-: if it doesn't work when you add it to your guix.scm, can you report it to bug-guix? <g_bor>I've found out how to fix rekado's patch on python to not break tests. <thorwil>is there a general approach to add/change/delete lines from configuration in /etc (or ~)? my first example would be "set bell-style none" in /etc/inputrc (which doesn't exist, yet)? <civodul>thorwil: to add a file to /etc, you need to "extend" etc-service-type <civodul>i think the manual has an example for that <rekado>g_bor: great! What does the change look like? <rekado>unfortunately, I’ve already been building hundreds of packages with that change. <g_bor>Actually it goes like that make the change in the importlib to also depend on 'DETERMINISTIC_BUILD'. <g_bor>However it seems to me, that something is wrong here... <g_bor>It seems that with the bytecode manipulation stuff it is actually possible to create modules not respecting 'DETERMINISTIC_BUILD'. Is it possible that for example numpy does something like that, and that's why it is not reproducible? <civodul>i wonder why our GitHub updater is so often unhelpful <civodul>for instance, "guix refresh arpack-ng" does nothing <g_bor>civodul: I'm now browsing the bugtracker, and we have #19599 won't fix, it is an strace bug. It has a notice at the and, that upstream should be contacted. Do you know if it is fixed upsteam? <g_bor>It was fixed in strace v4.8. We now have 4.21. We can close this bug, upstream fixed it. <civodul>really appreciated when someone helps with bug triage <ng0>hey.. I just found that a new, just building, version of a build symlinks to the oldest version (foo-0) in /tmp/ instead of its own (foo-14) root <ng0>is this a known issue? has anyone experienced this before? <mange>The build always uses -0 in the build container, but then if you use --keep-failed it's put into a numbered folder. <rekado>g_bor: it seems wrong to me to make more things in the bytecode validation depend on the runtime environment. <rekado>I think it is not correct to make validation behaviour dependent on the user environment. <rekado>generating deterministic bytecode, however, is something that should be dependent on the environment, because people may build bytecode in projects that are not covered by Guix. <rekado>when building with Guix we can trivially set this environment variable, so it’s not a problem. <rekado>I feel that maybe we should leave the patch as is, although this entails disabling three tests. <g_bor>rekado: In fact it seems that there is some mechanism in these tests, a module is created there on the fly, and thus failing the test. The module there is in fact created when we have 'DETERMINISTIC_BUILD' unset already. <g_bor>I still feel that disabling the tests is safe. <g_bor>However this points to a possibility, that we can still create .pyc-s where 'DETERMINISTIC_BUILD' is not respected. <g_bor>This might be responsible for the remaining problems. <rekado>that’s why we’re recompiling all .py files at the end when DETERMINISTIC_BUILD is enabled again. <rekado>for some reason this still leaves about 500 pyc files that are not deterministic. It’s possible that they were generated earlier (and maybe they should be removed before rebuilding all py files). <rekado>civodul: IT just confirmed that they have no additional restrictions in the firewall that would affect SSH connections between overdrive1 and berlin.guixsd.org. <civodul>i figured a while back the problem was in the offloading code <rekado>only took them a few weeks to reply :) <civodul>the code is "mostly" fixed, but not 100% it seems <civodul>on berlin we still see deadlocks in the head/build machine communication <efraim>I was going to say you could just throw up your hands and use tor, no networking problems then <civodul>actually having Tor running is a good way to work around local networking issues <civodul>because it always finds its way out :-) <ng0>except when the tor network is being attacked again.. happens very often. so network can be annoying, but it works <ng0>in any case proxy enabled offloadimg, donwloading (not just substitutes etc) would be a great benefit <ng0>speaking of which.. a friend brought up the lack of a field for "recommended runtime dependencies" and since my torbrowser requires a running tor (you will get to the testpage saying "you don't run tor!") with a control port, do we just point it out in the description like always or could we just extend the fields? <ng0>not just for this package, but think of the many optional runtime dependencies of mc etc <ng0>after a certain number of years you just know what you need, but newcomers won't figure it out that easy <ng0>when I write "fields" I just mean what'S being returned by the package search <ng0>technically incorrect, let's just pretend I wrote "more metadata" <efraim>I like Debian's 'provides' field, 'oh, you need X? Take one of these 3' <rekado>with Tor it’s different. You’d use the tor-service, not juts a package. <mfiano>Is it as much of a pain to get a Common Lisp development working with Guix as it is with Nix? <mfiano>Particularly a Common Lisp image being able to locate foreign libraries and such <ng0>right.. but the simple statement "requires: tor" in a package search would tell people: Aha! I need tor for torbrowser. just as an example. <ng0>or maybe even tor (service) <rekado>ng0: isn’t that exactly what torbrowser shows when tor is not available? <ng0>where (some comment) <ng0>I picked the wrong example <ng0>the persons point was, Debian's "recommended" is good, and is something Guix is missing <rekado>mfiano: I don’t know how “much of a pain” this is in Nix, nor do I know if it is painful in Guix, as I’m not a Common Lisper. <ng0>efraim: but the 'recommended' is different than the 'provides' <rekado>ng0, efraim: they are related in that you could recommend “some browser” and icecat, epiphany, eolie … all provide “some browser”. <rekado>the point is that this is not necessarily at the package level <ng0>I disagree, but I never mentioned the package level explicitly. All I was told is that the package search output could be improved by adding something similar to Debian's "recommended" <rekado>we have already moved on from that suggestion <ng0>so it's no problem because you personally don't see a problem? <ng0>or was this discussed in the past? <civodul>ng0: i think the point is that a Debian-style "recommend" in the case of Torbrowser would need to recommend a service, not a package <thomassgn>Curious about something: I'm continuing on making a package inherit from another and want to change the arguments field. First I couldn't find any documentation for '(package-arguments package)' and now I see everywhere in the guix sources it is preceded by '(substitute-keyword-arguments ...)' which I also can not find in the docs for either guix or guile. I'm going to look through the guix sources for it, but <thomassgn>is this simply missing documentation, or is something else going here? <efraim>I don't think it's explicitly documented, I normally grep for substitute-keyword-arguments when I need to add another one <thomassgn>I see there is a docstring (is that the right word in guile/scheme/lisp?) in the define-syntax procedure for substitute-keyword-arguments also, it's _very_ concise. :) <snape>thomassgn: yes, it's the right word <thomassgn>Wow, I wish we were taught C and not C++ with a focus on object orientation at school... Sooo much to unlearn... :} <rekado>ng0: you misunderstood. I meant that the we understood the suggestion already; we just went beyond that initial suggestion and discussed what a “recommendation” would need to map to. <rekado>I didn’t say that “it’s not a problem for me, so end of discussion”, and I think that’s a rather uncharitable reading of my comment. <ng0>your reply was rather short, which didn't help it. thanks for clearing that up <bavier`>I'm having trouble upgrading my system from wicd to network-manager, NM can't find my wireless interfaces <bavier`>thekyriarchy: `ifconfig -a` shows them <thomassgn>and they are UP? don't remember the ifconfig command for it but 'ip link set up DEVICE' I think it is will do the trick. <thomassgn>you could also check rfkill -list (from package rfkill) <bavier`>yeah, I tried putting them UP, but didn't help. <bavier`>wicd never required they be up before connecting <thomassgn>bavier`: sometimes weird things happen with hard blocking, check rfkill. But it is not so common. <bavier`>thomassgn: ok, thanks, I'll try that <thomassgn>that's about as far as my troubleshooting skills go in the wizardry of wireless :P <fractal>is there a source for the raw iso file available anywhere? <fractal>i can't figure out how to get the iso out of the xz compressed file <roptat>fractal: xz -d guix-….iso doesn't work? <fractal>i'm probably in over my head trying this since i'm mostly a GUI user. i tried extracting it in Nautilus but got an error <fractal>was going to try to run it in a VM if i DID get the iso out <rekado>fractal: what are you trying to do? <rekado>test GuixSD (the system distribution) in a virtual machine host? <fractal>i'm used to downloading raw ISO files <rekado>note that this is not how to install GuixSD on hardware. <rekado>so you downloaded the qemu image? <rekado>you’ll only need one to run the pre-built VM image. <fractal>heads up: i am mostly a mint/ubuntu user <fractal>starting to realize this is a bit too deep for me i think :( <rekado>no worries, we don’t discriminate against beginners :) <rekado>I haven’t used GNOME Boxes (successfully) before. <wigust->fractal: It's not hard as long as you follow the documentation <fractal>ACTION found the same with Arch in the past. not hard if following documentation at all <fractal>excessive command line and editing config files isn't exactly my style though <fractal>ACTION will look over these pages and decide how/if he wishes to continue, and if this is something he wishes to continue <bavier`>fractal: thanks for giving Guix a try <rekado>fractal: you’re welcome. Maybe you’ll come around to it one day – or maybe GuixSD will become easier to try out. <fractal>in a world of distro after distro where everything feels the same, i can say that this one really stood out to me when i read about it <fractal>and yes, those help pages allowed me to extract the iso. (i was doing it wrong, and assumed there wasn't specific documentation for it. derp!) <thomassgn>fractal: Been there, I remember a period when I was changing distro approximately once a month. <thomassgn>if you do want to try a commandline and config-files heavy distro I would recommend GuixSD (or maybe NixOS, samey but different - GuixSDs precursor). And remember that learning to be comfortable in a commandline can be time consuming but also incredibly rewarding in terms of understanding and suddenly so much more becomes accessible in this world of free software (and ironically I found, in nonfree also)... :) <wigust->We have an Emacs interface for Guix BTW <rekado>I get a syntax error when using “guix challenge” <rekado>I get: “Wrong type to apply: #<syntax-transformer uri?>” when running “guix challenge python-pandas” <rekado>hmm, works with ./pre-inst-env ¯\\_(ツ)_/¯ <rekado>must be something wrong with my GUILE_LOAD_PATH <ng0>did someone mess up cryptsetup? I haven't rebooted in a while, but it shouldn't reject usb harddrives I have.. <ng0>hn different port, worked <efraim>how do I print the uuid of my drives/partitions? lsuuid doesn't seem to be a thing <rekado>libffi is not reproducible and wrongly installs files into $out/lib/gnu/store/… <thorwil>i take it i can ignore the collisions and randomly choosing messages. <thorwil>but i also got to see: shepperd: service user-homes could not be started <efraim>user-homes is a one-off job, it creates the user home directories and only runs if it needs to change something <thorwil>i have root plus one user since the first config. this would suggest shepherd shouldn't even try to start user-homes, then, right? <efraim>i hate when I run find on the store and all I get back are matches from bash-completion <efraim>as far as i understand user-homes, yes (I haven't looked at the code for it yet) <thorwil>what happens to a /home/bob if bob is dropped from the configuration? <atw`>good to know, I'd wondered about that <efraim>do we have commands for suspend or hibernate? <atw`>efraim: loginctl suspend if memory serves. Not sure about hibernate but maybe it's likewise <thorwil>bavier`: but shouldn't everything in a homedir and itself (except things a user added manually) be part of a generation? <dustyweb>hey catonano! I'm at rebooting web of trust <guile-guest3>Hi all, guile has mysteriously stopped working on my guixsd machine. When I run guile it says "guile: warning: failed to install locale" and then a variety of other stuff, which I'd be happy to paste here <efraim>working on the enlightenment-service, #$enlightenment/lib/enlightenment/modules/cpufreq/linux-gnu-x86_64-0.22/freqset is supposed to be setuid <guile-guest3>I noticed this during a "sudo guix pull", but i'm not sure if it was broken before. It has persisted after the command finished and after I run "sudo guix package -u" <Sleep_Walker>efraim: that is right, they use setuid bits for their helpers <efraim>i know, just not excited to generate the linux-gnu-x86_64-0.22 portion <mbakke>Ooh, Ceph has been building on armhf for 12 hours now. <catonano>it's been on my rreading list for a very long time now :-/ <catonano>I searchd it and didn't find it but maybe I did something wrong ? <catonano>I did guix package --list-available | grep flyspell <rcm>civodul: Hello from guile. Sorry, I wasn't sure if it was a guile or a guix problem initially. So the general order of update commands you use is "sudo guix pull" then "guix pull" then "sudo guix system reconfigure "? <rcm>Just given how long a "guix pull" command takes to execute I want to make sure I'm not being redundant by running the root command and the non-root command <vagrantc>you don't actually need to update root's copy of guix <vagrantc>unless you're installing programs just for the root user <rcm>vagrantc: So as long as all of the root user's necessary programs are in the config.scm file, you never need to run "sudo guix pull"? <bavier`>vagrantc: rcm is doing a guix system reconfigure <thorwil>i did "guix system reconfigure" as non-root once, accidentally; after all the work, it ended with the failure of setting some symlink <rekado>thorwil: the work was not in vain, though <rekado>(as long as the version of Guix for the current user was current) <rcm>What exactly is happening when I run "guix pull"? It spends a lot of time compiling stuff. Is building a.) every program available to guixsd. b.) every program that the user has installed (not including those that are in the config.scm) c.) every program that is in config.scm or that the user has installed. or d.) something else entirely <rcm>rekado: I suppose this is a stupid question, but what exactly is "Guix"? If I have a different config than you do, and we both run "guix pull" will we both be compiling the same exact thing? <rekado>Guix is a collection of Guile modules. <thorwil>"guix pull" is updating that which does not depend on configuration(?) <rekado>many of these modules contain package definitions as Scheme variables. <rekado>these variables can reference other variables in other modules lazily. <rekado>the result is a big lazy graph of Scheme variables. <rekado>to make runtime traversal and computation on the graph faster we compile these modules to bytecode. <rcm>So for a single-user computer, is there any way for me to avoid duplicating work when running "sudo guix pull" followed by "guix pull"? <bavier`>rcm: `sudo guix system ...` like vagrantc mentioned (which I often forget) <vagrantc>guix pull && guix package -u && guix system build /etc/config.scm && sudo -E guix system reconfigure /etc/config.scm <vagrantc>you could maybe skip the guix system build step, but doing it that way makes the reconfigure go very fast <rcm>So do you never need to run "guix pull" as root or does a "guix pull" happen implicitly during the "sudo -E guix system reconfigure /etc/config.scm" part? <wigust->rcm: ‘guix pull’ just creates a symlink ‘~/.config/guix/latest’, nothing more. <bavier`>rcm: the -E flag ensures that your guix is executed rather than root's <rcm>Sorry for beating a dead horse, but I still don't think I quite understand (but I think I'm getting close. This has been very helpful!). Does creating the symlink '~/.config/guix/latest' have any effect on the root user? <vagrantc>ACTION admits it's all kind of confusing <vagrantc>ACTION still in the toying with guix phases <rcm>thorwil: So how will the root user be using the latest version of guix without running 'guix pull' as root? <wigust->rcm: every user (including root) should have ‘~/.config/guix/latest’. Using ‘sudo’ mechanism you could preserve your Bash environment variables, for example to use your user's ‘~/.config/guix/latest’ instead of root's ‘~/.config/guix/latest’. <thorwil>is it this way: no matter the user (including root), guix pull will fetch and build the latest available, if necessary, then set ~/.config/guix/latest? <rcm>I have to run, but this has been incredibly illuminating. I know that guixsd is incredibly modular and applies to many many usecases, but perhaps the manual could use a 'best practices' section where things like basic system maintinence are outlined for a typical user <rcm>thank you all so much for the valuable information <wigust->rcm: best practice is to ‘pull’ for each user, but you asked for a specific case :-) <wigust->thorwil: no matter the user, but it will pull and build even if not necessary as I know 
