IRC channel logs

2021-05-04.log

back to list of logs

*nckx ret.
<nckx>cybersyn: So the package that fails to build is precisely that proprietary module, not the kernel itself (‘linux-module-builder’ is just a ‘build environment’ for modules). As you know we cannot provide support for the former here.
<cybersyn>for sure, thanks anyway
<nckx>--with-graft is working correctly, and by doing so works around/hides the fact that the two aren't actually compatible.
<cybersyn>is there anyway to use --with-graft within a configuration file?
<nckx>Not that I know, but I've never looked into it either.
*nckx → 😴 for realz now, 'night Guix.
<rekado_>cybersyn: you can write a package variant with that transformation
<rekado_>see options->transformation in the manual
<cybersyn>rekado_: thanks, "package variant" has brought up the info i was looking for, it seems :)
<vagrantc>do release tarballs always get uploaded to https://alpha.gnu.org/gnu/guix ? I see that the release candidates only seem to end up there, as opposed to ftp.gnu.or
<apteryx>vagrantc: the final release will go to ftp.gnu.org
<apteryx>The RCs go to alpha.gnu.org
<vagrantc>apteryx: only RCs go to alpha.gnu.org ?
<vagrantc>the short of it is, i guess, i'm trying to set up monitoring for new releases, and ideally that would only be a single location ... maybe i'll just poll the git tags instead
<cybersyn>hi all, i'm back, still have some issues building a package variant
<cybersyn>you know what, it just hit me what i forgot to do
<cybersyn>nm, i think i got it
<apteryx>vagrantc: yes, only RCs go to alpha
<apteryx>(AFAIK anyway :-))
<vagrantc>looks like older released also went to alpha.gnu.org ... but no big deal.
<sneek>Welcome back vagrantc, you have 1 message!
<sneek>vagrantc, apteryx says: I recently let mhw know about that decision, so they wouldn't be surprised when the change hits the patch tracker; they told me while they still disagree with it, it's a rather small thing in the bigger picture and they are ready to let it go.
<vagrantc>apteryx: yeah, that's the impression i got from mhw based on the various threads on the subject
***iyzsong- is now known as iyzsong
<apteryx>roptat: according to https://stackoverflow.com/questions/7447440/generating-list-of-generated-sources-a-la-foreach-in-automake, Automake does not understand GNU Make non-standard extensions :-/
<apteryx>sneek later tell roptat I tried something like: info_TEXINFOS = [...] $(patsubst %,\%D\%/$(MANUAL_LANGUAGES).%.texi,guix) but that also failed
<sneek>Got it.
<vagrantc>yay, the tarball for linux-libre was at least available for kernel build
<Noclip><nckx "Noclip: Can you elaborate on how"> Did you read my answers? What do you think?
<merazi>Hello guix!!!
<merazi>:D
<merazi>I've learned a looot since the last time I was here, I am taking my time to read the documentation ;)
<merazi>I was confusing the "services" with daemons of some sort :P I was *wrong*: http://guix.gnu.org/en/manual/en/guix.html#Services I'm so happy I had to tell you guys about it
<merazi>Well, I'll stop being annoying (lol) I hope you all have a wonderful rest of your day, or night ;D
<tissevert>hi guix !
<Noclip>Hey
<tissevert>while test building a package from the guix repos with ./pre-inst-env guix build, I get a lot of warnings about .scm files being newer than their .go counterparts (no kidding, I've just pulled to be sure I was up to date)
<tissevert>do you all have such warnings each time you test build a package ? if not what do you do to avoid it ?
<rekado>build the sources first by running “make”
<tissevert>ohhh
<tissevert>each time I pull, makes sense ^^'
<tissevert>oh no, I have to enter that environment again : )
<tissevert>make running, thanks !
<civodul>Hello Guix!
<efraim>hi!
<efraim>does anyone remember off-hand how to collect all the apache2 logs? just error_log isn't enough for me today
<efraim>^^ found some apache2 documentation https://httpd.apache.org/docs/2.4/logs.html
<abcdw>hi guix!
<karthik[m]>abcdw: hi
<karthik[m]>anyone here using guix on lenovo x230with non free wifi card?
<efraim>building for i686-linux on x86_64-linux is a regular build or a cross build?
<mekeor[m]>abcdw: hi!
<mekeor[m]>karthik: why do you ask? :D do you need help with a non-free wifi-card? :D
<mekeor[m]>efraim: sound like a cross-build for me (since i686 is 32-bit, afaik, and x86-64 is 64-bit architecture)
<karthik[m]>mekeor: yes. nongnu has it ?
<karthik[m]>BTW i found an old but useful info on guix https://news.ycombinator.com/item?id=16490027
<janneke>efraim: using --system it's a regular build, using --target it's a cross build
<sss>hi all, ldns examples should be installed into bin, or maybe separate package should be created fot them
<PotentialUser-81>Hello!
<PotentialUser-81>Friends, how is the pronunciation of "Guile"?
<fnstudio>PotentialUser-81: i think it rhymes with mile, the distance unit
*civodul did an RC1 install in a VM, with X11 and a bunch of things
<civodul>took ~20mn
<civodul>i think it's better than 1.2.0
<civodul>i wonder if Guix Data Service or ci.guix have stats about the duration of the installation tests
<civodul>cbaines: is it something we have in store? ↑
<rekado>karthik[m]: there’s also the 2019 version of that comment: https://news.ycombinator.com/item?id=19809366
<rekado>and an addendum from 2020: https://news.ycombinator.com/item?id=23529932
<PotentialUser-81>* Help!!
<nckx>Good morning, Guix.
<nckx>Noclip: I haven't forgot. I'll respond later.
<nckx>PotentialUser-81: Apart from ‘...and hard g as in good’, I think you've been helped?
<PotentialUser-81>nckx: Could you provide an ipa?
<PotentialUser-81>Please help!!
<nckx>- gaɪl
<nckx>- chillax.
<PotentialUser-81>nckx: Thank you very much!
<mekeor[m]>i have a server running guix system. suddenly, i can't run "su" or "sudo" successfully. although i can still login per ssh with a ssh-key. i'm pretty sure my password is correct. any idea whats happening?
<emacs-user57>Hi! I just reinstalled Guix and using EXWM. However, it's not using any of the emacs packages I downloaded before. I am using this on my .emacs (add-to-list 'load-path "/home/k/.guix-profile/share/emacs/site-lisp/")
<emacs-user57>I am using pdf-tools, nov.el, and modus-vivendi and none are working right now.
<emacs-user57>I also have (guix-emacs-autoload-packages) on my .emacs
<iyzsong>mekeor[m]: maybe the /var/log/secure (or auth) file say something? i think it could be pam related
<mekeor[m]>iyzsong: i set (use-pam? #f) for ssh. is that relevant?
<iyzsong>mekeor[m]: that may be the reason why only ssh works
<davidl>civodul: I tried linking /lib/ld-linux-x86-64.so to ~/.guix-profile/lib/ld-linux-x86-64.so.2 and start the AppImage file again, but the same result: bash: ./drawio-x86_64-14.5.1.AppImage: No such file or directory
<mekeor[m]>iyzsong: removing that option solved the issue. thank you so much! :)))))
<civodul>emacs-user57: hi! you installed these packages with Guix but they're not found when you evaluate (require '...)?
<emacs-user57>civodul: yes I installed all of thse using Guix -- it worked properly until I updated my Guix a few days ago.
<emacs-user57>I rolled back and it worked again
<emacs-user57>I'm trying to install Guix on a new computer but it's unable to find the packages
<civodul>emacs-user57: ah ha! i think there were changes a few days ago in this area, maybe leoprikler can comment
<civodul>could it be a missing EMACSLOADPATH or something?
<emacs-user57>How do I check?
<leoprikler>Hmm, what's the EMACSLOADPATH of EXWM
<emacs-user57>leoprikler: How do I find out?
<emacs-user57>Sorry new at this :-)
<nckx>davidl: For some reason this binary expects the loader in the old /lib64 location, not /lib.
<leoprikler>(getenv "EMACSLOADPATH")
<davidl>nckx: ok, Ill try again. How did u look that up though?
<nckx>Once you change that it will break properly, not finding zlib and other expected stuff.
<nckx>davidl: Honestly? ...I used the advanced binary introspection tool called ‘grep -ao’.
<leoprikler>(I hope EXWM lets you eval arbitrary elisp, I haven't used it)
<nckx>Because I always forget the proper way.
<emacs-user57>leoprikler: "/run/current-system/profile/share/emacs/site-lisp:/gnu/store/1zszglsxl4zxy9alcwxjwj26d30qmyv9-emacs-27.2/share/emacs/27.2/lisp"
<leoprikler>yep, that won't work
<leoprikler>you should set it up, so that your ~/.guix-profile/share/emacs/site-lisp is in there as well
<davidl>nckx: hm, that didn't fix it for me.
<davidl>nckx: same error.
<nckx>It did for me.
<davidl>did you symlink entire /lib64 to ~/.guix-profile/lib or just the ld-linux*.so file?
<emacs-user57>leoprikler: how do I set that up?
<nckx>davidl: I symlinked /lib64 → /lib just to test.
<emacs-user57>still a bit new to this
<leoprikler>I'm not sure either. Did you just freshly install your local emacs packages?
<nckx>davidl: And now ‘ldd drawio-x86_64-14.5.1.AppImage’ says it can't find zlib instead of claiming it's not a dynamic executable. So it works.
<emacs-user57>fresh install
<emacs-user57>guix pulled and everything
<leoprikler>In that case EXWM does not yet know about your Guix profile
<nckx>davidl: No, running it does, I got confused, but the gist is the same.
<leoprikler>it *should* work fine in subsequent sessions, but if you don't want to restart it yet
<emacs-user57>I rebooted it 3x already and it did the same thing. :-(
<nckx>davidl: *Then*, ‘LD_LIBRARY_PATH=$HOME/.guix-profile/lib ./drawio-x86_64-14.5.1.AppImage’ complains about fuse, and that's as far as my non-existent AppImage knowledge allows me to go. :)
<leoprikler>Okay, in that case it really is dumb
<emacs-user57>awww
<leoprikler>Where does EXWM read user config from?
<davidl>nckx: I just tried the same :)
<davidl>nckx: Im gonna try and install fuse now
<nckx>davidl: Did you try the manual work-around in the error message? I didn't.
<emacs-user57>leoprikler: it reads it from ~/.emacs
<emacs-user57>I haven't confirgured EXWM yet
<emacs-user57>using default config
<leoprikler>does it also accept the newer stuff (like init.el in XDG_CONFIG_HOME and early init?)
<nckx>guix install fuse → retry → ‘execv error: No such file or directory’ 😒
<emacs-user57>leopreikler: haven't changed it from .emacs to init.el
<emacs-user57>I'll try it
<leoprikler>Use whichever you want, but it's probably helpful to think about load order
<nckx>Er, why does drawio.appimage bundle an entire Web browser (chrome)?
<leoprikler>sneek later tell emacs-user57 you want to push "~/.guix-profile/share/emacs/site-lisp" to load-path and then load "~/.guix-profile/share/emacs/site-lisp/subdirs.el"
<sneek>Will do.
<leoprikler>sneek later-tell emacs-user57 be careful to appropriately expand "~"
<leoprikler>sneek later tell emacs-user57 be careful to appropriately expand "~"
<sneek>Got it.
<leoprikler>sneek botsnack
<sneek>:)
<emacs-user57>leorprickler unfortunately didn't work
<sneek>Welcome back emacs-user57, you have 2 messages!
<sneek>emacs-user57, leoprikler says: you want to push "~/.guix-profile/share/emacs/site-lisp" to load-path and then load "~/.guix-profile/share/emacs/site-lisp/subdirs.el"
<sneek>emacs-user57, leoprikler says: be careful to appropriately expand "~"
<emacs-user57>how do I load this on the terminal?
<emacs-user57>or push it?
<leoprikler>does EXWM allow you to eval arbitrary elisp at runtime?
<emacs-user57>how do I check?
<emacs-user57>I only use default EXWM config
<leoprikler>Don't ask me, I'm not even an EXWM user
<emacs-user57>ah ok
<emacs-user57>I put these on the .emacs file
<emacs-user57>;; Ensures that Guix sees and loads packages installed
<emacs-user57>(add-to-list 'load-path "/home/k/.guix-profile/share/emacs/site-lisp/")
<emacs-user57>;; Autoloads packages in that folder
<emacs-user57>(guix-emacs-autoload-packages)
<emacs-user57>and usually it works
<emacs-user57>after the latest update somehow the emacs pacakages installed via Guix don't work for some reason
<leoprikler>that's because load-path is no longer correct
<leoprikler>before (guix-emacs-autoload-packages), you need to load subdirs.el
<leoprikler>that's the difference
<emacs-user57>ah
<davidl>nckx: sudo LD_LIBRARY_PATH=/home/user1/.guix-profile/lib ./drawio-x86_64-14.5.1.AppImage
<davidl>which gives: /tmp/.mount_drawioYmDitg/drawio: error while loading shared libraries: libnss3.so: cannot open shared object file: No such file or directory
<emacs-user57>leoprickler: what should I put there?
<emacs-user57>leoprikler: what should I put there?
<nckx>davidl: I can't get it to find libnss3.so despite using ‘LD_LIBRARY_PATH=$(guix build nss)/lib/nss’, I'm obviously missing something obvious.
<davidl>can't find which - if any - libnss file I should possibly symlink to - there are multiple like libnss_files.so, libnss_hesiod.so etc.
<leoprikler> http://paste.debian.net/hidden/d732832d/ this one ought to work
<davidl>nckx: so am I, but now Im gonna take lunch :)
<nckx>davidl: Just libnss3.so.
<leoprikler>for backwards compatibility, you might want to check if subdirs.el exists, but I leave that as an exercise to the reader
<nckx>It's in /lib/nss.
<nckx>But libnss3.so => not found and I don't get why.
<nckx>I even copied it to /lib out of spite but it still fails 🤷
<emacs-user57>leoprikler: will reload and try that out. :-)
<civodul>davidl: if you're using a channel with packages that contain AppImages, you might want to discuss it with the channel authors
<civodul>it's a very unusual approach
<nckx>Now I get the dreaded ‘error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory’.
<nckx>Fontconfig error: Cannot load default config file: No such file: (null) → Trace/breakpoint trap
<emacs-user57>leoprikler: it works! Thanks!
<emacs-user57>you saved my eyes
<emacs-user57>lolz
<leoprikler>np :)
<leoprikler>it's still weird, that EXWM doesn't see your guix profile normally
<emacs-user57>it was -- it just happened right after I did a guix pull, etc.
<emacs-user57>from black themed exwm to pure white
<emacs-user57>after reboot
<emacs-user57>then I tried it on a different computer and it never got back to black theme
<emacs-user57>none of the guix installed emacs packages worked as well
<emacs-user57>but now they do! :-)
<leoprikler>I still think, that EXWM should source your guix profile before the Emacs process itself starts, so that such hacks are not needed
<leoprikler>but that'd be more complicated
<emacs-user57>maybe something happened with the new verison of EXWM?
<emacs-user57>good thing there's always a roll-back in Guix
<leoprikler>nah, you had a workaround before
<emacs-user57>however for new installs they will have to find out the way I did
<leoprikler>you just had to adjust that workaround for the new site-lisp layout
<emacs-user57>my concern is with the new Guix coming out on May 10th, new users tryingout EXWM may have some concerns
<leoprikler>yeah, I don't think our EXWM story is particularly good
<emacs-user57>maybe include this in cookbook?
<leoprikler>I'll maybe write up a proper bug report later, but for now I'm going to eat
<emacs-user57>happy eating! Thanks again.
<srji>at the installation i got asked if i want to use pre-builded packages
<srji>i decided no
<srji>how can i change it afterwards?
<rekado>srji: after the installation you can authorize the build farm key.
<rekado>but note that the installation will take a very long time without pre-built packages.
<srji>thats why i want to use the build farm
<efraim>srji: https://guix.gnu.org/manual/devel/en/html_node/Substitute-Server-Authorization.html
<srji>ok ty
<emacs-user57>Looks like there are others using EXWM and Guix having the same problem as I https://github.com/ch11ng/exwm/issues/819
<leoprikler>emacs-user57: Are you still here?
<srji>guix pull: error: Git error: the SSL certificate is invalid
<efraim>do we have a quick way to grab x86_64 from x86_64-unknown-linux-gnu?
<efraim>I can parse it but I'd rather reuse a function
<leoprikler>I think there are some triplet conversion functions
<davidl>civodul: Ok. Im not doing that. I just downloaded an AppImage and tried to start it.
<leoprikler>efraim: gnu-triplet->nix-system should yield "x86_64-linux", but that's probably still a bit too much
<efraim>actually I think I can just override it and use 'custom'
<srji>solved ssl error
<efraim>leoprikler: gnu-triplet->nix-system is probably want I want anyway for my go cross compile patch
<leoprikler>Other than that, it seems checking with string-prefix? is the way to go
<efraim>nope, using 'custom' failed. I'll grab the first part
<efraim>yeah but I'm not checking, I just need the string
<efraim>(let ((triplet (gnu-triplet->nix-system))) (string-take triplet (string-index triplet #\-)))
<nckx>davidl: To be clear, we don't currently support binary blobs compiled for other distributions at all. Getting this thing to run is best-effort and might not be possible yet.
<nckx>I'm not sure if the fontconfig error is the fatal one or if it's due to the fact that I tried some random libgcc_s's I had lying around and the ABI is wrong.
<civodul>roptat: hey! did you see the thread on Guix Home upstreaming? what are your thoughts?
<rekado>I’m itching for a tlpdb-based texlive importer…
<apteryx>rekado: eh :-)
<roptat>civodul, yes I've seen them, I think that's exciting :)
<sneek>Welcome back roptat, you have 1 message!
<sneek>roptat, apteryx says: I tried something like: info_TEXINFOS = [...] $(patsubst %,\%D\%/$(MANUAL_LANGUAGES).%.texi,guix) but that also failed
<civodul>roptat: ah good, i like it too! i was wondering what you thought
***alendvai__ is now known as attila_lendvai
<davidl>nckx: sure, I understand. I am stuck now because I need the libatk-bridge package which doesn't exist.
<davidl>nckx: this is where Im at now: sudo LD_LIBRARY_PATH=$(find ~/.guix-profile/lib -maxdepth 1 -type d | xargs | tr -s ' ' ':'):$(find ~/.guix-profile/lib -maxdepth 1 -type l | xargs | tr -s ' ' ':') ./drawio-x86_64-14.5.1.AppImage
<davidl>/tmp/.mount_drawioMaOcLR/drawio: error while loading shared libraries: libatk-bridge-2.0.so.0: cannot open shared object file: No such file or directory
<bone-baboon>I have a substitute server that has python and gnutls built on it. But when a client does `guix pull --substitute-urls=<my-substitute-server>:<port>` it starts building python and guntls. The substitute server was started with `--cache-bypass-threshold=<size-of-substitute-server-hard-drive>`. On a substitute server after building a package is there a command I can use to add that package to the substitute server's cache?
<civodul>bone-baboon: hi! the first step would be to check whether the Python/GnuTLS being built really are the same as those available on the server
<civodul>if you run with -v3, their store file name will be displayed
<civodul>then you can check whether it exists on the server
<civodul>next, you can check what 'guix publish' replies using wget
<civodul>as in: wget -O - http://example.org/XYZ.narinfo
<civodul>where XYZ is the base32 base string of what you're looking for, like 3p90d676sxxhcpn8a1hxyz9j66rjd23f
<civodul>which comes from "/gnu/store/3p90d676sxxhcpn8a1hxyz9j66rjd23f-indent-2.2.12"
<bone-baboon>civodul: Thank you I am checking that now.
<liltechdude>Hello guys! How I can on the 'install' stage without Automake install info files?
<bone-baboon>civodul: In the output of `wget -O - http://example.org/<gnutls-hash>.narinfo` is StorePath: /gnu/store/<hash>-gnutls-3.6.15.drv. It also lists gzip, zstd and lzip. The store path in the substitute servers response matches what `guix pull --substitute-urls=<...> -v3` said was being built on the client computer.
<rekado>liltechdude: you don’t need automake to install info files.
<rekado>you need automake only to build the makefile
<civodul>bone-baboon: looks like <gnutls-hash> is the hash of the gnutls-3.6.15.drv, where it should be the hash of gnutls-3.6.15 (without ".drv")
<liltechdude>rekado: okay, I have 'texi' file, how I can (or where should read about this) install this files as info pages?
<rekado>liltechdude: I need a bit more context. Is this for Guix or for some other package? It depends on what machinery you have. If there’s a texi file there’s likely also a build system target to turn that into an info file.
<roptat>liltechdude, if you have a Makefile, you can usually call "make whatever.info" to turn whatever.texi into that info page, otherwise you can also manually call makeinfo
<bone-baboon>civodul: I also get a wget response from the substitute server with a store path matching the hash for /gnu/store/<hash>-gnutls-3.6.15 (which I found in the pull -v3 output) which has a different <hash> than the ...-gnutls-3.6.15.drv
<roptat>liltechdude, sorry, actually I'm not sure I gave you an answer to your question, I'd like to get more context. Is that guix's own git repo, one of your project, or a guix package you're trying to make? or something else?
<liltechdude>rekado: This is my toy project for learning texinfo https://git.sr.ht/~liltechdude/gnu-guide/tree
<liltechdude>all i want is get info page in emacs after `guix build -L . lil-gnu-guide`
<Maskude>I want to use (service alsa-service type) without using the default pulseaudio. Is there a way to do this?
<Maskude>I mean to ignore pulseaudio package in /etc/config.scm
<roptat>liltechdude, to build it you can run "makeinfo guide.texi" (add this to a "guide.info" target to your Makefile)
<roptat>then to install it, uncomment your install target, and add something like #:make-flags (list (string-append "infodir=" (assoc-ref %outputs "out") "/share/info/")) to your recipe
<roptat>Maskude, there's a pulseaudio? field in alsa-configuration, does that help?
<roptat>you'd specify something like (service alsa-service-type (alsa-configuration (pulseaudio? #f)))
<roptat>(well if that's what you want, I'm not sure I understand your question)
<liltechdude>roptat: install: target '/gnu/store/39zdfv6aqdaq4y5dv961kvy2gd9170y3-lil-gnu-guide-0.0.1/share/info/' is not a directory: No such file or directory. Should I create folder or not?
<roptat>liltechdude, yes, in the makefile
<roptat>something like mkdir -p $(DESTDIR)/$(infodir)
<liltechdude>roptat: hmmmm, file does not apperearing in info mode, but exist in /gnu/store/biqc6j4nra3iyjiwrcg2yhr4ca79x2fw-lil-gnu-guide-0.0.1/share/info
<roptat>liltechdude, right, you installed the info file, but probably nothing in your environment points to it
<liltechdude>but i write guix install
<liltechdude>after guix build
<roptat>do you have info in your profile?
<roptat>that would be needed to make sure guix generates the right variable
<liltechdude>roptat: no, info not in profile
<roptat>you either need it, or set INFOPATH manually
<roptat>(info-reader)
<liltechdude>oh, I supposed that after installing all thing would automatically werks
<liltechdude>maybe in some recipe all thing like updating system variables already done?
<roptat>no, when you install a package, guix will update etc/profile according to what's in your profile: to have a variable definition, you need a package that defines that variable (like texinfo or info-reader), and a package that provides at least a file that creates that path
<roptat>so to set INFOPATH, you need info-reader to provide the definition, and your package to provide a manual so the definition is present in etc/profile
<roptat>then you need to reload. In your current terminal, you can temporarily set the variable with ". $HOME/.guix-profile/etc/profile"
<roptat>you can also inspect the file, or the output of "guix package --search-path"
<civodul>apteryx: i took a stab at NEWS!
<civodul>i'll commit what i have
<liltechdude>roptat: info-reader must be native-input for package, right?
<roptat>liltechdude, no, it must be in your profile, it has nothing to do with your package
<roptat>just guix install info-reader
<roptat>or set INFOPATH manual
<roptat>manually
<liltechdude>after reloading nothing changed :(
<roptat>what's your $INFOPATH?
<liltechdude>/home/lil/.config/guix/current/share/info:/home/lil/.guix-profile/share/info:/run/current-system/profile/share/info:/home/lil/.guix-profile/share/info:/run/current-system/profile/share/info
<roptat>looks good
<roptat>you don't have a @setfilename in your texi file, I think that might be an issue
<mbakke>is there an easy way to install a gexp through a manifest?
<roptat>mbakke, https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/manifest.scm
<roptat>you can create a manifest-entry that contains a file-like object (so, a computed-file that contains a gexp)
<mbakke>roptat: thanks!
<mbakke>not sure about "easy way", but it will do ;)
<liltechdude>roptat: I'am update files https://git.sr.ht/~liltechdude/gnu-guide
<liltechdude>and still it not werks (not have symlink in share/info)
<roptat>you installed the new package in your default profile, right?
<liltechdude>yes, new
<roptat>so you should have $HOME/.guix-profile/share/info/guide.info, right?
<liltechdude>yes
<roptat>er, your makefile is weird, I don't think it'll work on clean sources (but you don't build from clean sources)
<roptat>now, does "info guide" work?
<liltechdude>heh
<liltechdude>yes
<roptat>so that's an issue with emacs, and I don't know anything about emacs ^^'
<liltechdude>thank you for your help very much
<roptat>stikonas[m], I tried updating our ecj bootstrap, but there are still a few things I don't understand
<roptat>stikonas[m], from the ebuild, I see you separate the source into 1.4 and 1.6, but how do you get a compiler for 1.6 at this point of the bootstrap?
<roptat>or is it enough to build the part written in java 4, to build the part written in java 6?
<lfam> https://www.qubes-os.org/news/2021/03/19/qsb-067/
<lfam>Package signature bypass in RPM 6
<lfam>I mean, in RPM ^
<lfam>There's no "6" involved
<lfam>It's interesting, the two major Linux package managers, RPM and apt, have both been shown to not perform package signature verification properly, and it's happened multiple times
<lfam>We should probably try doing this kind of thing with Guix
<lfam>It also shows that security doesn't really matter for user adoption
<Skadena>Where is fonts directory located in guix system? /usr/share/fonts in other distros.
<lfam>Skadena: Take a look at this: https://guix.gnu.org/manual/devel/en/html_node/Application-Setup.html#X11-Fonts
<Skadena>Ifam thanks i should have looked there first ^__^
<lfam>I'm not sure about fonts installed at the "system" level via config.scm. I'd expect them to be within /run/current-syste
<lfam>I mean, /run/current-system
<Skadena>ok i'll take a look
<liltechdude>roptat: this is my mistake (I must include section in texi file that say to emacs how to display file in info dir page)
<bone-baboon>I am trying to run `make` it the Guix repository. I am getting a command not found error for po4a-transalate. There are no search results for `guix search po4a-transalate`. What package provides po4a-transalate?
<roptat>po4a
<roptat>it should be there if you use guix environment guix
<bone-baboon>roptat: Thank you. I am insterested more generally in how I could figure out what package provides a program if I can not find it with `guix search <program-name>`.
<roptat>there's no way :/
<roptat>usually I try something like ls /gnu/store/*/bin/po4a-translate for instance, or I just know the name of the package
<bone-baboon>roptat: Thanks. That ls approach would only work if you already had the package built or installed but would not work if the package is not already on the system?
<roptat> yes
<bone-baboon>When I run `make` in the Guix repository is there a way to make the documentation for only one language for example English?
<roptat>no, the default target depends on all the languages
<bone-baboon>roptat: Thanks
<lfam>Pity we missed this for string freeze: <https://bugs.gnu.org/46956>
<bone-baboon>%base-packages is defined in the Guix repository in gnu/system.scm. There are packages that are part of %base-packages and that have names that do not match what can be found with `guix search`. They are (%base-packages name, guix search name): (iproute, iproute2), (guile-3.0-latest, guile), (util-linux+udev, util-linux-with-udev). I am unable to build the %base-packages package names with `guix build` but I can build the
<bone-baboon> name counterpart. Could someone explain the rationale for this?
<lfam>It's the difference between Scheme variable name and package name
<lfam>The rationale is that we don't always want those names to be the same. For example, we have several packages named "linux-libre", the difference being their versions. The variable names are how they are distinguished at the code level
<bone-baboon>lfam: Thank you
<nij>Hello! Is there a lispy systemd.timer equivalents on guix? I don't find anything by searching herd.timer..
<roptat>mcron?
<nij>I hope that.. but does it capture all outputs/errors from the program? What does it do if it skips a task because the machine is off?
<roptat>no idea
<nij>Based on https://www.gnu.org/software/mcron/manual/mcron.html#Behaviour-on-laptops
<nij>It seems that it only handles the "recovering from suspended state" correctly.
<nij>systemd.timer logs as many things as possible.. but I don't see things like that in mcron's manual.
<nij>Without a comprehensive log, I am not sure if it can tell if it has misses some important job.
<raghavgururajan>Hello Guix!
<nij>Hi :)
<andreas-e>Hello raghavgururajan!
<mhj[m]>HI hi guix, upgrading right now. So far everything is going smoothly!
<mhj[m]>Then after I reboot into the new system, gonna play some Streets of Rage 2 in RetroArch :D
<nojr>hello :)
<nojr>I' ve installed monero-gui on a foreign distro via guix
<nojr>I can't run it though and can't find the executable in my system, has anyone had this issue? I've had the same problem with librecad
<nojr>but at least I could run via the command line, monero-gui is installed but cannot be invoked via the launcher or in the command line prompt
<mhj[m]>Is it in your path? Check for Guix path with "echo $PATH" maybe?
<nojr>mhj[m]: nope
<mhj[m]>Hmm
<nojr>honestly, I've had many issues with GUI programs in a foreign distro :/
<nojr>all sorts of errors that's why I don
<nojr>t have many installed only Emacs
<roptat>you'll have to make sure there's ~/.guix-profile/bin in your $PATH
<nojr>roptat: yup it's there
<roptat>so how did you install monero-gui, and where is its binary?
<nojr>roptat: $ guix package -i monero-gui
<nojr>no idea, I can't $ which monero-gui
<nojr>$ guix package -i monero-gui again and returns
<lfam>Depending on which "launcher" you're using, maybe it has to be taught where to look for packages installed by Guix
<roptat>ok, give me a minute, I'm downloading a substitute
<nojr>The following package will be upgraded: monero-gui (dependencies or package changed) nothing to be done
<lfam>nij: Shepherd and mcron are still very simplistic compared to systemd. I want them to be improved to reach parity, especially in terms of logging
<nojr>lfam: stock ubuntu 20.04 ??
<roptat>nojr, monero-wallet-gui probably, not monero-gui
<roptat>nojr, I mean, you've installed monero-gui, and it contains a binary called monero-wallet-gui
<roptat>so run monero-wallet-gui instead of monero-gui
<nojr>roptat: hehe yeah that worked, hmm how did you find out it was monero-wallet-gui?
<lfam>nij: That is an (unstated?) goal of shepherd: to offer a system management interface that rivals systemd in it's utility and sophistication
<lfam>But, now we have to actually do that work :)
<roptat>nojr, ls $(guix build monero-gui)/bin
<nojr>roptat: thanks! that's useful
<roptat>you could also have found with something like monero<tab>
<roptat>to autocomplete :)
<roptat>(well two tabs to give you the list of possibilities, since there's also monerod)
<davidl>Anyone here who happens to know which package may contain libgcc_s.so.1? Or can make an informed guess among any of the following packages: libgcc\* gcc\* libstdc++\* libgfortran\* libgcj\* libgomp\* libtool cpp
*davidl trying to install glibc
***iskarian_ is now known as iskarian
<lfam>david1: The "lib" output of the GCC package provides
<lfam>it
<iskarian>davidl, should be gcc (specifically, the lib output)
<lfam>I'm grateful that our CVE-2021-27851 has finally been recorded in the canonical database: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27851
<drakonis> making history eh?
<lfam>Making the history books anyways ;)
***grumble is now known as Guest31287
***gurmble is now known as grumble
<andreas-e>lfam: How do you get the gcc:lib package? Is it not all hidden in gcc-toolchain, without the lib output?
<lfam>andreas-e: You can pass the Scheme expression directly to `guix build`. Like, `guix build --no-grafts --expression='(@@ (gnu packages gcc) gcc)'`
<andreas-e>Ah, thanks! This is the syntax I do not manage to memorise...
<lfam>With that, you can build hidden-packages, or packages that are simply not defined publicly
<andreas-e>Although it is not that complicated; in hindsight, I tend to forget that I need a double "@@".
<bavier[m]>I'm getting a "permission denied" when building the guix-manual derivation for 'guix pull' just now.
<bavier[m]>anyone else?
<lfam>Hm, I just ran `guix pull` on Guix System and it seemed to work okay
<lfam>That was for commit 4ca8a002633f5d5c88c689fd41a686b5cdff33ec
<bavier[m]>hmm, same commit for me.
<civodul>lfam: re CVE, nice it eventually happened
<civodul>and yeah, too bad we missed the patch documenting mirrors
<lfam>It took a lot of asking and reminding various organizations to get the CVE done
<lfam>I'll probably stop doing CVEs after this
<civodul>bah, that's terrible
<lfam>I don't think the system is going to keep working for anyone that's not a CNA
<lfam>We even got mentioned on LWN: https://lwn.net/Articles/851849/
<lfam>Well, we got linked to, if not mentioned by name
<lfam>We could even start our own ID system, like GNU-VULN-0000
<apteryx>nckx: I've investigated a bit the /etc/profile(.d),/etc/environment(.d),etc situation w.r.t. how the non-standard variables are made available when commands are sent non-interactively via SSH. It's a rather complicated situation. The way Guix System does it itself is rely on 1. build time optional feature of bash (-DNON_INTERACTIVE_LOGIN_SHELLS) to source ~/.bashrc when invoked from sshd 2. On a
<apteryx>fragment of .bashrc sourcing /etc/profile, which does the heavy lifting.
<apteryx>we can't rely on 1. on foreign distribution (chances are Bash is not built with that feature)
<apteryx>/etc/environment, if present, would probably be used, but then its not a script and cannot handle sourcing other files such as $HOME/.guix-profile/etc/profile
<apteryx>a way that should work on foreign distributions right now with a guix-install.sh install guix is to have the environment correctly is to force the command through a 'login' shell, like so: 'ssh remote sh -l -c "guix describe"'; that should take care of sourcing the /etc/profile.d/guix.sh script
<bavier[m]>oh hey, just a friendly report that I just used the 1.3.0 rc installer image to reinstall and boot up my system. Seems to be working alright so far. :)
<lfam>Great :)
<lfam>Any idea about that `guix pull` permission denied error?
<davidl>iskarian: ok thanks, though how do I install it? gcc-toolchain appears to depend on it, but Im not able to simply run guix package -i gcc:lib as it switches to gcc-toolchain automatically..
<bavier[m]>a small annoyance in the installer, though: I chose the "manual install" method, if I switch to tty2 to read some docs, then switch back to tty1, I have to re-select the "manual install" option to get back to the terminal I was in.
<bavier[m]>lfam: no ideas yet, looking more now.
<davidl>iskarian: I also have gcc-toolchain installed already but can't find the libgcc_s.so.1 file in my ~/.guix-profile
<davidl>iskarian: ok, thanks to lfam's comment above I was able to install it similarly with: guix package -e '(@@ (gnu packages gcc) gcc)'
<lfam>davidl: Depending on what you're trying to do, you may want to use gcc-toolchain instead
<davidl>lfam: how would I specify only the :lib output in this syntax '(@@ (gnu packages gcc) gcc)'
<lfam>The GCC package is hidden for a reason
<lfam>You can't davidl
<lfam>Installing the GCC package on Guix is not really supported
<davidl>lfam: ok. I am trying to run an AppImage and for it I need shared libraries.
<lfam>Okay
<lfam>I don't know how to make that work
<lfam> https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-build.html
<davidl>lfam: It is just an ugly hack. I do this: sudo LD_LIBRARY_PATH=$(find ~/.guix-profile/lib -maxdepth 1 -type d | xargs | tr -s ' ' ':'):$(find ~/.guix-profile/lib -maxdepth 1 -type l | xargs | tr -s ' ' ':') ./drawio-x86_64-14.5.1.AppImage and I get this;
<davidl>/tmp/.mount_drawio0ZyWKF/drawio: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory
<lfam>"Alternatively, the --expression option may be used to specify a Scheme expression that evaluates to a package; this is useful when disambiguating among several same-named packages or package variants is needed. "
<lfam> '(@@ (gnu packages gcc) gcc)' is a package; the lib output of the GCC package is not a package
<lfam>So, you can't use that syntax in that way
<davidl>lfam: I vaguely remember having specified a package output in a package declaration input fields.
<lfam>Yes, that's possible
<davidl>lfam: but that wouldn't work here or?
<lfam>It's a different thing
<lfam>When you do `guix build --expression='(@@ (gnu packages gcc) gcc)'`, you are telling Guix to build the package that expression evaluates to
<lfam>It only accepts packages. You can't do `guix build gcc:lib` either
***iskarian_ is now known as iskarian
<iskarian>ah, these disconnects are killing me
<davidl>lfam: ok. So basically, do you know if there is any way at all to install the lib output of gcc in a convenient way, or do I need to write a package module and redefine the package with (define-public ... ?
<lfam>I would just install the GCC package, but I still don't think it's the right thing to do here
<lfam>Like I said, we hid that package because it doesn't work on its own
<lfam>You need to use gcc-toolchain
<lfam>Additionally, the error message "error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory"
<davidl>lfam: I did, but still find ~/.guix-profile -iname '*libgcc*' does not give me the file I was looking for: libgcc_s.so.1
<lfam>I don't know how to make binaries compiled for other operating systems work on Guix
<lfam>There are some hacks to make it work, but I don't know them
<lfam>They are expecting many things to be in certain places, but Guix does not provide them
<davidl>essentially, AppImages are supposed to work on their own, but shared object files are hardcoded to /lib and /lib64 which I have symlinked to ~/.guix-profile/lib, though I still need the shared object files installed in ~/.guix-profile/lib
<lfam>I vaguely remember somebody using the extra-special-file service to provide the Guix linker / loader in the expected location, and binaries compiled for other operating systems worked (or almost worked)
<lfam>Right, AppImages and all the other "app bundles" are not actually self-contained
<lfam>They still expect a standard old-school Linux environment
<iskarian>honestly probably easier to run them in a lxc running a more standard environment
<lfam>Yes
<davidl>lfam: what are the thoughts on supporting a package or a service that sets up symlinks in the right places that make these bundles work? For example, if AppImages generally require fuse and symlinks from /lib and /lib64, an AppImage service could provide the installation of fuse and special-files-service (or whatever that thing was called).
<Noisytoot>nckx, It's been over 2 weeks since I posted https://issues.guix.gnu.org/47682, could you apply it?
<lfam>It's going to be a hard sell, asking us to make a service that allows using pre-compiled binaries
<lfam>It's not really in the spirit of the thing
<davidl>hehe, yeah
<davidl>true
<lfam>If I could remember that extra-special-files hack in more detail, I'd share it
<lfam>I'm trying to dig it up now
<davidl>lfam: (define %my-special-files
<davidl> `(("/bin/bash" ,(file-append bash "/bin/bash")))
<lfam>Maybe this helps: https://logs.guix.gnu.org/guix/2020-07-01.log#204301
<davidl>and (service special-files-service-type %my-special-files
<davidl>lfam: awesome, thanks
<lfam>It's not what I was looking for but it's related
<davidl>now the question is still where libgcc_s.so.1 exists.
<davidl>General question to guix maintainers: patch review order policy? My patch submissions are generally pretty small, but when I do work on a patch and submit it, I have no idea about when or if it will actually be reviewed. So far, the majority of patches I have sent have been reviewed, but when it takes a while like 2 weeks or more, I am concerned that my efforts have been wasted and I don't think Im the only one. If there was a policy and you could just
<davidl>say something like "currently there is 2 weeks backlog but we are working on it", it would feel like the risk of me wasting my time is much smaller.
<lfam>:/
<lfam>There's no policy at all davidl
<civodul>davidl: hi! it's a question to all committers, not just maintainers
<civodul>but yes, it can be frustrating
<civodul>we do our best, but it's hard to keep up
<lfam>It's something I wanted to bring up after the release
<lfam>It seems to have grown out of control
<civodul>also right now several of us are focusing on the release, which doesn't help
<civodul>yeah
<davidl>Im sure you all do, and Im very thankful. I love this project :-)
<lfam>It really doesn't hurt to find somebody who's touched the same code before, or similar packages, and ping them to ask for review
<lfam>We don't want the process to be difficult or require, like, a social investigation of the project. But that's kind of the reality currently
<davidl>lfam: Ok. I feel like I would be pushy and bothersome if I pinged people to review my patches (which I have done some time), but if that's what's suggested maybe I will try that more often.
<lfam>There's a good chance your patches won't get reviewed otherwish
<lfam>otherwise
<lfam>I'll say this: I never look at emails that are older than a month or so
<lfam>So, if a patch didn't get reviewed for more than a month, I'm never going to look at it
<lfam>That's just me
<lfam>Maybe it's the wrong approach but it's what happens
<davidl>lfam: ok. I had a package I worked on which required probably 20+ packages to 2 different package modules, but then to submit I would need to split the commits up in separate packages carefully, but so I never did because I was worried it would never get reviewed anyway.
<lfam>Right
<lfam>I recommend finding somebody to collaborate with
<lfam>A committer: https://savannah.gnu.org/project/memberlist.php?group=guix
<lfam>Somebody who seems to have worked on related packages before
<davidl>lfam: thanks. So maybe for now, the best thing is to ask someone before working on a patch-set, whether they're up for reviewing it once it's ready. I don't think it's a great solution. I guess the project just needs more full-time maintainers who can review patches. In a way it's a good sign of interest in the project though, that there are more patches sent than can be committed :-)
<lfam>To clarify: maintainers are not the same thing as committers
<lfam>There are only 5 maintainers and they aren't directly responsible for code review
<davidl>lfam: ok I see.
<lfam>I agree we need more people reviewing but it's not easy to make volunteers do this task
<lfam>There are several dozen committers, however. And code review can even be done by non-committers, and I do value that kind of code review as a committer
<apteryx>nckx: re /etc/environment, perhaps the statu quo is not that bad after all; we *could* migrate the content of /etc/profile.d/guix.sh to /etc/environment.d/guix at least on systemd machines, with the exception of sourcing $HOME/.guix-profile/etc/profile, which seems like a deal breaker to me (it will work for some applications and then not for others, because some environment variable will be missing)
<lfam>Code review is pretty hard work, requiring strong level of focus on technical matters, a sense of "what's cooking" in related code, and emotional resilience
<lfam>davidl: Something you can do to improve your chances with code review are to say whether or not the packages build or not, pass lint or not, work for your use case or not, etc
<lfam>It's surprisingly common to apply patches for review and see that these tasks have apparently not been performed. And that's demotivating
<bavier[m]>seconded.
<davidl>lfam: Ill put it in the subject header :-)
<lfam>It's okay to send patches that are not complete, but it's important to say so
<davidl>in the future.
<davidl>gonna look like [PATCH 0/22] <subject> (btw. passes lint test and builds!
<lfam>Yeah, or even in the email
<lfam>`git format-patch` and `git send-email` have the options --cover-letter and --annotate
<lfam>Or you can just write in the commit message. The reviewer will remove that part
<lfam>Whatever works for you
<davidl>lfam: sure. Thanks for your suggestions. It's appreciated.
*davidl afk
<chikamungus>Hi lovelies! I understand xorgs settings are meant to be set by gdm or whatever login manager but in my autogenerated config.scm from my install, the xorg-configuration keyboard-layout is set in xfce-desktop-service-type in the services section. Why is that? I want to get my head round what is going on before I add some needed extra xorg config stuff
<iskarian>efraim, in your gccgo > go patch from a few years ago, you suggest that go wants to be built with the gcc from the gccgo build... do you recall where you found that info (or, by trial & error)?
<iskarian>chikamungus, I'm pretty new to system configuration as well, but perhaps see https://guix.gnu.org/en/manual/en/guix.html#Keyboard-Layout and https://guix.gnu.org/en/manual/en/guix.html#X-Window from the manual?
<iskarian>I've never seen it in e.g. xfce-desktop-service-type, though I have seen it in alternate dms like slim-service-type
<iskarian>My understanding is that you either put a (xorg-configuration (xorg-configuration (keyboard-layout ...)) in the DM service, or you add a separate service (set-xorg-configuration (xorg-configuration (keyboard-layout ...)) which will communicate that to whatever DM exists
<nckx>davidl: git send-email tip: you can write whatever you want under the first ‘---’ and git will not include it in the commit message. Saves reviewers some work compared to having to remove ‘Hi! etc.’ manually from an otherwise perfect commit message, which of course you will write.
<chikamungus>thanks iskarian, that's useful. My worry is if it's put in xfce-desktop-service, it won't be set in other desktops and it seems a strange thing for the graphical installer to do
<chikamungus>as it is, it's a us keyboard layout which is probably what xorg would default to anyway
<nckx>Does xfce-desktop-service-type provide a display manager?
<nckx>chikamungus: Can you share the auto-generated configuration? I'm curious.
<chikamungus>You know what, I'm reading the scheme all wrong and I'm being daft
<nckx>😃
<Gooberpatrol66>I'm following this https://guix.gnu.org/manual/en/html_node/Invoking-guix-container.html and I get "no such process" when running guix container
<Gooberpatrol66>guix container exec 9001 /run/current-system/profile/bin/bash --login
<Gooberpatrol66>guix container: error: no such process 9001
<chikamungus>Sorry to waste your time but in asking the question, I've started to understand a bit better. It's been a while since I lisped!
<nckx>You didn't.
<Gooberpatrol66>Does anyone know what the PID "should" be?
<nckx>Gooberpatrol66: You can't choose a PID you like. It has to exist. Is there a PID 9001 running on your system (created with guix environment or guix system)?
<Gooberpatrol66>it has to exist before the container is launched?
<nckx>No, it is the PID of the container created by those commands.
<davexunit>you start the container with one command, then run another command to exec something
<davexunit>it's a rather primitive tool. there isn't a management daemon like, say, docker.
<Gooberpatrol66>ok thanks
<nckx>OIC, you thought ‘guix container exec’ created containers.
<davexunit>back in 2015 I figured I might improve this tool some day... oopsies
<nckx>Try something like ‘guix system container /my/system.scm’ and run the resulting script. Then look up the PID of that script using you favourite process manager. Then use ‘guix container exec <PID> <COMMAND>’.
<nckx>I tried it, it still works.
<nckx>Pretty nice for a primitive tool, davexunit!
<nckx>Gooberpatrol66: I had to use ‘sudo’ for both (so make sure you don't use sudo's PID, but the child's, I guess), probably because I don't have unprivileged nonsense enabled.
<jonsger>can I pull from a local git repo? like on my computer
<jonsger>e.g. file://path/to/repo
<jonsger>forget it, I have an unreleated issue :P