IRC channel logs


back to list of logs

<taohansen>hey guix, i'm a little worried about updating between releases now because every time i do something seems to break
<taohansen>here's my screen-tearing code which no longer works
<taohansen>anti-screen-tearing* code
<rekado_>taohansen: how does it fail?
<rekado_>or does it just not have any effect?
<taohansen>no effect
<taohansen>worked perfectly before
<taohansen>now i've got tearing all over the place
<rekado_>taohansen: do the xorg logs tell you anything about this?
<taohansen>where does GuixSD keep those logs?
<rekado_>here for example: /var/log/Xorg.0.log
<rekado_>snippets for package definitions and commit messages are now in master. Check “The Perfect Setup” section in the manual for information on how to set things up.
<taohansen>rekado_: xorg log:
<rekado_>taohansen: I don’t know if I see this right, but you don’t seem to be using the defined device.
<rekado_>could you confirm that /gnu/store/mydbgl0ylhmm7m9v6f728lzryxcfk1pc-xserver.conf contains the section?
<rekado_>I don’t know how this works on Arch, but /etc/X11/xorg.conf.d/20-intel.conf probably isn’t the only file they have.
<taohansen>it does not contain the section specified
<rekado_>is it possible that you have to reference that device section in some other section?
<taohansen>i'm using GuixSD not Arch
<rekado_>I know, but the snippet comes from Arch, according to the comment you left there.
<rekado_>how about the contents of /gnu/store/0x0vihx9nq4rr8byizid1i8lf9zm2xsz-xorg.conf.d ?
<taohansen>4 files symlinked but none of them the defined
<rekado_>do you even have an Intel graphics chip?
<taohansen>why would the defined contents of a file change unless Guix developers are changing standards for definitions between releases?
<rekado_>according to the log you have nouveau…?
<rekado_>“Guix developers” don’t change standards for definitions.
<taohansen>i have both integrated Intel and an Nvidia.
<rekado_>according to your log the intel thing isn’t recognized.
<taohansen>that being recognized has changed between releases
<taohansen>so, regression?
<rekado_>it would be good for you to first find that snippet in the xorg config files.
<rekado_>once you’ve confirmed that it’s actually somewhere where it’s loaded we can determine if it is a regression, and in which package.
<rekado_>FWIW: my extra configuration for the X server work unchanged.
<rekado_>nothing has changed in that area.
<taohansen>okay, i'll update my locate database and do a search
<rekado_>good luck!
<taohansen>but that is strange because it has changed for me and it was right after a guix pull and system reconfigure.
<rekado_>I understand, but it’s unreasonable to assume that Guix has changed.
<rekado_>the software we provide may have changed
<rekado_>e.g. kernel, xorg-server, …
<taohansen>i guess i'd just like if i didn't have to take a day off to debug my system every time i do an update but then again i am running a 0.14 point release so if i wanted stable hah, well, what was i expecting
<rekado_>so if it’s a regression that’s where Id’ look.
<rekado_>“stable” has no meaning.
<rekado_>it’s supported.
<rekado_>we cannot possibly guarantee that the latest version of the applications we provide has fewer bugs than the previous versions.
<taohansen>`locate` cannot find the defined file so my terrible theory is my defined file is somehow not being passed along to the guix manifest as it used to
<rekado_>you may also want to try a different kernel version, e.g. one of the LTS kernels.
<rekado_>taohansen: you are mistaken: it’s not a file.
<taohansen>which sounds to me suspiciously like a specification for how things should be written in the manifest has changed
<taohansen>it's not a file?
<rekado_>no, it’s a string.
<rekado_>your suspicion is noted, but that’s not what happened. You are welcome to check the git log.
<taohansen>so i should be using `ag` not `locate`
<rekado_>I have to go now. Hope you’ll figure it out.
<taohansen>thanks for your help
<taohansen>rolled back a generation and back to tear-free nirvana. i'm just going to hold off on updates for a while. Guix devs, please let me know if i can furnish you with some logs or otherwise be helpful.
<wigust_>taohansen: differs from my [255622.029] (**) intel(0): Option "TearFree" "true"
<taohansen>wigust_: would love to take a look at your manifest
<taohansen>wigust_: thank you
<thomassgn>so for some reason guix does not provide some files necessary for x86_64 in grub; on a machine with 64bit cpu and the running kernel is 64bit. it can't find /gnu/store/...-grub-2.02/lib/grub/x86_64-efi/ and the file in it; I can't find it either, I mean it is not there, checked both on the live pen and the system I'm installing to. this is the SD btw.
<thomassgn>anyone know how to mitigate this?
<ng0>How is that a problem? (writing from a 64bit laptop with GuixSD, watching a movie on another GuixSD 64bit)
<ng0>does it affect you somehow beyond a verbose warning message?
<wigust_>taohansen: My /gnu/store/*xserver.conf contains section defined in 20-intel.conf by the way.
<ng0>oh, efi
<ng0>well, nvm my comment then.
<taohansen>wigust_: yeah your manifest declarations match mine exactly. i can only guess it's because you're running a different derivation of guix
<wigust_>taohansen: System was build from adedbe95d4896c86c26b2b3ad8408e49f52e9796
<wigust_>taohansen: Maybe you could pull it with "guix pull --commit=adedbe95d4896c86c26b2b3ad8408e49f52e9796" and check if it works for you. I don't know why you don't get the same generated xserver.conf, sorry.
<thomassgn>well, the only thing in /gnu/store/...-grub-2.02/lib/grub/ is i386-pc and grub errors out on guix system init. i.e. bootloader will not install
<wigust_>taohansen: Then you could build a system and check if desired xserver.conf was produced with "guix system build" (could do it as regular user).
<taohansen>wigust_: this is something i'll have to do when i have more time available to me.
<ng0>Wouldn't it be easier to create yasnippet-guix and let our emacs-build-system handle the installation instead of by hand from the source checkout in its etc folder?
<ng0>I mean, I would certainly prefer it to symlinking this from one git into another git (my emacs.d in my config git)
<rekado>ng0: I fail to see how that’s easier than customizing a single variable.
<rekado>there is no code to be installed at all, so the emacs-build-system would not be the right thing to use anyway.
<ng0>I don't know much about yasnippet. I just thought it would simply work, after adding a hook in init.el for a mode. so you are supposed to provide custom directories anyway?
<ng0>setq yas-snippet-dirs … ah well
<rekado>no hooks are needed
<rekado>you just need to start “yas-minor-mode” or “yas-global-mode” and have that directory in yas-snippet-dirs.
<ng0>the share/emacs/yasnippet-snippets folder of our emacs-yasnippet-snippets must be manually defined first, we do not patch yasnippet in some way to include it, right?
<ng0>*first => before it can be used
<ng0>*they … not the snippets we were talking about
<ng0>oh, I just read the package description
<ng0>I should've done that months ago :)
<ng0>thanks for the small intro to yasnippet
<ng0>When I just need to do "mvn -Dmaven.test.skip=true package" for a package - I am building jdee-server - would it be alright to just use this as a command in a phase? We do not have a maven build system yet
<ng0>I have the "client" component in emacs packaged, now I just need this:
<iyzsong>but we do not have maven (aka, 'mvn') yet...
<ng0>I've seen many many java commits. Does anyone have an idea how many packages are missing until maven can be worked on?
<castilma>why does timeout so often?
<castilma>is there a way to see, what berlin.guixsd has built?
<ofosos>Hey Guix, my guix-daemon seems to be hanging in a guix substitue --query
<ofosos>if i add a dependency to curl, my guix build hangs forever :(
<pkill9>is there a way to add the nix substitute packages to guix? I think the main Guix repo/whatever lacks substitute builds for my machine
<pkill9>and does anyone know the url to add for that?
<rekado>ofosos: you probably have a dependency cycle.
<rekado>pkill9: you may have some more luck with substitutes from
<rekado>Nix substitutes won’t help you as they are for completely different derivations.
<ofosos>rekado: this must be some implicit dependency added by the build system, how can i debug that
<ofosos>strangely, the scheme stuff compiles, but `guix build' fails :(
<rekado>ofosos: compiling the code doesn’t require traversal of the input graph.
<ofosos>I know I can use guix gc to display the dependents of a built package, but how do I dipslay it for one that isn't already built?
<ofosos>must be cmake
<ofosos>it is
<ofosos>rekado: thanks :)
<rekado>ACTION replaced two build nodes of with a single 64 core 128G memory node.
<ofosos>rekado: will you be visiting fosdem? I think i owe you a beer :)
<pkill9>rekado: thanks, it still tries to build everything (i added the public key to the authorized list)
<pkill9>i'll upload an example of the output to a pastebin
<pkill9>I don't mind building some stuff, but I'd prefer to have as much prebuilt stuff as possible
<pkill9>but it doesn't seem to accept prebuilt versions of a lot of basic things, such as gcc
<rekado>pkill9: you should use in *addition* to the default
<rekado>ofosos: yes, I’ll be there.
<rekado>ofosos: maybe we can just pass around a single beer, as we are all indebted to one another in some way.
<rekado>ACTION prefers juice
<pkill9>rekado: it still tries to build everything. Do the prebuilt substitutes depend on a particular kernel? `uname -r` outputs 4.4.88. I don't know much about building software, sorry if I'm ignorant :P
<ofosos>I spent the day yak-shaving: some test in pycurl wants libcurl to support http2, so I'm adding that to get virtaal to run
<ofosos>I don't think it's entirely unreasonable to expect curl to support http/2
<rekado>pkill9: by default Guix derives what to build from its sources. Then it asks the substitute servers if they have already built the things. If they haven’t it will proceed to build things from source.
<rekado>this means that availability of packages also depends on *your* version of Guix.
<pkill9>ah ok
<pkill9>that may explain it, I'm running version 0.12
<rekado>oh, yes, that’s quite old.
<pkill9>i didn't realise it treats guix itself as a build source, thanks
<rekado>and the software it would try to build is also at least 10 months old.
<rekado>Guix is a collection of Scheme values that reference one another; together they form a big graph of packages, each with a unique version/configuration.
<rekado>as you update your copy of Guix that graph will change.
<rekado>when you install a package you ask Guix to instantiate part of that graph.
<rekado>this means that you cannot build new software with an old version of Guix.
<rekado>(that’s technically not correct, but it’s a good approximation)
<pkill9>I think I get the general idea of how Guix/Nix works
<rekado>“guix pull” updates Guix and with it all the package definitions (and thus the big graph of interconnected packages).
<ofosos>Oh my dear, now it's rebuilding everything :/
<rekado>ofosos: did you play with the definition for curl? “guix refresh -l curl” shows you a lower bound of packages that would need rebuilding in that case.
<ofosos>No dependents other than itself: curl@7.57.0
<ofosos>Is that really `-l'?
<ofosos>Yep, it is.
<ofosos>But cmake depends on curl, and cmake will basically require rebuilding all the things.
<rekado>so you only changed the definition for curl 7.57.0?
<rekado>we use curl 7.55.1 throughout
<rekado>(that’s what’s bound to the “curl” variable)
<rekado>so try “guix refresh -l curl@7.55”
<castilma>M283750649[m]: would you mind sharing your changed grub.cfg?
<ofosos>Building the following 951 packages would ensure 2356 dependent packages are rebuilt:
<ofosos>So is this 951 or 2536 packages?
<efraim>951 packages have curl as an input, with a total of 2536 packages that would have to be rebuilt as a result of those 951
<efraim>it seems lookingglass uses ?mmintrin.h in its sources, I'm going to limit it to intel only
<ofosos>Hmm, is there an easy way, how I can teach the python build system to call `make check' for the check phase?
<rekado>ofosos: for a single package just replace the check phase.
<g_bor>rekado: Regarding the issue with java-asm, it is fine by me if we have a java-asm-bootstrap with tests disabled, but it seems that the asm tests for version 5.2 donn't work because we have a dependency we cannot compile with the current jdk.
<g_bor>rekado: I think I will check, if the situation improves if we upgrade java-asm to version 6.
<rekado>is there a reason to keep the old version?
<g_bor>rekado: I don't know 65 packages depend on it. I think if we do this in parallel with changing the default java, it is fine, but I don't know if we should upgrade this on master... I don't think so.
<rekado>yes, this should be done on the jdk update branch
<g_bor>Ok, I will have a look at that then.
<rekado>g_bor: thank you!
<ofosos>rekado: I've submitted a patch to include HTTP/2 in curl, what are the chances of getting it accepted?
<pkill9>following the binary installation tutorial at , in step 2 it says 'The latter [/var/guix] contains a ready-to-use profile for root (see next step.)', and the next step talks about sourcing from `$GUIX_PROFILE/etc/profile`, but for me the profile directory for root in /var/guix/profiles/per-user/root is empty.
<pkill9>is there something I missed?
<pkill9>for reference, I downloaded+extracted
<rekado>pkill9: did you run the commands in step 2?
<pkill9>no because I want to leave them in a folder and turn the folder intoa package with slackware's makepkg
<pkill9>i did the first command
<pkill9>the second one just moves the two extracted folders to the root filesystem
<pkill9>but i'd like to first put them ina package just so it's tracked by my package manager
<rekado>that thing is a link. Have you checked its target?
<pkill9>ah i see what's wrong, thanks :)
<pkill9>i think i may have also extracted it before incorrectly, as i changed into a new folder and then extracted again but without the --waring=no-timestamp
<castilma>how can i add a file and directory to /etc?
<castilma>i tried (simple-service 'my-X-config etc-service-type`(("X11/xorg.conf.d/52-quirk.conf" ,(plain-file "52-quirk" "content")))), but this fails with symlink error: file does not exist.
<castilma>if I remove the leading directorys, it works
<cbaines>castilma, you could tweak the gexp to produce a directory, rather that the file, but an easier way to do this would probably be to use the extra-special-file procedure, which uses the special-files-service-type
<cbaines>The special-files-service-type handles creating the necessary directories, so the above approach you're taking should work
<pkill9>what's the typical way you permantently add a substitute url? would you add it to the guix-daemon startup script?
<cbaines>pkill9, are you using GuixSD, or something else?
<pkill9>i'm using something else: slackware
<efraim> '--substitute-urls=""
<pkill9>i just mean, is there a configuration file?
<cbaines>Then yes, I think you'd need to change the arguments that the guix-daemon is running with
<pkill9>ah ok
<cbaines>I'm not sure there is a config file
<efraim>Add to the guix-daemon startup command, quoted and space separated iirc
<cbaines>castilma, did my message about using extra-special-file make sense?
<lfam>There is not a configuration file. Passing the --substitute-urls argument to guix-daemon is the way to do it
<castilma>on second read, yes. but what does extra-special-file return? a service?
<castilma>and should I really use it, even though there is the etc service, that handles etc?
<cbaines>castilma, I think it should be fine
<pkill9>after installing `glibc-locales` and setting $GUIX_LOCPATH, I no longer get the message from Guix about locales, but I still get this error: `substitute: guile: warning: failed to install locale`
<pkill9>and this error: `substitute: guile: warning: failed to install locale`
<pkill9>oops, sorry, I meant: `substitute: warning: failed to install locale: Invalid argument`
<lfam>pkill9: GUIX_LOCPATH needs to be set in at least two places to avoid those warnings (they are only warnings, btw). It needs to be set in the environment where you run Guix, so something like ~/.bash_profile. It also needs to be set in the environment where you run the guix-daemon. For me, that's in the systemd service file I use to run guix-daemon
<pkill9>ah, that makes sense, thanks :)
<castilma>cbaines: I solved it now like this:
<castilma>can someone tell me how to add filesystem mount options to the root fs? (options "data=journal") doesn't work