<joshuaBPMan>Also, if someone wants me to host a static website, please let me know.
<str1ngs>nly: Hello I have created an experimental webrtc branch. if you pull nomad ans switch to the webrtc branch. then guix environment nomad-git . you can test with make run. substitutes are also provided on http://gx.bufio.org you'll probably want those to avoid large rebuilds. you can test with this snippet in ~/.nomad. http://paste.debian.net/1161792 . please only use this for testing I need to do somewhere on the 'permission-request
<str1ngs>signal before you can use this for real. let me know if you have any issues. also test with jitsi if you can please.
<peanutbutterandc>Hey there, I am working on a package that uses the cmake build system, and at the end of configure phase I am being warned "Manually specified variables were not used by the project: CMAKE_INSTALL_LIBDIR"
<nckx>peanutbutterandc: The warning is warning you that ‘you’ manually specified a variable on the CMake command line, which the project didn't use. I.e.: it had no effect, was pointless, but harmless.
<nckx>I say ‘you’ because Guix passes some default variables like CMAKE_INSTALL_LIBDIR, not you. However, manually passing it *again* won't help 😛
<peanutbutterandc>nckx, But `guix environment -L . --ad-hoc the-package-i-just-made` && cd $GUIX_ENVIRONMENT && tree shows that there is no lib directory. And the package was acting kinda' buggy (whereas my manual non-guix build works well, kinda) so I thought this might be an issue
<nckx>Pretty sure that setting it as an environment variable has no effect at all.
<peanutbutterandc>nckx, I do the same thing. guix environment is super cool.... ah! I thought i had ffmpeg in my normal profile (I was so sure!) but turns out I have not. Well, time to (wrap-program, then!
<nckx>Don't be hard on yourself. Be happy it's easy to fix.
<peanutbutterandc>I am glad all of you here are so kind and willing to help. Thank you very much for that. I really appreciate everyone here who has taken me under their wings one time or the other. (:
<peanutbutterandc>Yes, it is a great one. And what I like most is that it doesn't quite seem forced. But everyone is just very chill. And willing to help out. So, maybe this is by virtue of a lot of chill people hanging out rather than a code of conduct.
<jgart[m]>brettgilio: I'm still meaning to get back to your email. Thanks for sending the info about debugging the guix channel for your emacs config package. I haven't found the time to test that again. I'm hoping to reply soon
<nckx>But OK, even adding a separate emacs-26 back is probably work that could be better spent on fixing the breakage.
<brettgilio>jgart[m]: oh that was you! No worries. I am messing with it right now
<brettgilio>nckx: it's probably just my philosophy but I agree. We should have started with a wip branch, we should just fix it and advise people use inferiors until we finish fixing it
<brendyyn>Hmm. Doom breaks my emacs's guix extension. When i run guix-edit i get No geiser repl for this buffer. if i run run-geiser, then running guix-edit says starting repl and errors with no prompt found
<jgart[m]>cool! Ideally it is how I would like to have my emacs configs managed (i.e. as a guix package definition)
<jgart[m]>something that behaves like guix profiles and manifests but for switching between different emacs configs could be nice. Might be useful for those emacs users that want to quickly jump between doom and no doom
<mroh>jgart[m]: doom means: no guix emacs packages, yes?
<mroh>maybe you could have 3 guix profiles: one "root", and the other two that inherit from "root" with guix-emacs and doom-emacs.
<jgart[m]>if a user wants to build packages on guix system in the traditional way for testing, experimentation without guix should they ```guix install debootstrap lxc``` and build them using one of the above?
<brendyyn> i dont have any special config appart from installing Doom emacs. with emacs -Q i can run guix-edit just fine
<str1ngs>jgart[m]: you can build it manually. say you want build bash locally. you can do guix environment bash then configure and make ... etc
<raghavgururajan>peanutbutterandc, brendyyn: DG_RUNTIME_DIR=/run/user/1000 is set by elogind-service
<raghavgururajan>peanutbutterandc, If you ran the program in a pure env, then you can ignore that warning. elogind is something that user will have to setup. The program installed and running with elogind-service, will not show that warning.
<raghavgururajan>It should not be. Because, if the program is wrapped with "XDG_RUNTIME_DIR=/run/user/1000", then the program will look for that dir/file, which will not exist in pure-env or in system without elogind.
<peanutbutterandc>raghavgururajan, I am on a foreign distro.... And yes, I did ran it in a pure env... so perhaps that is why it's saying that....
<zjgkkn>guix-vits: no, but just try it -- doesn't work. May be `guix build ghc ghc-xmonad-contrib xmonad` will help?
<peanutbutterandc>raghavgururajan, Hey there, a package I packaged put it's icon in GUIX_PROFILE/share/icons (outside any other dir)... it is just a single 500x500 png file. Is share/pixbuf a better place to put it? o.O
<peanutbutterandc>strange thing is: while I was running from `guix environment --ad-hoc prog`, I can see the icon in the panel, but now that I've installed it into my profile that I can't see the icon at all
<raghavgururajan>peanutbutterandc, LoL why sir. So $prefix/share/icons is the default location for installing icons. Any sub-dirs following that, depends wupon use cases.
<raghavgururajan>peanutbutterandc, Wait a sec, you mean panel inside the program right?
<raghavgururajan>jgart[m], One issue though that any non-official instances cannot be constantly verfied for FSDG compliance. As it will be under control of the custom channel's owner and not guix maintainers.
<raghavgururajan>Any other channel can silently start distributing non-free software.
<jgart[m]>raghavgururajan: right. It would have to be a use at your own risk list/website
<raghavgururajan>jgart[m]: Now I wonder, did you mean to channel or substitute-server?
<jgart[m]>probably not endorsable by guix.gnu.org because of FSDG
<jgart[m]>raghavgururajan: a website for each would be nice :)
<jgart[m]>since they are different things even though they are related
<brendyyn>Its an interesting proposition. I've thought about it too. What kind of channels should exist where the packages wont be put into guix proper, besides proprietary software?
<jgart[m]>I think it would be good to make a distinction between a substitute server and a channel not offering substitutes
<raghavgururajan>jgart[m]: Yeah! the substitute server should not be an issue. Because, when a user uses official channel but tries to download from custom substitute-server, then guix won't download due to mismatch of hashes.
<brendyyn>suppose for example guix deleted python-2, so someone created a python2 channel for that old stuff. but in that case i think it would be good for guix proper to include an updated /purpose/ based list of such channels
<jgart[m]>but a channel doesn't have to package software per se
<brendyyn>i need to explain what i mean. With debian/ubuntu, i often add a new Source for something specific, but over time that repo might get abandoned and there will be another one somewhere to replace it
<jgart[m]>there can be two versions of that package
<jgart[m]>the audio only version and the full video version
<brendyyn>so for example there could be a suckless channel, but guix proper will include a list of free software channels that have names like "suckless", which will point to which ever channel is the go to for latest suckless software. if in the future that channel gets abandoned but someone else forks it, guix can just change that path and things wont break for everyone
<jgart[m]>kind of like the way sicp is packaged as an info manual
<raghavgururajan>jgart[m], We can list channel mirrors though. All mirrors will be signed same.
<brendyyn>yeah, one of the things i want to do is create packages for all creative commons dictionaries i can find
<raghavgururajan>peanutbutterandc, I checked linphoneqt. It has /share/icons/hicolor/scalable/apps/linphone.svg. But no other icon files. My bet is, an application *should* have a icon in either *48x48* non-scalable format (png) or in scalable format (svg).
<peanutbutterandc>raghavgururajan, I see... that makes sense... I'll try to find some another way to fix it. Thank you very much once again.
<raghavgururajan>peanutbutterandc, I think that because, scalable icons can be resized, where non-scalalable icons cannot be resized. So anything larger than 48x48 may not be compatible to be fit/viewed in menus.
<jgart[m]>just wanted to share something cool I just found out. If you want to use the guile repl from the terminal with vi keybindings and readline you can use rlwrap with this in your $HOME/.inputrc https://paste.gnome.org/pdimj63vu
<raghavgururajan>peanutbutterandc: When you are charged-up, try this. I found out something new. In .desktop, make icon line just as `Icon=AppIcon`. No png, no /gnu/[..]. Let the rename stuff be /share/icons/hicolor/48x48/apps/AppIcon.png
<raghavgururajan>That is because, `Icon=` attribute already defaults to $XDG_DATA_DIR/icons/hicolor/48x48/apps. If there is /gnu/[...] in `Icon=` line, then DE's will look for $XDG_DATA_DIR/icons/hicolor/48x48/apps/gnu/store/.../share/icons/hicolor/48x48/apps, which doesn't exist.
<raghavgururajan>I checked with other GUI apps. They have `Icon=prog-name` in .desktop file and `prog-name.png` file under /share/icons/hicolor/48x48/apps
<leoprikler>for this usage of --profile, yes, it's where to put it
<leoprikler>for other uses of --profile [e.g. --list-installed] it is the path to an already existing profile
<leoprikler>in either case --profile is always the location of the profile, not a name or something
<fnstudio>leoprikler: cool, thanks; and how about the `manifest.scm` that i pass via `--manifest`? is it good practice to save it in the profile folder? or can it be discarded straightaway after its use?
<leoprikler>well, you can save it right next to the profile, but in the profile would be a bit difficult
<fnstudio>right, difficult as in "it'd be overwritten"?
<leoprikler>where you put it is your preference. I personally use ~/.config/guix/manifest*.scm
<roptat>so that's probably because guile3.0-chickadee propagates guile3.0-opengl and guile3.0-sdl2 (llvm is a dependency of mesa)
<roptat>you can see it with guix graph guile3.0-chickadee --path llvm for instance
<roptat>I don't think we have a type of graph that shows you exactly what's in the pack: the references type is a subset of them (only references, but not propagated inputs), the default one is a superset of them (it shows all the inputs, even when they're not used at runtime)
<simendsjo>Thanks, that's quite useful. Not really feasible to give someone a 1GB program for a really small thing though.
<roptat>well, people are used to huge games, no? :p
<simendsjo>Haha, but then they get more art than computer generated squares :)
<brendyyn>simendsjo: it would be interesting to explore making portable apps with guix. i think you would need to define custom packages that stripped out many things. the thing about guix is that it includes literally every dependency
<roptat>splitting llvm into bin / lib / devel would be a win of 37 MB already
<brendyyn>but many of them could be deleted and integrated with the system
<brendyyn>for example what of there was a phase with guix pack that could delete the bundled terminal and replace it with a link to /bin/sh
<leoprikler>well, yeah, but how do you ensure that /bin/sh behaves how you want it to
<simendsjo>Yeah, I expect far from 1GB is needed to run this. I have no idea how it should be done, but it sounds time-consuming and that you'd need experience with guix.
<brendyyn>there are no guarantees for anything, its about compromising for practicality.
<brendyyn>well my idea actually has almost nothing to do with guix. for example you make a guix pack, extract it, then delete things that are not needed, and a strict that replaces them with links to their location on the host system
<guix-vits>sneek: later tell vagrantc: (aarch64) Do You have any pointers: how to make sddm, slim, or anything like that work? I can use sway, and xterm (for example). But the display managers do not work..
<joshuaBPMan>also, question time. I've got gnucode.me running again (finally). It is being served by a guix system on a linode. I've set up certbot and nginx per the manual and civodul helped me to do it....I'd like to set the site to redirect to https...I've done that before. But will that eventually cause certbot to fail, if it needs to re-issue a certificate? because when it tries to go to
<str1ngs>though this wraps GI_TYPELIB_PATH so it should work regardless
***ChanServ sets mode: +o nckx
***nckx changes topic to 'GNU Guix ⚠️ CI server is being repaired ⚠️ | get Guix at https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.debian.net | Guix in high-performance computing: https://hpc.guix.info | This channel's logged: http://logs.guix.gnu.org | 1.1.0 is out! https://guix.gnu.org/blog/2020/gnu-guix-1.1.0-rele'
***nckx changes topic to 'GNU Guix ⚠️ the CI is being repaired ⚠️ | get Guix at https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.debian.net | Guix in high-performance computing: https://hpc.guix.info | This channel's logged: http://logs.guix.gnu.org | 1.1.0 is out! https://guix.gnu.org/blog/2020/gnu-guix-1.1.0-release'
***nckx changes topic to 'GNU Guix ⚠️ the CI is being repaired | get Guix at https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.debian.net | Guix in high-performance computing: https://hpc.guix.info | This channel's logged: http://logs.guix.gnu.org | 1.1.0 is out! https://guix.gnu.org/blog/2020/gnu-guix-1.1.0-release'
***nckx changes topic to 'GNU Guix ⚠️ the CI is being repaired | get Guix at https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.debian.net | Guix in high-performance computing: https://hpc.guix.info | This channel's logged: http://logs.guix.gnu.org | 1.1.0 is out! https://guix.gnu.org/blog/2020/gnu-guix-1.1.0-released/'
***ChanServ sets mode: -o nckx
<str1ngs>ArneBab_: I'll see if I can replicate this.
<nckx>roptat: Could you remove _IMAGE from the ISO label? I don't think it adds value and versions can get long.
<rekado_>str1ngs: it wraps GI_TYPELIB_PATH, but it doesn’t override it, does it?
<str1ngs>rekado_: I'd have to check if it concatenates an existing GI_TYPE_LIB_PATH but offhand I'd say no it doesn't. other wise it would loss functional packaging.
<str1ngs>rekado_: sorry for the rant. to answer your question better if the wrap did this it would loss functional package. export GI_TYPELIB_PATH="$GI_TYPLIB_PATH:/gnu/store/output...:/gnu/store/output" pseudo code.
<rekado_>str1ngs: it’s not always right. I think we’re too often picking “prefix” when “=” would have been better. We’ve been suffering with PYTHONPATH wrapping since forever, because the order of directories on that variable has not the obvious semantics that you’d think.