IRC channel logs

2020-03-01.log

back to list of logs

<noobly>lfam: still no luck, I'm wondering if the fact that I don't have a /bin/env file may be to blame?
<lfam>What do you mean by no luck? Where does it break?
<noobly>well, guix system updates with the new config just fine, but the problem of npx returning '/usr/bin/env: command not found' persist
<lfam>Does /usr/bin/env work?
<lfam>I mean, does it exist?
<lfam>Beyond that, what command is /usr/bin/env trying to find?
<noobly>No, I have no /usr at all
<lfam>Okay, so then it didn't work
<lfam>You did `guix system reconfigure /etc/config.scm` and rebooted?
<noobly>No! I didn't, just `guix system build /etc/config.scm` and no reboot
<noobly>should I do that now?
<lfam>Okay, the build subcommand only builds the new system. Reconfigure actually makes it effective and then rebooting is required to fully switch obver
<lfam>over
<lfam>Yes, you should do that now
<noobly>ah, ok. I
<noobly>*I'm going to have to sit down and read the docs tonight. I was just hoping to get some NodeJS stuff done on this machine today. But thanks I'll run those commands and reboot now
<lfam>Okay
<daviid>nly: are you the author of the bug report about g-golf not building with guix?
<str1ngs>daviid: I have a package declaration for g-golf if anyone needs it.
<daviid>str1ngs: right, i was goingi to mentn this
<str1ngs> http://git.savannah.nongnu.org/cgit/nomad.git/tree/guix/gnu/packages/g-golf.scm?h=feature-windows
<str1ngs>do you have a link to the bug report?
<daviid> https://lists.gnu.org/archive/html/bug-g-golf/2020-02/msg00000.html
<str1ngs>ah this is nly
<nly>daviid yes
<str1ngs>daviid: it's probably related to the cannot register existing type 'GdkPixbuf' issue
<str1ngs>which I still have not tracked down.
<str1ngs>GdkPixbuf is random it can happen with other types as well. #introspection suggested that a library is being loaded twice.
<str1ngs>and this only happens on guix, other distro are not effected by this
<daviid>str1ngs: ah ok
<str1ngs>I'm going to be out for the evening. but if you guys need me to test anything. I'll be back later in the night
<daviid>nly: make check pass here, it seems a weird 'guix' or 'guix infrastrucutre' related bug
<daviid>str1ngs: ok, made good progress on <closure> and how the mashaler will have access to detailed argument info/des to 'decode' those arrays in general, arrays of iterfaces in particular, wil ping on #guile
<nly>thanks
<daviid>nly: out of curioisity, did you register to bug-g-olf or not?
<nly>daviid: did not
<nly>but i guess i should
<daviid>ok, it's to avoid spam that i request to do so, but then i receive an admin mail telling me I should visit https://lists.gnu.org/mailman/admindb/bug-g-golf, but then there there is nothing ... i wonder why
<daviid>nly: while g-golf is under such extensive development, I suggest you may as well ping me here or on #guile
<nly>that makes sense. Thanks daviid :)
<str1ngs>daviid: okay thanks for the update, will be back later in the evening
<daviid>str1ngs: welcome
<nly>subscribed to bug-g-golf@gnu.org
***jonsger1 is now known as jonsger
<guix-vits>Hi Guix.
<daviid>nly: ok great, if you have any question, or suggestion, don't hesitate to ask or suggest :), if 'purely g-golf', preferably on #guile
***wxie1 is now known as wxie
***wxie1 is now known as wxie
***wxie1 is now known as wxie
<leoprikler>daviid, nly: The GdkPixbuf issue can be worked around by suffixing GI-related environment variables, which makes the ones your DE actually uses take priority.
<leoprikler>I think this is causes by conflicting libraries – e.g. you link to /gnu/store/some-hash-gtk-some-version, but /gnu/store/some-other-hash-gtk-some-version is actually in use.
<str1ngs>leoprikler: setting GI_TYPELIB_PATH does not seem to help. but it could be order dependant
<leoprikler>It certainly is. Try changing the polari package ;)
<str1ngs>also disabling this patch http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/glib.scm#n394 definitely fixes but that's less than ideal.
<str1ngs>I suspect what's happening is there are two typelibs being used that use different store paths for libraries. but I have not figured out how to text that
<str1ngs>s/text/test
<efraim>is there a way to re-read the shepherd init file while it's running?
<rekado>“guix gc” does not free any space on ci.guix.gnu.org even though it claims to have freed space.
<NieDzejkob>efraim: Hmm, how does `guix system reconfigure` activate the new services?
<efraim>NieDzejkob: IIRC only if the service isn't active at the time of reconfiguring
<efraim>I meant more for when running shepherd as a user
<janneke>efraim: and `reload' is not what you want?
<efraim>herd reload root?
<janneke>yes, i think so
<efraim>looks like its 'herd reload root /path/to/init.scm'
<efraim>stops and starts everything, so pretty close to what I was looking for
<efraim>looks like I should look more into using multiple files
<janneke>you only want services that changed to be stopped and started?
<janneke>or even just variable values changed in-place?
<efraim>good question. I guess I want the running services to continue running and the service definitions to be the new ones if I start or restart any of services
<janneke>ah, yes i see
<janneke>makes sense, that sounds like a useful feature
<g_bor[m]>rekado: are you around?
<raghavgururajan>Hello Guix!
<raghavgururajan>Folks! If you have time, please share your thoughts regarding this: https://lists.gnu.org/archive/html/guix-devel/2020-02/msg00341.html
<g_bor[m]>raghavgururajan: the way I see it is that currently guix has limited modularization possibilities because of limitation in the module structure we are using.
<raghavgururajan>g_bor[m] I see.
<g_bor[m]>Flexibility could be gained with a one service per module approach, but according to earlier reports this leads to performance problems, at least with the packages. It would worth investigating if the guile3 transition makes it possible to increase modularity, and if not what can be done with the guile module system to improve it.
<raghavgururajan>g_bor[m] The implication is critical right? I was wondering if we could make that priority.
<raghavgururajan>I see.
<NieDzejkob>Perhaps the cause of the performance problems in guile should be investigated?
<rekado>g_bor[m]: what’s up?
*rekado still waits for “guix gc --optimize” to terminate on ci.guix.gnu.org
<efraim>I borrowed from (guix build utils) and now I can load files into Shepherd from a subdirectory. I might try to make it less complex though, find-files is a bit overkill
*janneke successfully built on hurd: /gnu/store/k75d6s6f84szrnz178zka5zr9rnpizc0-gcc-cross-boot0-7.5.0
<janneke>i thought we were waay past this? :-( ...but it seems we need less patches than ever :-)
<g_bor[m]>rekado: it's just I have seen the problems you were facing on berlin, and wanted to ask how I could help.
<rekado>g_bor[m]: I don’t know. Something seems to be wrong with “guix gc” on ci.guix.gnu.org. It seems to have no effect. And it’s terribly slow.
<rekado>I can’t really commit more time to this today.
<g_bor[m]>rekado: do we have any free space right now? I have a little time to look around now.
<rekado>37TB of 37TB are in use on /gnu
<rekado>zero bytes free.
<rekado>despite running “guix gc -C 4G” successfully.
<efraim>is it mounted read-only or something strange like that?
<rekado>no
<rekado>guix gc --optimize is running since about … two hours, but it doesn’t seem to do anything.
<g_bor[m]>I will have a look, and write my findings on sysadmins, so someone can take over.
<rekado>(according to strace)
<rekado>g_bor[m]: I’m running “strace -f -o gc-log -s 1024 guix gc -C 4G” right now, so next thing you could do is to take a look at “gc-log” to see if there’s anything interesting going on.
<g_bor[m]>Ok, that would be my first attempt also after having a look at the daemon log. I will report back soon.
<janneke>ah, and i found why building 'hello' hangs -- sigh / :)
<janneke>"someone" could maybe write a circular dependency exception
<rekado>so… “guix gc” prints “finding garbage collector roots...” and then is stuck in “read”
<rekado>janneke: cbaines had something like that
<janneke>nice, /me wants
<roptat>oh, not sure if it's a guile or a guix packaging issue: our guile-next comes with a guile.m4 that defines GUILE_PKG, which I use to detect the presence of guile. However, guile-next only checks for guile 2.2, 2.0 and 1.6, so my configure script fails
<roptat>1.8*
<rekado>g_bor[m]: I just deleted a big old file in /gnu/foo in the hopes of avoiding guix gc problems due to a complete lack of space.
<Desmes>Hey people. If there are developers here, first I want to say thank you for this amazing piece of software (and documentation).
<Desmes>I have a small qurestion though, I've rolled back a couple of generations of my Guix system. Is there any way to get the config file I used for this generation?
<roptat>try to look at /run/current-system/provenance if it exists
<roptat>it should have a reference to a configuration.scm in the store
<roptat>however, it's a recent addition, so if you rolled back to before it was added, there's no way for you to get the configuration file for that generation
<g_bor[m]>rekado: I see the bit of free space now that you created.
<rekado>g_bor[m]: sorry, watching the log wouldn’t help, because the work happens in guix-daemon…
<roptat>I get 502 from berlin, I suppose it's related to the free space issue?
<g_bor[m]>Are you running any gc right now?
<rekado>gotta attach strace to the guix-daemon process, which is in fact reading lots of stuff.
<rekado>yes
<rekado>the above command is still running
<rekado>brb
<Desmes>roptat it was yesterday. There's no "provenance" file there though, can it have a different name?
<g_bor[m]>ok, I will wait until it completes.
<roptat>I don't think so. its presence depends on the guix commit, not when you rolled back
<nckx>Desmes: /run/current-system/configuration.scm?
<roptat>ha! I didn't see it ^^"
<Desmes>roptat: I mean, yesterday I run "guix pull" and "guix system reconfigure ..." so I must have a recent Guix version.
<Desmes>nckx: Here's what I have in there: boot, etc, initrd, kernel, locale, parameters, profile
<roptat>what matters is the version of guix you used to build the *current* system, so if you rolled back, you're on a system that's older than yesterday ;)
<roptat>but if you want the configuration file you used yesterday, you can find it: /var/guix/profiles/system-n-link/configuration.scm (where n is the biggest number you can find)
<Desmes>roptat: The version of Guix I used to build the "current" system == The version of Guix I had yesterday (after running "guix pull", before doing "guix system reconfigure"). Or I am mistaken?
<roptat>if you are on the latest generation of the system, you are right, unless something went wrong with the reconfigure (maybe it didn't use the correct guix?)
<roptat>but if you rolled back, your current system is an older one
<nckx>Desmes: No, you rolled back to an older system (which is now ‘current’). Which was built with an old guix. Which doesn't contain the ‘copy the configuration to /run/current-system’ code.
<Desmes>I rolled back to the version of my system I had yesterday, though.
<nckx>Mmm.
<g_bor[m]>rekado: I've set up a notification to see when the gc finishes.
<g_bor[m]>I will check what's up after that.
<janneke>grrr: Fatal Python error: Py_Initialize: can't initialize time OSError: [Errno 1073741846] Invalid argument
<janneke>
<janneke>why oh why do we now also have Python in our bootstrap
<g_bor[m]>Btw I see a few defunct mcron things. Is it possible that the gc job was broken again?
<nckx>Desmes: I've ssh'd into a system that isn't mine and /run/current-system/{provenance,configuration.scm} are definitely not a me-thing. They exist here too. Just to be sure: what does ‘command -v guix’ return? And sudo sh -c 'command -v guix'?
<nckx>janneke: glibc? Or has that not hit us yet?
<janneke>nckx: yeah, pretty sure that's it
<Desmes>I've checked all (three) the versions of /var/guix/profiles/system-n-link/config.scm and none are the current config.scm that I'm running, they are "newer"
<nckx>janneke: Bluh.
<janneke>nckx: glibc-final-with-bootstrap-bash
<nckx>-and-python.
*nckx must go o/
<janneke>o/
<janneke>TBH, there has been a time that i thought python was much easier than guile
<Desmes>nckx: both commands yield: "/home/main/.config/guix/current/bin/guix"
<janneke>aaargh, how do i download a patch/commit from github
*janneke tries hovering over all kinds of texts in the hope to get a "finger" icon or title saying "raw" or something
<nckx>janneke: Add .patch to the …/<commit hash> URL.
<janneke>*much* prettier colors than debbugs, though
<nckx>Now I really gots to go.
<g_bor[m]>if you go to the commit, and add .patch to the end of the url it should downalod a patch
<janneke>nckx: \o/
<g_bor[m]>:)
<g_bor[m]>nckx: fast as always :)
<alextee[m]>guix substitute: error: download from 'https://ci.guix.gnu.org/nar/ij9zdxmwrjhf4sy4cw3xyq48143cd1jh-ffmpeg-4.2.2.tar.xz' failed: 502, "Bad Gateway" ?
<janneke>g_bor[m]: i appreciate your answer a lot too :-)
<janneke>the python problem is probably fixed in python 3.8, but we cannot use those as they need pthreads
<janneke>why does nobody in this world care about bootstrapping?
<rekado>alextee[m]: please try again
<rekado>hmm, I restarted the guix-publish, nginx, and cuirass-web services, but I also get the timeout
<rekado>restart nginx again…
<rekado>works now
<rekado>guix-publish must have stopped working when we ran out of space
<g_bor[m]>janneke: I believe this is because it is hard to be considerate, and it is simply convenient not to do the right thing. I believe that raising awareness and giving tools to check if they don't break bootsrap might lower the burden to get into this mindset. What so you think?
<janneke>g_bor[m]: i like to think it's an awareness issue, yes...
<alextee[m]>rekado: works now, thanks
***OriansJ`` is now known as OriansJ
<rekado>g_bor[m]: “guix gc” is now actually deleting things.
<rekado>I don’t have that many jokers left to clear space in emergencies like this.
<rekado>so it would be great to avoid problems like this in the future.
<g_bor[m]>rekado: nice.
<rekado>I’ll keep checking this throughout the day to make sure we end up with at least 1TB free.
<g_bor[m]>In the meanwhile I was inspecting how could we get data from zabbix without the frontend.
<g_bor[m]>I can't get to the server data, but the agent is inspectable from the command line.
<g_bor[m]>it looks like that the /gnu filesystem is not monitored. I can only find filesystem info in zabbix from /
<g_bor[m]>But I might be wrong...
<valignatev>Hey guix o/
<valignatev>How do I make applications that I've installed with guix respect global DPI settings?
<valignatev>I set dpi with xrandr --dpi and in ~/.Xresources
<valignatev>At the start of the X session
<valignatev>All applications installed with pacman respect this setting, but those coming from guix don't - I can see it when I hover my mouse cursor into the window - it immediately becomes smaller as if there wasn't any scaling.
<valignatev>So it looks like the old font antialiasing issue I had a while ago that I was able to solve by symlinking my system fontconfig into the ~/.config directory. Is there a trick like that to make guix-based apps find out about the DPI?
<bandali>leoprikler, i think apteryx was
<leoprikler>Yeah, IIRC they already figured it out before your reply.
<bandali>ah
<bandali>right
<leoprikler>something weird about %standard-phases being taken from the wrong place if I'm not mistaken
<valignatev>Hm, does guix sandbox application somehow so they don't see global settings like DPI? Still can't figure out why guix-installed apps don't respect my DPI settings
<roptat>how are they supposed to learn about that global setting?
<shtwzrd>a guix-installed app should still read your ~/.Xresources. Are you sure this isn't an app-specific issue?
<guix-vits> https://wiki.archlinux.org/index.php/HiDPI -- hope it isn't off-topic
<valignatev>roptat: I set them up with xrandr --dpi in my ~/.xinitrc and in ~/.Xresources and it gets set during the startup. All applications that I've installed with pacman respect the option, but those that installed with guix ignore the settings.
<valignatev>I run my wm with startx after login
<valignatev>I'm using guix on top of Arch
<shtwzrd>valignatev: Have you tried with the exact same application? Like, GTK emacs on arch and GTK emacs via guix?
<valignatev>Yes, I did
<valignatev>Installed with pacman works, installed with guix doesn't
<valignatev>I mean, emacs installed with guix works, it just doesn't scale according to my dpi settings. It seems that apps installed with guix are somehow sandboxed from seeing dpi settings. I don't really know how to even debug that :)
<roptat>I don't really know graphics stuff, but I suppose an application has to look somewhere to find the dpi settings, right? xrandr must set some option somewhere, and the guix application is not looking at the right location or something
<valignatev>I've naively tried to run xrdb -query | grep dpi from within emacs, and it returns the correct number, but I'm like 99% sure that it's not how the apps look this up
<shtwzrd>with emacs, what it will respond to is going to depend on how it was compiled, iirc. Plain X/motif emacs would get dpi settings from your Xresources. But I think GTK compiled emacs uses some GTK specific dpi setting somewhere else
<valignatev>GTK itself should grab the settings if it doesn't see GTK_SCALE (I don't remember exactly how it's called) env variable
<valignatev>But the problem isn't just with GTK applications.
<valignatev>Alacritty has the same problem, and it has nothing to do with gtk
<shtwzrd>Hm. It is at the very least not a general problem with loading your .Xresources or other config files from ~. Like you saw in emacs, xrdb was returning the right values. I wonder, if you change the value in your .Xresources, is it even affecting the pacman-installed applications?
<shtwzrd>I'm thinking we have to be looking at the wrong places to be setting DPI for the given applications. But if the pacman-installed versions of the same applications are responding to your changes then that wouldn't make sense.
<NieDzejkob>I'd grep for GTK_SCALE or whatever in gtk's codebase and then look around
<valignatev>shtwzrd: Yeah, pacman apps respond to changing dpi there
<shtwzrd>valignatev: ok possibly dumb question, but are you doing all this on the same monitor?
<shtwzrd>and second dumb question: are you remembering to do xrdb -merge ~/.Xresources before launching the guix packaged apps?
<valignatev>Sure, the same monitor (my laptop monitor). It's WQHD monitor on Thinkpad T480s. So I have resolution of 2560X1440 and I set DPI of 150
<valignatev>Yep, I source Xresources in my ~/.xinitrc at the start of the X session
<valignatev>With xrdb -merge
<valignatev>So xrdb -query | grep dpi returns the correct value
<shtwzrd>I'm afraid I'm stumped, then. :/ It does sound like there's something fishy specifically with DPI settings.
<valignatev>Hm. It doesn't look like it's something wrong with GTK specifically either, because the same issue exists with QT apps, and with plain X windows that don't use any ui toolkit
<shtwzrd>It is only the DPI setting that seems to be ignored though, right? Like if you specify Emacs.font:, guix-installed emacs honors it, right? (It does for me, and I'm also running on a foreign distro)
<valignatev>I don't set emacs font in ~/.Xresources, I set it in emacs directly, but might as well try it out. How do I set Emacs font in xresources?
<shtwzrd>something like "Emacs.font: Inconsolata LGC:size=14"
<shtwzrd>You don't even need to make sure it's a font you have, if you don't have it and you launch emacs from the commandline, it'll complain about not having the font and that'd be proof enough
<valignatev>Yeah, it definitely tries cuz I get "Font ‘Inconsolata LGC:size=14’ is not defined"
<shtwzrd>ok, cool :) Then it's definitely specific to the DPI setting. Unfortunately I got no idea why though.
<shtwzrd>Well, one last shot in the dark: when you launch the pacman-installed application, how are you doing it? Are you just launching straight from the command line?
<shtwzrd>(I'm wondering if maybe when you're launching from a .desktop entry or something, maybe it could be supplying some arguments or setting some env vars or something?)
<valignatev>I've tried both ways - from the command line and from within dmenu - both ways behave well in case of pacman-installed apps
<roptat>maybe try to use strace? I don't know what you'll be looking for exactly, but maybe it can give you some hint as to what is wrong?
<valignatev>roptat: So guix doesn't look into any special place for X settings and doesn't do anything by itself to try to guard guix-based apps from the user setting, right?
<roptat>I don't think so
<valignatev>Ok, good to know that it's not something in the manual that I'm missing :)
<valignatev>I'll try to debug it somehow, maybe I'll have some success
***hitchcock.freenode.net sets mode: +o ChanServ
<rndd>hi everyone! i'm tinkering with my custom guix channel and i have a question. i tried fine the answer in manual with no result. well... at this moment to create a package i write package.scm file and put this file in my git repo. but i saw source code of guix and there is a way when you write one long file (for examples games.scm). How to do it in custom channel? How to make several long files where i can describe different packages?
<nckx>rndd: You do exactly the same thing. The ‘package.scm’ method I think you're describing (guix build -f ….scm) isn't exactly deprecated but it's not encouraged either.
<nckx>For example, here's the layout of one of my channels: https://paste.debian.net/plain/1133045
<nckx>gnuzilla.scm just contains (define nicecat <nicecat package definition>) (define other-package <its package definition>) etc.
<nckx>Other modules can #:use-module (nckx packages gnuzilla) to depend on them.
<nckx>And they all show up in ‘guix package -A .’.
<leoprikler>Rather than talking about "deprecation" or "encouragement", what's important here is "purpose". If you write a channel with the purpose of making it behave like guix proper, you'll have to write it in the same manner as guix proper, i.e. declaring all your packages as public variables.
<leoprikler>If you write single packages as one might want to do for development purposes, package.scm is the way to go.
<rndd>leoprikler: any tutorial or manual ?
<nckx>rndd: Not that I know of. There's not much to document. You simply create a directory, put a .scm file in it with a (define-module …) header and one or more define-public'd packages exactly like in Guix, then add an entry for file://my/channel/directory to your ~/.config/guix/channels.scm.
<nckx>Then you pull.
<nckx>Definitely read (guix)Channels if you haven't already.
<shtwzrd>Doesn't the directory need to be a git repo too?
<nckx>Oh, important: you need to commit any change you make before pulling.
<nckx>shtwzrd: Yes.
<NieDzejkob>nckx: If I may ask... what's nicecat?
<nckx>Example channels.scm: https://paste.debian.net/plain/1133050
<nckx>NieDzejkob: Just my personal IceCat with some hacks atop it. Mainly hacks to the JS interpreter to brea^Wfix proprietary Web sites I can't do without. Too specific to be generally useful.
<nckx>I don't actually know if they're proprietary; ‘evil’ is a better descriptor.
<shtwzrd>I dig the name nicecat
<NieDzejkob>I, too, dig the name
<rndd>nckx: thanks for your answer. my problem is that i am actually doing what you said but that doesn't work. Maybe i do something wrong.
<leoprikler>"Nicecat concatenates input files like regular cat, but adds a 'nice' after every occurence of 69, sixtynine or sixty-nine."
<atw`>I'm packaging some python, and I've been putting "test" dependencies like https://github.com/itamarst/eliot/blob/1.12.0/setup.py#L51 under native-inputs. Is that the right approach?
<atw`>
<atw`>hmm maybe I should just take what the importer gives
<NieDzejkob>yeah, native-inputs is what's usually done
<Gooberpatrol66>when I'm logged into root, I get "ssh: command not found" but when I try to install openssh, I get "nothing to be done"
<NieDzejkob>Gooberpatrol66: what command are you using to install openssh? Is that a login shell, or su/sudo?
<Gooberpatrol66>su
<Gooberpatrol66>guix package --manifest=/etc/packages-root.scm
<Gooberpatrol66>The following package will be installed:
<Gooberpatrol66>openssh 8.0p1 /gnu/store/hpwvg4v4q5hqg0qb7b6sa6rjmg47pqwj-openssh-8.0p1
<Gooberpatrol66>nothing to be done
<NieDzejkob>hmm, what does `type guix` say?
<Gooberpatrol66>guix is /home/nathan/.config/guix/current/bin/guix
<NieDzejkob>Hmm, not sure if it matters. What if you use `su -` instead of normal `su`?
<NieDzejkob>OH
<NieDzejkob>You're trying to find ssh in your user's profile
<Gooberpatrol66>ok su - worked
<Gooberpatrol66>thx
<NieDzejkob>(I don't see why you're trying to run ssh as *root* but ok)
<alextee[m]>is there a reason we're stuck on an old meson version?
*alextee[m] wants the 0.53 goodies
<NieDzejkob>alextee[m]: core-updates has 0.53.1
<alextee[m]>oh sweet, so it's coming soon
<NieDzejkob>on one hand, yeah, on the other hand, the core-updates thread on the ML seems to have died down a bit :/
<NieDzejkob>Is there some documentation on how to use Guix's packages for vim plugins? They don't seem to get detected automatically
<roptat>NieDzejkob, you'd need some configuration in your .vimrc I think
<roptat>but I'm not sure what exactly. I use set runtimepath+=/home/roptat/.guix-profile/share/nvim/site in neovim