IRC channel logs

2019-03-06.log

back to list of logs

<mikadoZero>The emacs and guile-emacs packages have the same synopsis and description. What is the difference between them?
<mikadoZero>guile-emacs has three additional dependencies guile-for-guile-emacs, automake and autoconf.
<nckx>mikadoZero: guile-emacs replaces the Emacs Lisp interpreter with Guile. So the descriptions matching isn't a bug, but guile-emacs missing an extra line mentioning this important detail is.
<nckx>(It's also still buggy IIRC.)
<nckx>mikadoZero: https://www.emacswiki.org/emacs/GuileEmacs
<mikadoZero>nckx: Thanks
<g_bor>ok, now I have a final word on the neovim segfault issue, but I still don't havev a solution.
<g_bor>It is curses that returns an error on a terminfo lookup, and the libtermkey code is not handling that.
<g_bor>It looks like the lookup should not return an error in the first place, and it also looks like that correct error handling should be added at the call site.
<mikadoZero>nckx: I could submit a patch for the guile-emacs description.
<nckx>mikadoZero: Very welcome!
<nckx>(To be clear: elisp isn't being replaced, just the interpreter.)
*nckx .oO Or should we call it a compiler now?
<rvgn>I have a confusion with understanding LISP. 1) Is LISP a programming language by itself or a programming language model? 2) Scheme is a dialect of LISP right? Is dialect a synonym for paradigm?
<mikadoZero>rvgn: There are many lisp languages.
<mikadoZero>rvgn: Each lisp language is a dialect.
<mikadoZero>rvgn: Scheme is a dialect of lisp.
<rvgn>So LISP in general is a language model not a language. Using that model there are many LISP languages which are LISP dialects. Am I on right track here?
<buenouanq>yeah, but you're prolly thinking too hard
<mikadoZero>rvgn: Yes there is the lisp family of languages.
<rvgn>Thanks!
<bavier>any reason we haven't upgraded our patchelf to version 0.9?
<mikadoZero>nckx: On further inspection my find was a symptom of something larger which I have submitted to the guix-devel mailing list.
***catonano_ is now known as catonano
<leungbk>i was thinking about packaging a rust app, but i noticed that there aren't any packages that invoke the cargo-build-system. is there no interest at present for rust packaging bc of the long bootstrapping process?
<bavier>leungbk: afaik it's just a difficult process, the cargo-build-system is a wip
<leungbk>i see, thank you
<lfam>"It would be nice" if (guix build union) was able to create in a union in a directory that already exists
<lfam>I'd like to build a union in the root of the TMPDIR
<lfam>However, mkdir fails because TMPDIR is already created
***kensington_ is now known as kensington
<nly>What kinds of things can guix build build? `guix build -e '(use-modules (gnu packages base)) #~(begin ..)'` is "not something we can build" http://nly.info.tm:9001/guix/build.sh
<g_bor>hello guix!
<g_bor>Hello nly!
<g_bor>I am looking at this.
<g_bor>From a file with guix package -f this almost works, it misses the module (guix gexp)
<nly>thanks
<g_bor>could not yet find out how to make it work with -e ...
<efraim>looks like go doesn't like compiling from arm to arm64, got an integer overflow
<efraim>I might have to revive my gccgo patches
<roptat>hi guix!
<g_bor>hello roptat!
<g_bor>I've found out what is happening in neovim.
<roptat>great!
<g_bor>I just don't know why, and don't know what would be the correct fix.
<g_bor>The story is that curses returns a -1 from tigetstr, that is passed to the hook in neovim, but the hook is not prepared for that, and the -1 is passed as a pointer causing the segfault.
<g_bor>Only two question remains: why curses returns -1, and should we fix the hook, and if yes, how...
<efraim>i assume you checked if any other distros are getting this issue? that's normally my first check, see if anyone else already fixed it
<efraim>could it be that we're using an "older" version of ncurses?
<g_bor>efraim: did not check it yet. Good idea. I still feel that, even if the curses is faulty that the hook should also be fixed, as a segfault on startup is not a really nice ux.
<g_bor>It seems that there are some unfortunate combinations... like this:
<g_bor> https://github.com/neovim/neovim/issues/8061
<g_bor>however we don't use unibilium...
<efraim>i was about to ask about that
<g_bor>efraim: on the upstream tracker I see no more instances related to that, and we are on ncurses 6.1, so that should not be the issue either...
<civodul>Hello Guix!
<janneke>hello civodul!
***dddddd_ is now known as dddddd
<nly>I can't even connect to bluetooth device without starting pulseaudio first
<g_bor>hello guix!
<g_bor>It seems that we can have the neovim segfault resolved soon.
<g_bor>I talked to someone on their IRC and it seems that a one-line patch can solve this.
<roptat>nice!
<g_bor>roptat: I promised them a bug report and a pull request later today.
<g_bor>How should we handle this on the guix side?
<g_bor>Would it be better to have a patch, or should we just add a build phase?
<g_bor>I guess I would go for the build phase...
<roptat>whatever is easier for you
<roptat>thanks for working on that :)
<g_bor>ok, I will file the pull request first, so that I have something to refer to on the comment.
<rekado>nly: the audio application should cause pulseaudio to be started automatically.
<rekado>nly: if you have a headless system and you want to use bluetooth audio I suggest using bluez-alsa.
<rekado>I’m still having trouble with mpd playing back audio over bluetooth this way, but for all other players it seems to work fine.
<nly>I got as far as running `bluealsa` and the device connects with no pulseaudio running
<nly>Trying to play any sound results in `Unknown PCM` or something like `no file`
<nly>I am trying to use guix to package guix for termux using package->termux-package, http://nly.info.tm:9001/guix/pkgs.scm
<nly>package-description contains newlines which is a problem
<rekado>nly: you’ll need to set up a new device in /etc/asound.conf
<rekado>I’ll probably add a service for this in the next few days
<nly>thanks
<nly>that would be very nice
<rekado>you’d still need to pair and connect the device manually, though (with bluetoothctl)
<nly>huh, it connects automatically after (in bluetoothctl) `pair` and `trust`
<nly>and one more thing, `bluealsa` must be running
<rekado>yes, bluealso is a daemon.
***nly is now known as nlyy
<civodul>roptat: going through my backlog i see a lot of notifications from the TP to guix-devel
<civodul>are you keeping track of these? :-)
<civodul>should we do a mass update of all the .po files?
<roptat>civodul, lots of them?
<roptat>I remember pushing the danish and german translations recently
<roptat>I see there's a Swedish file from yesterday too
***nlyy is now known as nly
<roptat>but nothing else?
<roptat>ah, there's a new German po file for the shepherd, but I don't have commit access
<roptat>I can take care of the Swedish po if you want
<rekado>civodul: looking at guile-json I see that version 3.0 switched from the hash table representation back to alist.
<rekado>this feature was lost in 2.0
<rekado>so… I wonder if maybe the upgrade to 3.x won’t be so difficult after all.
<rekado>the only difference may be JSON arrays that are no longer defined as lists but as vectors.
<rekado>civodul: I saw your new slides just now. Looking good!
<rekado>civodul: when referencing the PiGx paper in the future please use https://doi.org/10.1093/gigascience/giy123 instead of the bioRxiv link.
<civodul>rekado: alright, noted!
<civodul>rekado: re guile-json@3, yes, it switched to alists, so the main differences are that it used to return hash tables and no longer does, and returns vectors instead of lists
<civodul>i'm glad you're looking into it :-)
<civodul>rekado: speaking of the talk, it was interesting because it was a workshop on containers for HPC
<civodul>and they invited me initially to talk about container image generation with Guix
<civodul>so of course i slightly retargeted the topic ;-)
<rekado>hah!
<civodul>the person after me presented a web UI to generate... Singularity def files
<civodul>someone from the audience asked: "wait, shouldn't you generate containers directly via Guix?" :-)
<rekado>:)
<civodul>so we need to get guix-pack-as-a-service going
<rekado>yeah
<rekado>I can get some old file servers soon; could help with hosting this.
<efraim>Sounds like a use case for my travisci config
<g_bor>hello guix!
<civodul>howdy g_bor!
<g_bor>Regarding the video repository, one thing that should be done is to license the files, and set up a licensing policy for contributions. Wdyt?
<g_bor>howdy civodul!
<civodul>g_bor: good point
<civodul>it should be copyleft, but we need to think about how to choose between GPL/GFDL/CC-BY-SA
<g_bor>civodul: that does not seem trivial...
<g_bor>I would say that the code parts are fine by the GPL, but not sure about the rest... Also would we like to use a single license for the whole thing...
<g_bor>I would rather say no. There are two types of very different materials mixed.
<civodul>g_bor: yeah, true
<bgardner>Is postfix not available due to licensing issues or does it just need packaged?
<roptat>civodul, where's that talk?
<roptat>bgardner, I'm not aware of any licensing issue with postfix
<g_bor>civodul: Maybe we could go for GPL for stuff not in the video directories and CC-BY-SA for the content of the video directories.
<bgardner>roptat: Thanks!
<civodul>g_bor[m]: i haven't looked into details, but that sounds like a good plan
<civodul>roptat: there's no video recording of the talk, but the slides are at https://git.savannah.gnu.org/cgit/guix/maintenance.git/plain/talks/in2p3-2019/talk.20190305.pdf?id=5630fcfc2226b8ac0534020cad311644c122ab9b
<rekado>g_bor[m]: since the documentation plays a role in the videos please make sure that the licenses are compatible.
<quiliro>hello...freedom fighters!
<quiliro>thank you for guix
<quiliro>i am not using guixsd now...i had a problem on epiphany with fonts...arial is not displayed...i got squares with numbers on certain characters
<quiliro>i am also discovering emacs
<quiliro>but i have some difficulties exporting
<quiliro>has anyone had success exporting from emacs?
<quiliro>C-x C-e
<quiliro>but i am very enthusiastic...i found elisp intro is a great way to learn the syntax of guix
<quiliro>i know it is a different variation...but that manual is great to introduce basic concepts
<quiliro>does anyone know how to make the desktop or even just emacs tell me when there are new messages on emacs irc (erc)?
<mikadoZero>quiliro: What do you mean when you say exporting? The function that is bound to C-x C-e is `eval-last-sexp`.
<mikadoZero>quiliro: For rcirc: (add-hook 'rcirc-mode-hook (lambda () (rcirc-track-minor-mode 1))) It is in the rcirc manual. As well as omit-mode which I like.
<mikadoZero>quiliro: You might have more success with emacs question in an emacs channel. Like #emacs or #emacs-beginners.
<quiliro>mikadoZero: thank you...
<quiliro>mikadoZero: rcirc is the same as erc?
<nly>woops 'make-builds.sh* is giving me stack-overflow http://nly.info.tm:9001/guix/termux.scm
<quiliro>mikadoZero: export from org-mode
<bavier`>nly: the definition is infinitely recursive
<nly>fixed it
<nly>haha yeah
<nly>there is somehow an origin object in this '(map cadr (package-inputs package))
<bavier`>nly: package inputs are not necessarily packages
<bavier`>so if you're interested in only the packages, you'll have to filter them out
<nly>thanks
<Copenhagen_Bram>How does guixSD decrypt a LUKS partition to something like /dev/mapper/rootfs as specified in the config file?
<rvgn>Copenhagen_Bram By the use kernel module dm-crypt.
<rvgn>*use of
<Copenhagen_Bram>Ah
<Copenhagen_Bram>rvgn: Does this also involve an initramfs at all?
<mbakke>Berlin seems to struggle with the staging branch: https://berlin.guixsd.org/jobset/staging-staging
<mbakke>Copenhagen_Bram: Yes, the decryption occurs in an initrd.
<Copenhagen_Bram>ah
<mikadoZero>quiliro: rcirc is not the same as erc.
<mikadoZero>quiliro: I have not had trouble exporting with org-mode. I suggest you read the org manual. orgmode.org or C-h i in emacs.
*Copenhagen_Bram is installing gentoo and was wondering how GuixSD did it
<nly>C-x C-e, I think you meant C-c C-e for org-export...?
<nly>I am stuck with make-builds.sh* http://nly.info.tm:9001/guix/termux.scm
<quiliro>nly: yep...sorry
<quiliro>mikadoZero: i did what the manual said...it works on debian...not on GSD
<g_bor>hello guix!
<quiliro>hello g_bor
<g_bor>i had a look around the licensing stuff, and it turned out to be inconclusive.
<quiliro>what's up?
<g_bor>it's all fine. But I am confused.
<g_bor>Now we have the documentation videos, and there are at least two incompatible licenses in play.
<g_bor>the gpl and the gfdl...
<g_bor>it is not even very clear to me what does it mean for example, that gpld software cant include gdfl licensed text...
<g_bor>what exactly cant you do?
<quiliro>g_bor: they are licenses which prevent changing license. Including a gfdl text on a gpl work would chang the work's license
<quiliro>one can't be included inside the other
<quiliro>one work must be separate from the other work with incompatible licenses
<quiliro>as far as i can understand...i am not an expert...does what i am writting make any sense?
<g_bor>quiliro: that is exactly my understanding, but what does include inside each other, and keep them separate mean?
<g_bor>they should not be in the same file? Or in the same repository?
<bavier`>ianal, but consider the case of including a source listing of a gpl program in an appendix of a gfdl'd manual
<g_bor>Just take an example: guix is gpl. The manual is gfdl. Is this not a problem?
<quiliro>i think bavier's example is tolerable because the amount of code is trivial and g_bor's example is solvable by specifying which file is gpl and which is gfdl
<bavier`>I think "separate" here means that neither depends on the other
<bavier`>the guix program does not require the manual in order to run, and the manual can be read and understood without the program
<quiliro>still...the license should be modified to be compatible
<ng0>hm.. what about a license "gpdl OR gpl3" choice/dual licensed? i don't remember if it was checked by lawyers then, but I think it was okay. Or is this bda too?
<ng0>*bad even
<vagrantc>where are the architectures defined in guix? ... i was wanting to try and get a riscv64 cross-compiler; i think it's supported upstream in the various toolchain bits with recent versions of gcc/binutils/glibc/etc
<lfam>Do we have a handy procedure for creating the *name* of a temporary file or directory? Like a way to generate a short random string that is safe for the filesystem?
<lfam>I don't want to actually create the path; it will be passed to union-build
<bavier`>lfam: 'tmpnam'
<lfam>Thanks bavier`
<kmicu>g_bor2: what do you mean by ‘software including text’?
<lfam>I am getting lots of truncated build logs from Berlin
<lfam>For example, this one: https://ci.guix.info/log/zn9lp55r2wykprmr098lkhij44r3sw40-demlo-3.8-0.fe9ec4c
<civodul>lfam: yeah it seems there's a bug that has to do with offloading
<civodul>as if some buffer wasn't flushed
<civodul>rekado: i just saw the commit that adds guile-studio, yay! \o\
<civodul>\o/
<mikadoZero>g_bor[m]: On gnu.org there is a page on license recommendation and it has a section on documentation that looks relevant to what you were talking about. http://www.gnu.org/licenses/license-recommendations.html
<mikadoZero>`which recsel` say recsel not found and `guix package -s recsel` returns nothing. I would like to use it to refine package search results as demonstrated in the manual. Where is it located?
<lfam>mikadoZero: Recutils
***renich_ is now known as renich
<janneke>hmm, i get some errors that i don't understand
<janneke>building /gnu/store/nxcq7hw103q2ryncnpa54cdfs7mninhq-gcc-toolchain-8.2.0.drv...
<janneke>while setting up the build environment: executing `/gnu/store/d1yz95qbxk4lgbdsi9r4i9kbvzfvc49p-guile-2.2.4/bin/guile': No such file or directory
<mikadoZero>lfam: Thanks
<janneke>things seem to be missing from the store, what could be going on?
<g_bor>hi janneke!
<lfam>janneke: Try `guix gc --verify`
<janneke>lfam: ah, thanks
<janneke>hi g_bor!
<g_bor>I was about to ask if you ran gc recently...
<lfam>janneke: There are further options to that command but they are expensive and potentially dangerous
<g_bor>lfam was faster :)
<lfam>If something is missing then something is wrong
<janneke>g_bor yes, i ran gc with some specific store paths (guile, gcc)
<janneke>after i succesfully setup an guix environment for arm, gcc was missing (dangling symlink in the environment)
<janneke>so, i guix gc'd that gcc and then things apparently got worse
*janneke now runs sudo guix gc --verify=contents,repair
<lfam>janneke: If you are working from a Git checkout, remember that after gc you probably need to do ./configure again
*g_bor rebuilding guix, hoping nasty backtrace go away:)
<janneke>lfam: yes, thanks -- i have some of those around; running off of guix pull mostly nowadays for non-bootstrap work though :-)
<janneke>but dannym did some nice arm things again for mes, and i want to run it! :-)
*vagrantc got to learn the excitment of "guix gc --verify=contents,repair ... *sighs*
<civodul>janneke: the "while setting up the build environment" error, is it because the file actually doesn't exist, or because its ELF interpreter doesn't exist, for example?
*lfam has revamped go-build-system to avoid <https://bugs.gnu.org/33620>
<civodul>lfam: great if we can get that fixed!
<g_bor>lfam: I'm so happy about that!
<janneke>civodul: oh crap, that's it -- guile exists but it's an ARM executable
<lfam>g_bor, civodul: WIP patches here: https://github.com/lfam/guix/tree/contrib-go-union
<janneke>i'm doing something weird, maybe
<lfam>I need to do some final tests, update the annotations, and write the commit message, but it seems to work
<g_bor>:)
<civodul>janneke: pheew :-) it's still weird that you get this error instead of the one that says you're on the wrong system
<civodul>but yeah, maybe you're doing something weird ;-)
<civodul>i saw all the ARM commits by Danny and that's exciting!
<janneke>lfam, civodul: the problem is solved -- thanks!
<civodul>cool!
<rekado>cbaines: I think it may be good to split (gnu packages ruby), so that we can keep the module closure small.
<janneke>i need to bother dannym about this, he suggested a nice trick to have qemu for arm show assembly code in single-step upon a segfault, or something
<janneke>i forgot about setting this up
<cbaines>rekado, sure, sounds fine to me :)
<rekado>cbaines: let’s do this after all of your ruby patches have been merged.
<g_bor>there seems to be something wrong with guix refresh here...
<g_bor>Maybe I'm doing something wrong...
<g_bor>It is a wrong argument in position thing, but only when I call it with -u ...
<g_bor>any idea?
<mikadoZero>Does `guix package -s ""` return all guix packages?
<nckx>mikadoZero: It should.
<mikadoZero>nckx: Thanks
<vagrantc_>got as far as a kernel panic on the asus-c201pa ... but somehow the wrong uuid got specified in my config.scm ... trying again...