IRC channel logs


back to list of logs

<joshuaBPMan>I can paste the relevant files if anyone would care to give me a hint.
<leoprikler>I have some time, hit me with pastes
<smithras>hi guix, I noticed that guix provides the openh264 package, does anyone know if it's easy to get this working out-of-the-box?
<leoprikler>for which purpose? playback?
<joshuaBPMan>leoprikler: just a moment. Thanks.
<smithras>leoprikler: yes, playback
<joshuaBPMan>leoprikler: this is my config file:
<joshuaBPMan>and here is my guile-web.scm file:
<joshuaBPMan>both are in the same directory.
<leoprikler>smithras: you probably want ffplay from ffmpeg or gst-libav if using gstreamer
<smithras>leoprikler: thanks for the tip!
<leoprikler>joshuaBPMan: so your guile-web module gets loaded, but the variable is not defined?
<smithras>leoprikler: do you know if there's a way to enable playback support in icecat as well?
<joshuaBPMan>leoprikler: it seems that web...
<joshuaBPMan>but why would it not be defined?
<joshuaBPMan>it seems that way*
<leoprikler>joshuaBPMan: can you do (module-variable (resolve-interface '(guile-web)) 'guile-web-service-type) after the use-modules form?
<leoprikler>(and display it)
<leoprikler>smithras: hmm... there's probably more to that than just one thing
<leoprikler>I'm not sure whether IceCat uses Gstreamer or something else
<leoprikler>but even if it does, it might block some JS and what not that actually loads the video (e.g. on sites like YT)
<leoprikler>can you open a local video and play it in IceCat?
<joshuaBPMan>I found this error: #<variable 7ff81c438610 value: #<undefined>>
<joshuaBPMan>when I displayed the module-variable
<leoprikler>can you do that for some other variables that should be exported too?
<joshuaBPMan>it is asking me if I forgot to include (guile-web)...but I have (use-modules (gnu) (guile-web))
<joshuaBPMan>sure. I can take a look.
<leoprikler>(also compare between (resolve-module ...) and (resolve-interface ...))
<alextee[m]>packaging question: a program includes a git submodule at a specific version. assuming we package the submodule separately and made it a dependency instead, wouldn't it be wrong because the versions could differ?
<joshuaBPMan>I did get this: #<variable 7f9f188f7380 value: #<syntax-transformer guile-web-configuration>>
<joshuaBPMan>and #<variable 7f9f188f7330 value: #<syntax-transformer guile-web-configuration?>>
<alextee[m]>does guix have a way to specify versions of a dependency? although im not sure how that would work since only the latest version of a package is available at a time
<joshuaBPMan>alextee[m]: I believe so.
<joshuaBPMan>guix currently packages guix 2 for example...
<leoprikler>alextee: you can define a package, that inherits another package and uses a specific version
<leoprikler>see e.g. ffmpeg for stepmania
<smithras>leoprikler: I did some more research, and it seems like the main workaround is to build and install a h.264 extension for icecat
<joshuaBPMan>alextee[m]: you specify it like this: guile@2.2.6
<alextee[m]>leoprikler: so for every package that depends on library A at specific versions, you would make a new package for library A-versionxyz?
<smithras>It's not a priority for me so I might not get around to it, now that local playback works
<alextee[m]>that inherits fromt he base library A?
<leoprikler>not necessarily
<leoprikler>if packaging it against the version shipped in Guix works fine, you can save yourself that trouble
<leoprikler>only if it really really really requires some specific version you do that
<alextee[m]>ok, that makes sense, thank you! leoprikler joshuaBPMan
<joshuaBPMan>it looks like (resolve-module ... ) and (resolve-interface ...) put out the same message.
<leoprikler>joshuaBPMan: your exports seem to mismatch with the defines somehow, but I'm not 100% sure how
<joshuaBPMan>guile-web-configuration and guile-web-configuration? seems to be defined...
<joshuaBPMan>leoprikler: ok...
<joshuaBPMan>I'll take a closer look at some other service examples and see what I'm doing wrong.
<leoprikler>btw. you should not export guile-web-service... that variable is never even mentioned in text
<leoprikler>can you do a (display guile-web-service-type) inside the module?
<leoprikler>alextee: does that extension ship with icecat or does it have another source?
<joshuaBPMan>leoprikler: thanks for the tips. I'll try that.
<joshuaBPMan>hmmm. displaying guile-web-service-type does not display anything.
<joshuaBPMan>actually displaying any text is not working. when I put the display in the module.
<leoprikler>try loading it from a normal guix repl
<leoprikler>(or guile repl)
<joshuaBPMan>hmmm. i can't seem to load the module from guix repl...I proably need to add it to the load path...
<leoprikler>(load "filename")?
<joshuaBPMan>ok now I can successfully run ,use(guile-web)...
<joshuaBPMan>I tried to display guile-web-service-type...and apparently it is an unbound variable.
<joshuaBPMan>wait...I put the define line at the top of the file that's why...
<joshuaBPMan>unknown location: source expression failed to match any pattern in form shepherd-service
<leoprikler>(define-module) should be at the top
<joshuaBPMan>yup. it is.
<joshuaBPMan>it still seems like guile-web-service-type is not defined...
<alextee[m]>is there guix lint for a local version? -L flag is not recognized
<joshuaBPMan>alextee[m]: possibly
<joshuaBPMan>I also just realized...
<joshuaBPMan>guile-web-shepherd-service is only defined and doesn't appear to be used.
<leoprikler>you messed up your service extension
<leoprikler>(service-extension shepherd-service guile-web-shepherd-service) is what you should have written
<leoprikler>inside your shepherd service check whether the field names are actually correct
<leoprikler>I'm going to bed now, good luck debugging.
<peanutbutterandc>How exactly do I go about deleting profiles, by the way?
<peanutbutterandc>For eg: the temporary profiles created just to test things out, that I no longer need.
<alextee>even after reading the propagated-paths section in the manual, i don't get it. how are they different from normal inputs?
***jonsger1 is now known as jonsger
<peanutbutterandc>alextee, As I understand it, the propagated-inputs are added to the profile. Say, if a timelapse script package includes ffmpeg in it's propagated-input, ffmpeg will be installed alongside it in the profile but if it is just an input, it will not be in the profile but it's absolute path (/gnu/store/.........-ffmpeg) will be used
<peanutbutterandc>alextee, It seems that propagated-inputs is best avoided at all costs because it throws away the whole idea of guix: independent package upgrades. Should the timelapse script depend on a certain version of ffmpeg, and an upgrade comes for ffmpeg, it'll break it.
<peanutbutterandc>alextee, ... and it seems anyone who knows what they're doing with guix prefers (substitute*) and/or (wrap-program) over propagated-inputs any day. [I am trying to upgrade my own package definitions to not use propagated-inputs at all. 1 down. 2 more to go]
<peanutbutterandc>I hope that helps. :)
<alextee[m]>oh hmmmm i kinda understand it a bit better now, thanks
<alextee[m]>packaging question: is there a way to disable "-j 8" for a specific phase?
<alextee[m]>it's a gnu build system, so maybe just override the test phase with "make check"
<peanutbutterandc>alextee[m], I'm sorry. I don't really know much about the actual building/compiling process. Just a n00b here. But I do remember hearing that the phases can be removed, skipped, replaced, etc.
<peanutbutterandc>Some thing like this: inside (arguments)
<alextee[m]>peanutbutterandc: yeah that's what i was thinking, to just replace the phase. it seems to run "make check -j8", but this particular package doesn't like the -j8 for its tests
<peanutbutterandc>alextee[m], Perhaps you could delete the normal test, and add-after whatever-comes-before test the code `make check` that you want to run as tests?
<alextee[m]>nevermind: If the #:parallel-tests? argument is true (the default), run make check -j
<peanutbutterandc>Glad you figured it out
<alextee[m]>yay that worked
<peanutbutterandc>Question: For a package that uses cmake-build-system (or any system, for that matter), where would I have to put the debugging lines? I'd like for it to (display %build-inputs) etc for investigation
<reepca>peanutbutterandc: you could put that in any phase (it shouldn't change). Alternatively, you could look at it directly in the builder that guix generates (though it's not pretty by any means).
<reepca>regarding deleting profiles, I think just deleting the symbolic link should work. Guix treats them as what it calls "indirect roots" - there's a symbolic link somewhere in /var/roots/... or something like that that points to /my/link/location, which in turn points to whatever it is you don't want garbage collected (in this case a profile). So you can just delete the symlink and the profile will no longer be live and be able to be
<reepca>er, /var/guix/roots/..., rather
<reepca>(above information may be not-quite-right, am investigating further)
<peanutbutterandc>reepca, Thank you. That makes sense. I am also trying the debug trick. However, I haven't yet managed to invoke ls successfully. So far I've been noting the directory and `ls dir`-ing on a separate terminal
<peanutbutterandc>Any built-in guile procedure I could use (like getcwd)?
<reepca>peanutbutterandc: well, you could use scandir. May have to (use-modules (ice-9 ftw)) though.
<reepca>I assume you're using trivial-build-system?
<peanutbutterandc>The `ls` one is for everything basically. Just trying to learn some debugging tricks. What is `ftw` supposed to stand for here?
<reepca>file-tree walk, I believe. For some reason scandir is in there.
<peanutbutterandc>ice-9 is some kind of fictional element, it seems. So basically ice-9 contains the gnu stuffs and because gnu stuffs are gpl3, they named it ice-9?
<reepca>IIRC there's an explanation of the name in the guile manual somewhere
<peanutbutterandc>I see. I haven't gotten that far into the manuals yet. I will be on the look out for it. Thank you
<reepca>hm, just tried finding it and can't seem to
<peanutbutterandc>I see. I would have liked to read it. Perhaps I should `git blame` sometime and email the author. :D
<reepca>peanutbutterandc: Actually my answer about deleting profiles depends a bit on how they were created. If you used "guix environment --root=myroot", deleting "myroot" should make it no longer live (assuming it's the only root). If you used "guix package -p", you can delete generations with "guix package -p myprofile --delete-generations", but this will always leave at least one generation, which you can manually remove from
<reepca>The reason for the distinction is that all the profile generations going in one directory makes it easy for "guix package" to do things like rollback and managing generations.
<str1ngs>reepca: I think if you roll-back from the last profile. you can even delete that one
<str1ngs>or do guix package -S0 but that might not always work depending on generations
***pc is now known as Guest26386
<peanutbutterandc>reepca, I see. I will try to do so then. Thank you. :)
<raghavgururajan>Hello Guix!
<raghavgururajan>Folks! I am trying packaging for first time (excited). I have a source tar ball (tar.gz) along with it's signature (tar.gz.sig). How do I get 'base32' string from them?
<leoprikler>you verify the source tar.gz against the signature (there's a gpg command for that)
<leoprikler>then you hash it using guix hash :(
<raghavgururajan>leoprikler I tried `gpg --verify [...].tar.gz.sig [...].tar.gz`. I got error regarding public key.
<raghavgururajan>gpg: Can't check signature: No public key
<leoprikler>you probably have to import some key
<leoprikler>look at the package's homepage/download section if you can find one
<raghavgururajan>leoprikler Gotcha! Thanks.
<PurpleSym>Do shepherd services for rpc.mountd/rpc.nfsd/exportfs exist somewhere?
<leoprikler>If they're not documented, chances are you have to write your own
<lec79>Hi buddies!
<lec79>Anybody in here?
<lec79>I don't understand very well how GNU Guix works, i have a VM in Virtualbox and i don't know how to upgrade the system
<leoprikler>upgrades inside a VM should be the same as upgrades everywhere else
<lec79>But you have to run guix pull only or you have to run guix pull and guix system reconfigure?
<leoprikler>guix pull followed by sudo guix system reconfigure
<lec79>guix pull as normal user or root?
<leoprikler>normal user
<leoprikler>if you get a warning about Guix being outdated, use sudo -E
<leoprikler>(alternatively pull once as root)
<leoprikler>s/being outdated/not existing/
<lec79>Compared to Pacman or DEB, Guile it's very slow.
<leoprikler>it's probably faster on real machines
<leoprikler>the major difference to debian and arch are source builds
<olivuser>Hellp #guix!
<grumbel>Can two versions of a package installed at the same time? I am getting conflicts here between gtk+@2.24.32 and gtk+@3.24.10, but as far as I can tell gtk2 and gtk3 shouldn't conflict with each other
<brendyyn>leoprikler: lec79; from my brief encounters with nix, i feel Guix's operatings are much slower than Nix too. like when uninstalling a package from a profile in Nix, it was instant. updating was much faster too and there are always substitutes
<olivuser>I have rsynced a ton of data, ~250gb, from an old (~5-7yr) ext4-formatted sata drive, to a new, btrfs-formatted sata. Since then, my system is so slow I cannot use xfce anymore, and even the TTY's are incredibly slow.
<olivuser>What could be the issue with that?
<lec79>brendyyn: i think so, but even when guix are installing only binaries, is slower than Pacman and DEB.
<olivuser>I mean I am now going to do a btrfs-check, but how is it that my computer becomes essentially useless after what I consider a "routine"-ish data transfer with an established tool?
<brendyyn>lec79: yeah that is hard to beat because the design is much more complex
<grumbel>olivuser: Is the drive near full? btrfs can get extremly slow on full drives. Maybe 'btrfs balance' can help. Also check dmesg for errors
<lec79>brendyyn: it will take a lot of time until Guix can compite with other package managers, every package manager has his own way to work and needs a lot of development.
<olivuser>grumbel: far from it, there should be about 150gb free, minimum. Will try those options and report back, thanks.
<olivuser>I am wondering, is it necessary to have btrfs-progs installed for btrfs filesystems to work properly?
<olivuser>grumbel: in dmesg, what would I have to look for in dmesg?
<grumbel>olivuser: stack traces involving btrfs or something, btrfs can be a little weird sometimes and rebooting tends to fix that
<grumbel>olivuser: Also have a look at 'btrfs fi show'
<olivuser>grumbel: will try reboot
<grumbel>btrfs can get full even when df reports that it's still pretty empty.
<olivuser>grumbel: but what would I do if it says it is full while it isnt according to other measures? Offloading to other hdds?
<grumbel>olivuser: that's what 'btrfs balance' will fix, it's not that the drive is actually full, just some of btrfs data structures got full and need some reordering
<grumbel>What is the relation between /var/guix/profiles/per-user/root/current-guix and /var/guix/profiles/per-user/juser/current-guix? Both contain a pure profile with just guix tools. Do I need both? Or should ~/.config/guix/current really point to the root one?
<grumbel>The guix-daemon is still managed by the root profile, so I don't see why there would be a set of guix tools updated independently of the guix-daemon (maybe I just screwed up the install?!)
<peanutbutterandc>grumbel, I believe it allows for separate users to `guix pull` to separate commits of guix. i.e. One could `guix pull` from root (on a foreign distro) and have the updated version of guix and guix daemon running, but the user foo could still stick to guix 1.0.1 or any other thing to his own liking
<peanutbutterandc>the current-guix dir only exists after running `guix pull`. So, contrariwise, the root could be stuck with 1.0.1 whereas foo could be using the latest and greatest guix.
<grumbel>I see, so it's more an artifact of package database and guix software still being one git repository.
<peanutbutterandc>grumbel, I think it is not "still being one git repository" but "actually being one git repository": it seems to be a design decision made by the guix developers pretty early on that the gnu distribution and guix go together
<peanutbutterandc>grumbel, But you could always use channels if you want a separate repo for packages. Like I have done here:
<peanutbutterandc> <- reference (channels). I read about the design decision thing in a blog post in, I believe
<grumbel>yes, for the future I would hope that the guix package database just becomes a channel, might of course have to wait for a stable packaging API and such.
<peanutbutterandc>It might have been this one:
<peanutbutterandc>The 'On Coupling' section.
<peanutbutterandc>grumbel, Also, if you want to experiment with guix as much as you want, a good way to do it would be inside of docker containers (that's how I did it first): I hope that helps. (:
<PurpleSym>leoprikler: Is it possible to extend session-environment’s config somehow? It’s not a base service, so I can’t modify-service it. But adding it to the list causes the image building to fail.
<PurpleSym>(inside an operating-system context)
<olivuser>so, I installed my home partition as btrfs using the guix graphical installer. Since my computer has become TERRIBLY slow after a data transfer from an old hdd, I tried running 'btrfs balance' on said partition. When I do that, btrfs balance says said partition is not btrfs, even though 'df -T' confirms it is. Any idea whats going on?
<olivuser>I did not have btrfs-progs installed from the getgo, will do a guix system reconfigure with those added to my config file, hope that helps...
<raghavgururajan>I was trying build a package using node-build-system. When 'build phase' started, I got an error "command "gulp" failed with status 127".
<raghavgururajan>How should I proceed further?
<grumbel>raghavgururajan: I think 'error 127' is when the program in the shebang (#!/bin/sh) isn't found
<grumbel>Is there a quick&dirty way of integrating guix.scm files found in upstream git repositories into the local system? Installing with 'guix package -f guix.scm' works well enough, but guix complains on updates about the packages having gone missing
<smithras>The not quick&dirty way would be with channels
<smithras>but maybe you could use the profile system to create a profile just for that one package, then guix package -u wouldn't always try to update it?
<smithras>I don't know much about profiles though, I just skimmed the article that was written a while back about them
<truby>hi guix! I've got a few patches for the llvm packages that I'd like to try and upstream, I was just wondering what the protocol is on version bumps in packages like llvm? Currently the latest package version is 8.0.0 but there's a bugfix/security release for that upstream (8.0.1) as well as a new version (9.0.0).. I was thinking to bump 8.0.0 to 8.0.1 and add a new llvm-9, clang-9 etc with the new version since it's backwards
<truby>I'm also wondering if I should do the version bump separately to the main part of my patch which is to fix clang++ finding C++ headers properly :-)
<ng0>truby: iirc it should be done on core-updates or at least not the default branch, as llvm->clang->rust->many rusts->icecat causes not many rebuilds but expensive in time
<truby>ng0: I don't think rust depends on clang, only llvm. But yeah the version bump would cause those rebuilds I guess :(
<truby>It seems like a bad idea to hold back potential security bug fixes to avoid rebuilds though
<ng0>okay, but unless guix is building firefox/icecat differently, clang itself is also used during icecat build (or is icecat so far behind that this has yet to happen?)
<ng0>when in doubt, better ask on the mailinglist?
<ng0>i have no idea how this is handled in guix now
<truby>Yeah I thought about that after I asked on here and did so :)
<ng0>ok :)
<truby>Just trying to familiarise myself with the contribution process here
<truby>I'm not sure icecat can be building using clang though, isn't it a C++ application? Clang++ currently doesn't work, that's the issue I wrote a patch to fix /)
<ng0>ah, ok
<ng0>in pkgsrc we build it with clang++, but that's not icecat there. nevermind then
<olivuser>Hello guix. After data transfer (ext4>btrfs), my guix system has become super slow. Now, when I try to 'btrfs balance /dev/sdbX/', I am told that said partition is not a btrfs filesystem, even though 'df -T' says so and I did format to btrfs using the guix installer. Any ideas?
<nckx>olivuser: Because ‘file system’ here means ‘/’ (or whatever), not block device.
<truby>ng0: upstream (as in, firefox) do recommend to build it with clang, and their prebuilt binaries are all clang built. But I do believe it still builds fine with gcc
<nckx>Let's build it with GCC so we can report bugs & keep it that way 😉 (Sigh…)
<nckx>truby: Are you familiar with grafts? They address the rebuilds vs. security updates issue in many cases (unless ‘vulnerable’ clang code is statically linked, which is possible but unlikely).
<truby>nckx: vaguely :) I would have no idea how to write one though
<nckx>truby: Have you read the ‘Security Updates’ section of the manual?
<roptat>hi guix!
<truby>oh, that doesn't seem too difficult
<roptat>I have an issue in my graphical terminals... I can't type non ascii characters in them after my last reconfigure (and guix pull && guix package -u)
<nckx>It's really quite easy: you (define …) an entirely separate ‘clang/fixed’ package (you could even copy & past the original clang but in practice we use ‘inherit’), then add (replacement clang/fixed) to the original clang.
<nckx>truby: ☝
<truby>so I should be able to just add an llvm-8-fixed package, then (replacement llvm-8-fixed) in llvm-8? in theory :)
<roptat>I thought about an issue in the glibc version being used, but it doesn't seem to be the case, as everything seems to be using glibc 2.29, which is the system's version
<roptat>also, I don't have any issue on a tty
<nckx>roptat: Hm, I had the same/a similar problem after the c-u merge with “ ‘ ’ ” etc. but it *did* go away after updating both of my profiles to the a recent commit.
<truby>ok, I can do it that way, and add llvm-9 clang-9 etc as separate packages too so that they are opt-in (for now?)
<roptat>ha! I know :)
<roptat>I forgot it came from another profile
<nckx>Also emojes which appeared as ‘?’, not raw boxes, so something somewhere was doing *some* interpretation.
<nckx>roptat: Ah 😃
<roptat>thanks nckx, I'm stupid :D
<roptat>the whole thing is built by the home manager
<nckx>truby: Yes, it's a good idea to keep ‘adding the new version’ & ‘flipping the default’ as 2 separate steps in non-trivial cases.
<nckx>Easier to test & makes git revert easy.
<ng0>oh, i forgot about grafts. sorry
<nckx>The GNU-BSD brain drain is real.
<nckx>ng0: How go your pkgsrc adventures?
<ng0>i knew grafts exist, it's not that bad :)
<ng0>that's a very broad question.. i don't know. it's good?
<nckx>Sorry. That's because I don't know what exactly you're working on now, if it still involves (future) Guix or not.
<ng0>it might involve guix, at least i have wip/guix but wip/nix is crawling along at a faster "speed" to be finished
<ng0>I have a bunch of packages, and I'm looking into maybe reasoning for more additions to the reproducible stuff in pkgsrc.
<ng0>getting both to run with pkgsrc is more like hacker curiosity at this point, i don't know if (with guix hat on) we'd add native netbsd support or if compatibility can be used, etc. and with this in pkgsrc we could hypothetical add support for more OS and architectures in guix, but in the end i know at guix we have other priorities than in pkgsrc, so it probably comes down to just guix on netbsd
<ng0>the guix package is stuck at me finding motivation to patch up gnutls so that I can build the pkgsrc gnutls with guile bindings as they currently assume too much about tripplets
<dongcarl>How to I indicate to `lookup-inferior-packages` that I want the `static` output of a package?
<dongcarl>`zlib:static` doesn't seem to work...
<leoprikler>sneek later tell PurpleSym I'm not sure.
<leoprikler>dongcarl: by the lack of inferior-package-outputs I assume that is not yet possible
<dongcarl>leoprikler: Yeah I'm thinking on the wrong level
<dongcarl>`inferior-package->manifest-entry` is what I want
<leoprikler>which sadly seems not to be documented
<fps>hmm, i'm trying to set allowoveride all in my apache config
<fps>but i can't even herd start httpd with tht
<fps>it just tells me service httpd could not get started
<grumbel>Any easy way to disable the sha256 check for packages? If I do '(source (local-file ...' I can get away without the sha256 check, but how would one do so with a remote git repository?
<fps>is there a way to debug this?
***xwvvvvwx- is now known as xwvvvvwx
<leoprikler>fps: did you inspect the generated config to see, that it is actually what you think it should be?
<fps>leoprikler: how do i find out where that config is?
<jonsger1>hm wip-gnome-updates seems to be broken
<leoprikler>search for *-httpd.conf in your /gnu/store
<fps>leoprikler: hmm, that is a little backwards, no? there might be several
<leoprikler>perhaps the filename is also logged to /var/log/httpd/error_log
<fps>also i might disturb the gamers playing on the xonotic process on that server if i search through the whole store
<fps>leoprikler: i checked there already. last error is from 7th of november from a couple of days ago
<fps>shouldn't there be a way from inspecting the system profile/
<leoprikler>I'm not sure where that would be stored tbh
<leoprikler>but if you can guess the path to some httpd.conf you might find a symlink
<alextee[m]>anyone here tried using cairo in guix? i can't get gradients to work
<alextee[m]>same code works in other distros
<alextee[m]>actually nvm, was my mistake
<fps>is there any way to get more debug info out of herd?
<leoprikler>by inspecting pid 1 you can find the shepherd conf
<leoprikler>from there you should find out the name of the config passed to httpd
<leoprikler>grumbel: you can do local-file even if you clone a repo
<fps>.go is a guile object file?
<fps>oh well, the path to the conf is readable as a string in the binary file ;)
<leoprikler>if i do ps aux | grep shepherd, I get /path/to/guile --no-auto-compile /path/to/shepherd --config /path/to/config
<leoprikler>what is your result?
<fps>yeah, i get the path of the shepherd config as well
<fps>but when i inspect that file there's only a reference to a /gnu/store/jicq7747zg4haxx9xgy88z78hagzqyz8-shepherd-httpd.go in there
<leoprikler>you can disassemble that with guild disassemble
<leoprikler>if reading binary is not your strength :)
<fps>well, the path to the config was readable in the binary.. but it seems to be one from a previous generation..
<fps>and guild shortens strings ;)
<zacts>hello gnu guix geeks
<fps>leoprikler: disassembling byte code to get the path to the generated config isn't really a sensible way to be able to inspect the system ;)
<leoprikler>well, the path is also printed when building an OS, but now one pays attention to that either :)
<fps>there was a path of a derivation printed
<fps>but not of the generated config itself iirc
<leoprikler>okay, my bad
<leoprikler>you get the derivation, which should contain the path to the actual file
<fps>but also only if you change that part of the config :)
<fps>oh well, i think i figured out what was wrong with my config. trying something
***MinceR_ is now known as MinceR
<jonjitsu>I'm trying to find information on if my lenovo t480 is fully supported. I think it would just be the wireless card (AC8265) that might need a binary blob. Is there a list of supported devices somewhere?
<bavier>the build progress meter seems to be confused by the "ghc" package's build output...
<bavier>jonjitsu: guix generally supports hardware supported by linux-libre
<jonjitsu>bavier: ya I was looking through the linux-libre website for such a list. I guess I need to search through the repo...
<bavier>jonjitsu: is the t480 similar to the t400? The latter has a couple RYF-certified models
<jonjitsu>bavier: The T400 seems like an ancient ancestor of the T480. I'm pretty sure the wifi card in the T480 is replacable though...
<jonjitsu>Do the RYF-certified models + drivers support bluetooth?
<nckx>bavier: Not from a technical standpoint. The 8 means ‘8 full generations since 0’. (‘T4’ is the model/form factor i.e. ‘they look similar’; the last digit is a revision number for minor tweaks, almost always 0).
<nckx>jonjitsu: No whitelist anymore? Nice.
<alextee[m]>i heard that icecat is supposed to have a tor button, don't we have it in guix?
<nckx>alextee[m]: No ‘Onion Browser Button’ in the Add-Ons list? That would be a change since 60.x. Best ask in #icecat.
<bdju>I've been wanting to find out if my T440p can use something supported by Linux
<bdju>they changed the wlan cards to m.2 which isn't covered by hnode, so I'd imagine the T480 has the same problem
<jackhill>alextee[m]: also see this thread: I believe an accurate summary is that ist's a known issue, but it may not have as good as it seemed anyways
<jackhill>it would be neat to have the full tor-browser in guix, but I don't know what's required for that.
<vertigo_38>I'm rather new to guile -- does anyone know how to load multiple modules in a more character-saving manner than (use-modules (gnu) (gnu packages emacs-xyz) (gnu packages statistics) [...]))? I'm aiming at writing 'gnu packages' just once and pass a list to it in my config.scm. I've tried constructs like (gnu packages (append (list emacs-xyz statistics))) and (gnu packages '(emacs-xyz statistics)), but obviously did not succeed with
<jackhill>vertigo_38: (use-package-modules …) might point you in the right direction
<jonjitsu>bdju: I noticed it was an m2 card in my t480. I was wondering if I could replace it with something like this but I would lose bluetooth
<leoprikler>perhaps you can get a USB dongle to work for you?
<alextee[m]>jackhill: thanks, that makes thing clearer
<vertigo_38>jackhill: thank you, that looks good! it somehow seems to build the packages anew right now, but I'm totally fine with that!
<bdju>jonjitsu: thanks for the link, I might order one of those cards. it looks like it will probably work
<bdju>you may have to mod your bios or install coreboot to remove a whitelist. I don't know about the T480, but on my T440p I'll have to do that. planning to flash coreboot at some point.
<raingloom>can we make PulseAudio use "flat-volumes = no" by default? idk what's the "vanillaness" rule, but even Arch sets that, and Arch packages are pretty vanilla
<nckx>raingloom: Arch doing something's not exactly an argument to do it too 😉 What is? I've forgot the sides in this endless debate.
<leoprikler>I'm seeing color emoji
<leoprikler>they're black, but I'm seeing them :D
<raingloom>nckx, well, it makes it more user-friendly, and if even the no-graphical-installer-for-you distro thinks it's worth it, it's probably worth it in Guix as well
<dustyweb>raingloom: I'd be for it
<dustyweb>really hurt my ears before thanks to flat-volumes :(
<raingloom>then i'll whip up a patch (unless someone gets to it before i do)
<nckx>leoprikler: ᕕ( ᐛ )ᕗ
<nckx>raingloom: *Why* is your preference more user friendly?
<nckx>Arch isn't exactly known for not patching stuff.
<raingloom>nckx, without that option the volume settings get very weirdly glitchy with no obvious reason, eg. VLC volume controls start controlling the master volume, setting different volumes for stereo channels breaks as soon as I start mpv or vlc, etc
<nckx>Interesting. Can't say I've ever had that problem with VLC but I don't use it often.
<nckx>Isn't that a bug in VLC?
<dustyweb>nckx: it's not just vlc
<nckx>(Not that we can't or shouldn't work around it, just wondering.)
<str1ngs>arch is short for arch nemesis .. just saying :)
<dustyweb>flat volumes results in weird behavior where you up the volume in a program, lower it in another
<leoprikler>or you up the volume in a program and it doesn't change :)
<dustyweb>and the other program lowers, but the other one stays up for the max, but unexpectedly you've changed your base volume
<leoprikler>fun things
<dustyweb>and then
<dustyweb>so this other program seems quiet
<dustyweb>you turn up your speakers
<dustyweb>another program makes a noise
<dustyweb>and if you ahve headphones on
*nckx is feeling so happy lucky rn.
<dustyweb>there go your eardrums
<dustyweb>I consider flat-volumes physically unsafe.
<dustyweb>new version of dungeon crawl stone soup pushed to master... not sure who else is a dcss fan here but
<dustyweb>man it's such a nice improvement
<dustyweb>throwing weapons improved, sif muna a better god, very nice all around
<nckx>Yeah, I've heard that before, but it's like we're using two totally different systems. I'm not exactly Mr. Multimedia, but I watch ‘Internet videos’ and enjoy ‘music and film’ as much as anyone. Never noticed anything even remotely odd about volume.
<nckx>raingloom: If that's what the OOB experience is for some people, please submit all the patches. 🙂
<leoprikler>there's nothing odd if you only have one program running and adjust your speaker via hardware
<raingloom>nckx, on it ^u^
<leoprikler>perhaps the wisest thing would be to have a <pulseaudio-configuration> record
<leoprikler>(it will have many fields tho)
<nckx>leoprikler: I think I use the MPV/VLC controls about 50% of the time, physical controls the other half, so it sounds like I'd be more likely to hear subtle (or soul-destroying) differences. Oh well.
<nckx>leoprikler: It can start out small, with just this knob (that's a better way to set a distro default than patching anyway).
<efraim>do we have an easy way to run modprobe at boot?
<raingloom>hmm, then i might have to write this later, because idk how to add new config records yet, and i have midterms this week.
<raingloom>or should i still send a patch until a proper solution is merged?
<nckx>raingloom: That's understandable. You can just open a bug report (with our without patch) for discussion.
<raingloom>good idea
<nckx>I now totally agree that this needs to be fixed somehow but it doesn't have to be rushed. Apparently it's been horrible for some people for years.
<nckx>And good luck 🙂
<jonsger>that's bad. It's very cold outside and our heating is broken. So I could "heat with Guix", but it doesn't run on ppc64le :(
<raingloom>i think i might have asked this before, but what's the reason botting became so slow recently? my most up-to-date profiles take a while with populating /etc, whereas older ones boot in seconds. did i enable something in my config that made it so slow or is this about reinitalizing stateful directories?
<raingloom>also, why not do a read-only bind mount and overlay it with a tmpfs? live-boot style.
<raingloom>(would be lighter on SSDs)
<nckx>raingloom: Because there's a lot of valuable data in /etc that you *want* stored safely on that SSD.
<nckx>I just installed a new printer and set its options; that's stored in /etc.
<nckx>(Should it be? Not in a perfect world, but… 😛)
<nckx>If every upstream knew what /var was for we could do what you suggest. At the expense of some valuable RAM, but it could always be made optional.
<nckx>Though at that point you could pre-create a static /etc in the store and just symlink it.
<raingloom>nckx: but if it gets overwritten on boot, why store it?
<nckx>raingloom: It doesn't?
<raingloom>oh. then what takes so long to copy?
<nckx>I don't know, I haven't noticed the bug of which you speak.
<raingloom>when init says it's "populating /etc from /gnu/store/1234...", that takes way longer than it used to, 2-3 minutes instead of seconds.
<nckx>Is it still faster when booting an older generation, now?
<raingloom>yep, older ones take seconds
<bendersteed>hello guix, I'm working on a racket build system. Is there any guile function for recursively symlinking a dir?
<bendersteed>I mean something like "cp -rs"
<bavier>bendersteed: 'union-build' from (guix build union) operates like that
<bendersteed>bavier: thanks!
<nckx>raingloom: Is there a bug report for this? I can't update my laptop for reasons that are entirely my own fault. A server booted slowly yesterday but then it uses 4 spinning drives and btrfs so 🤷
<raingloom>nckx, not that i know of, because i wasn't sure if it was a bug, but i can make one if needed
<nckx>raingloom: Don't hesitate to.
<nckx>2 minutes is extreme, and it's not your disc dying if older generations work fine.
<bendersteed>bavier: really thanks, this exactly the thing I was searching for! yay
<bavier>bendersteed: great ;)
<Blackbeard[m]>Hi guíx :D
<nckx>o/ Blackbeard[m].
<Blackbeard[m]>nckx: how are you?
***akko is now known as stallman
<kts>Blackbeard[m]: Hello
***stallman is now known as akko
<bendersteed>any ideas why it is reported that there is no code for module (guix build union)?
<nckx>bendersteed: Did you add it to #:imported-modules?
<nckx>Remember that this code is probably called on ‘the build side’. Don't add it to the top of your file, add it to the build envionment.
<nckx>Blackbeard[m]: Just got some great news from a pregnant friend so quitting IRC for the night \o/ Bye all.
<bendersteed>yeah, just found it! thanks. I had to ask to find it then.
<vagrantc>the last build-dependency for guix landed in Debian:
<stikonas>vagrantc: congratulations! Is the plan just to get guix into Debian, or will it somehow be used for bootstrapping too?
<oriansj>stikonas: getting guix into debian because it isn't need for the bootstrapping of guix on top of debian
<stikonas>well, I similarly have guix on top of Gentoo here
<vagrantc>stikonas: hoping to get guix into debian; we'll see how far it gets
<stikonas>but on Gentoo avoiding new binary seeds gets harder and harder... I had to write my own ebuilds of openjdk-9 and 10 to build openjdk-11...
<oriansj>well we got Guix into Arch; and I forgot the RPM package for guix status and if anyone is still maintaining that
<oriansj>stikonas: binaries tend to spread because of laziness; it takes a shitload of structure and hard work to actively work against that default
<jonsger>oriansj: guix is in openSUSE for quite a while now :P