IRC channel logs

2020-10-15.log

back to list of logs

<civodul>"guix show lsh" :-)
<civodul>it's unmaintained tho
<raghavgururajan>got it https://www.lysator.liu.se/~nisse/lsh/
<raghavgururajan>Oh no :(
<rekado> http://lists.lysator.liu.se/pipermail/lsh-bugs/2019q2/000684.html
<ss2>Now daemon is complaining that guile is too old.
<raghavgururajan>👍
<nly>what the heck, authentication worked, nice
<jonsger>why does `guix environment --ad-hoc cuirass -- info cuirass` not work?
<mroh>versuch `guix environment info-reader --ad-hoc cuirass -- info cuirass`
<jonsger>`guix environment --ad-hoc info-reader cuirass -- info cuirass` funktioniert, danke für den tipp :)
<mroh>gerne ;)
<terramorpha>Hi everyone, is there a way to specify a channels list in the operating-system definition without having to use ~/.config/guix/channels.scm ?
<terramorpha>It would help in making my setup more reproducible.
<jonsger>terramorpha: yes, you can somehow define local files in your config.scm. But I forgot how :(
<jonsger>terramorpha: with https://guix.gnu.org/manual/devel/en/guix.html#index-simple_002dservice e.g. https://gitlab.com/Efraim/guix-config/-/blob/master/E2140_config.scm#L84
<jonsger>while defining your channels at /etc/guix/channels.scm, which I do
<apteryx>ss2: wow, I've never heard of that need/solution! Glad you got it working.
***catonano_ is now known as catonano
<eloyesp>Hi, is there a channel to ask for help in spanish?
<apteryx>no, but you can ask here in Spanish if you want!
<eloyesp>ok, good to know (sometimes my English is not that good)...
<zimoun`>eloyesp: puede enviar un correo a help-guix@gnu.fr y escribir en espanol.
<zimoun`>/gnu.fr/gnu.org
<zimoun`>:-)
<eloyesp>Ok, I've just installed guix for the second time (the first time it didn't work), on an external SSD drive, mi idea was to be able use it on different computers, but the main system config seems to hardcode `/dev/sdX` on the bootloader section... I'm afraid it could overwrite the bootloader on the host machine, does anyone have any idea if there is
<eloyesp> a way to prevent that?
<roptat>eloyesp, I think at the end of the installer you're given a choice to edit the final configuration file before it starts actually installing anything
<roptat>that's where you'd change the bootloader config to install to your external drive instead
<eloyesp>I've already installed it on the external drive, it went ok, but now, I'm not sure when that file will be "executed" again...
<eloyesp>if I install a package, will it re-install the bootloader?
<eloyesp>the problem is that now, the disk is not sdd anymore, it is sdc ...
<roptat>oh I see
<roptat>that file is only executed when you run "guix system reconfigure"
<roptat>if you use only guix install & co, or any command run as user, as opposed to root, you're fine
<eloyesp>roptat: thanks, good to know...
<eloyesp>I have an idea now, can I use the disk id there? `/dev/disk/by_id/usb-xxx` (seems to be a link to the "correct" drive)
<eloyesp>does it makes sense?
<roptat>yes, absolutely, I was about to suggest it :)
<roptat>as long as that id is stable across machines
<roptat>(otherwise it'll fail, which is better than overriding another bootloader I guess)
<eloyesp>ok, done...
<eloyesp>is there a way to check if the file is fine (or make a dry run)
<roptat>there's --dry-run, but it doesn't really do anything
<roptat>I mean, I don't think it'll test the bootloader config for errors
<AsumFace>how does guix tell what compiler to use?
<apteryx>they are defined as part of the build systems
<apteryx>(guix build-systems gnu) for example
<AsumFace>i will look into this, thanks
<wleslie>I've hit a failure in my cross binutils compile and wondering if it's possible to run this command in something like the compile environment to dig deeper https://bpa.st/QKFA
<wleslie>I think this is binutils-2.34/bfd/config.status that is running here
<wleslie>looking at this file, I can't see what command `default` is supposed to be running
<wleslie>oh it's just chosing a po file
<wleslie>neither `config.status default` or `make` fail in my default environment, so it's strange that there's nothing between `config.status default` and the parent make failing
<wleslie>I may as well try the parent make
<wleslie>ah; I need to add makeinfo
<wleslie>I added texinfo to native inputs, but I get exactly the same error
<ani>How shall I send patch files to mailing list? attaching .patch file to email or from command line(terminal) git send-email ?
<nly>ani: try the easier method first?
<wleslie>the git-format-patch command produces them in the correct format for email
<vits-test>nly: which one? <fat>I usually just giving a link to the Debian paste.</fat>
***vits-test is now known as sneek
<sneek>Hello Guixen. On TTY in emacs: M-> and some key bindings do not work. They work after `sudo loadkeys us` (which gives me qwerty, same as it was before command).
***sneek is now known as vits-test
<vits-test>sneek seen sneek
<sneek>s34n was in #guix 4 months ago, saying: (I think. I can't look at history right now and I'm brand-new to guix).
<Brendan[m]2>anyone else have trouble with mailto links? im in sway without a desktop environment and when a click the reply to ... button on mailman in icecat, it opens icedove but then does nothing. if i click the same button in ungoogled-chromium, it works slightly better, it opens a new mail window, the To and CC are all empty
<Brendan[m]2>im not actually sure thats a "mailto" link but some kind of post request thing
<drakonis> https://cfp.nixcon.org/nixcon2020/talk/K89WJY/ this is tomorrow
<drakonis>worth following
***bkv is now known as bqv
<wleslie>it looks like if I'm using (make-libstdc++) and the target gcc is not the same version as the host gcc, I also need to override the host gcc
<wleslie>does that sound reasonable? otherwise I get a bunch of these: https://bpa.st/H46Q
<wleslie>I also get some strange failures, strange in that if I cd into the build directory, source the environment-variables, cd into the directory and keep running `make`, it eventually builds
<wleslie>I've been watching my memory and disk usage but I can't figure out what is causing it, but it is always at the same points that it fails
<vits-test>wleslie: maybe build process try access network? Sometimes that was the case.
<vits-test>also: make -j1
<wleslie>it's binutils, so it's not exactly unexamined code
<wleslie>yeah will -j1
<wleslie>thanks, hmm, I need to specify the emulation script template it seems
<wleslie>clearer errors with -j1 if nothing else
***apteryx_ is now known as apteryx
***iyzsong-- is now known as iyzsong-w
<civodul>Hello Guix!
<ani>guix doesn't have emacs27 module?
<PotentialUser-34>hello
<PotentialUser-34>does guix have support for rtl8822be wifi?
<leoprikler>Emacs 27 should be the default Emacs in Guix
<leoprikler>PotentialUser-34: Is that included in the linux-libre kernel or does it need firmware blobs?
<ani>leoprikler: when I installed guix install emacs
<ani>I got emacs 26.3
<ani>not 27
<leoprikler>You're on a pretty outdated guix, then, probably. Try `guix pull' first.
*civodul just realized we have bug #44000
<janneke>eh, \o/ ... i guess?
<civodul>yeah, a nice figure no?
<janneke>certainly!
<civodul>also, i got 'guix pull' to run in the childhurd, and eventually the system crashed
<civodul>no hints on the console though
<civodul>and the kernel debugger was unreachable
<janneke>bah!
<OriansJ>I wonder what percentage of bugs are still open.
<leoprikler>I'm waiting for 44444
<civodul>you can help reach that number faster! :-)
<civodul>i read that Hacktoberfest is a good way to do that, too
<Brendan[m]2>i think there are many people waiting for reviews on there submissions
<civodul>yes, we have a terrible backlog
<civodul>i feel like we committers could review more, but it's easier said than done
<Brendan[m]2>better to invest in the community by adressing those contributions rather than working on ones own todo list perhaps
<Brendan[m]2>how good do you have to be before you can become a comitter?
<nly>a scheme god
<civodul>it's not about being "good", whatever that means
<civodul>see the rules at: https://guix.gnu.org/manual/devel/en/html_node/Commit-Access.html
<Brendan[m]2>years ago i became a parabola commiter very quickly
<civodul>it's mostly about commitment
<leoprikler>You just need to sell your soul to the FSF and commit to only writing GPL software for the rest of your life ;)
<civodul>tsss
<Brendan[m]2>i think i would like to become one for the sake of working on things such as leaf packages where i hopefully wont break things that are important
<nly>>commitment hah, i see what you did there
<civodul>so the co-optation rules are clearly stated, and we clarified that on purpose some months ago
<civodul>in the hope that people would dare apply :-)
<civodul>i think it has worked to some extent
<Brendan[m]2>i wouldn't touch guix core stuff on my own. also, im not sure what is required to submit to core-updates. some people just seem to be working on it whenever so i dont know what the game plan is
<civodul> https://guix.gnu.org/manual/devel/en/html_node/Submitting-Patches.html explains the branching strategy
<Brendan[m]2>i wanted my fixes to wrap-program to be tested and go in if they are ok.
<civodul>oh yes, these would be welcome
<civodul>did you ping people?
<civodul>i was under the assumption that it was "being handled by someone" :-)
<Brendan[m]2>maybe it is, since people likely dont comment when there is no program and its just in the works. i pinged you and rekado about your old bug report for wrap-script. he said hed look into that one. as for the wrap-program, Danny asked a question, i clarified, and then no response since.
<Brendan[m]2>Part of the reason i wanted it in core-updates, even if it was buggy, was that i can exploit the build server to test rebuilding the world
<Brendan[m]2>otherwise id have to start burning my laptops cpu for a few days trying to do that to see if anything breaks
<leoprikler>I'm p sure wrap-program affects more than 1200 packages, so it belongs to c-u either way ;)
<Brendan[m]2>yep
<ani>how to know which guix version am I using?
<Brendan[m]2>guix --version
<civodul>Brendan[m]2: this is https://issues.guix.gnu.org/43367, right?
<ani>I tried guix version but it doesn't provide it in
<civodul>"guix describe"
<ani>Generation 2 Oct 14 2020 15:05:49 (current)
<ani> guix 3df7077
<ani> repository URL: https://git.savannah.gnu.org/git/guix.git
<ani> branch: master
<ani> commit: 3df707778a29b7364fffe94c150a9f69467c47cf
<ani>this is my output
<ani>am I at the latest version ?
<civodul>it looks like a recent version, presumably from Oct. 14 :-)
<vits-test>ani: guix show emacs|grep version
<civodul>so not the latest, but very close to it
<ani>yes
<ani>yes I am running emacs27.1
<efraim>about 50 commits behind HEAD but recent enough
<ani>efraim: damn, guix developers are faster than guix user :D
<zimoun>civodul: the Hacktoberfest thing a another way to say Hackathonm right? Just with a “prize” for some contribution, right?
<Brendan[m]2>means its in october
<civodul>zimoun: yes, but it's become (in)famous for being a source of spam to projects hosted on github.com
<OriansJ>civodul: atleast spam issue requests might find something I missed in stage0 or mescc-tools-seed
<jonsger>:P
<nly>in networking.scm how does tor-shepherd-service know which user to start tor as?
<Brendan[m]2>nly does it start as root and drop to tor on its own? you can see User tor in the torrc
<nly>ahhh
<nly>thanks a lot
<zimoun>ani: How is going your progress about the doc patch?
<nly>make-forkexec-constructor; how do i get it to run as a particular user?
<rekado_>Brendan[m]2: sorry about dropping the ball with wrap-script again. Life hasn’t been kind enough to me these weeks.
<rekado_>I’m too deep in brain fog to think clearly about the problem and devise solutions.
<zimoun>could we do something about the 2 “gnu/packages/gnuzilla.scm:595:10: warning: resolving” appearing each time I run “make”?
<Brendan[m]2>That's ok its not a problem. i might develop the test cases you suggested
<rekado_>zimoun: noticed those too. What’s that about? Is it a problem with how patches are referenced?
<OriansJ>rekado_: you need a vacation; no point in pushing oneself when this is a long term project
<OriansJ>and burnout is deadly to long term projects
<rekado_>OriansJ: yeah, no vacation in sight — I’m not even back to work yet. It’s just long term sleep deprivation. People say it gets better one day.
<Brendan[m]2>i think that gets better when the sleep deprivation stops ^_^
<rekado_>one way or another it must stop
<rekado_>all things must pass
<ani>zimoun: I sent the doc patch
<ani>also I sent a mail to help-guix@gnu.org
<OriansJ>rekado_: me too; but that is the point of 2 parents. One can give the other a day off to sleep and recover
<ani>zimoun: Hi all,
<ani>I am new when it comes to submitting patches through email. For my first patch, I copied all the body from the .path file and pasted in mail. Also from the subject line, I copied the subject and pasted it in the subject of my email. To be on the safer side I also attached a patch file to the email. What is the write way? I thought submitting through email is the easier way than submitting it to git email.
<ani>Regards,
<ani>Aniket.
<ani>this was the mail
<rekado_>ani: attaching is better than copy/paste because the formatting remains intact
<leoprikler>git send-email is preferred, but there's nothing wrong with using attachments
<rekado_>ani: you can also send the patch *directly* with “git send-email”,
<ani>I thought this way will be faster. But I guess now before sending R package patch I will send it through git command line
<rekado_>but it requires some configuration
<ani>yes
<ani>but after configuration only one command
<OriansJ>just be sure to communicate a rotation shedule with your spouse rekado_ and you both can escape cronic sleep deprivation
<ani>I guess that will be fun to do, but then I thought I will have to generate app password for gmail inorder to use it in terminal hence I thought of sending patch file.
<Brendan[m]2>you can just attach it instead
<Brendan[m]2>its even possible to attach multiple patches to a single email. its a bit difference to the convention but people can cope with it
<rekado_>ani: in the long term configuring send-email is a good idea, because it simplifies things; but in the mean time just attach the generated patch.
<ani>yes.
<rekado_>OriansJ: a crèche would be nice. Redundancy with just two parents is poor in case of sickness :-/
<OriansJ>rekado_: we call that day-care here; but there is a reason why extended families trade childcare favors
<OriansJ>but it only works if you have siblings who live a reasonable travel distance away
<zimoun>rekado_: the warning are about patch path. I do not understand. “git blame” says it is 2 commits by Mark. It is warning so it is ok, it is just annoying. :-)
<zimoun>ani: Cool! Are you an Emacs user?
<ani>zimoun: yes, sir.
<ani>Beginner though. I was using VIM
<ani>but then I came to church of emacs :D
<Brendan[m]2>ani tried doom at all?
<civodul>zimoun, rekado_: yeah that gnuzilla.scm warning comes from f43ffee90882c2d61b46d69728daa7432be297e4
<civodul>an unintended side effect
<zimoun>civodul: what is the point of this new “guile” file? I do not know but “guix environment -C guix” does not seems liking it…
<civodul>could you be more specific? :-)
<civodul>(it comes from <https://issues.guix.gnu.org/43737>)
<ani>Brendan[m]2: Doom is good, but I want to learn emacs fully first. Then I will switch to doom in near future.
<Brendan[m]2>"fully" see you in the year 2120
<ani>"fully" -> state in which I feel confident.
<zimoun>civodul: I did “guix environment -C guix”, run some stuff, then out and “guix environment -C guix –ad-hoc git”, tweak and then “make” failed
<leoprikler>I have "fully" learned Emacs to the extent that I now understand it is impossible to "fully" learn Emacs :)
<leoprikler>44008 and counting
<ani>guys I have question for you regarding GNU, FSF. Is it appropriate to ask it here?
<civodul>zimoun: failed how?
<zimoun>ani: I suggest you to give a look at the emacs package Magit. It helps! :-)
<civodul>ani: GNU and the FSF are totally different things, and Guix does not represent all of GNU; that said, you can ask :-)
<zimoun>civodul: ./pre-inst-env: line 55: /gnu/store/y0n6ravn3s5p6xl7jwgal6pvbmikajm7-profile/bin/guile: No such file or directory
<civodul>how does that relate to the new 'guile' binary? :-)
<civodul>here's a trick: if you want to use -C with an autoconf-based project, always use -CP
<civodul>that way, file names are recorded (in config.cache, Makefile, etc.) as $HOME/.guix-profile/...
<zimoun>ok, I am going to do.
<civodul>zimoun: BTW, i realized that Oct. 29th is holiday time here, so not good timing for me
<civodul>the week after is fine though
<civodul>and i'll be around the week before as well
<ani>yes, so I know GNU, FSF are totally different things. I started following them since my teenage. But I didn't know how to connect with it. I thought GNU is very limited and if you want to contribute then you will have to be expert at something, and I was wrong. And started exploring and using GNU and Free Software every possible time. Since then many of my friend see me as Free Software Activist. So they do ask me about Free Software and Open source etc. I have
<ani>prepared a mail for them, If you guys suggest me somethign what I need to improve in that information then that will be good.
<ani>zimoun: Yes, magit helps because emacs rocks. :)
<zimoun>civodul: no holidays when we speak about releasing. ;-)
<zimoun>instead 6th Nov.?
<zimoun>or 23rd Oct. ?
<zimoun>ani: if you use Magit, then it is really easy to submit patches: stage (s), commit (c c and rewrite), format-patch (W c C-m b master c) and then outside “git send-email –to=… 0001-blabla.patch” with the configuration of in the Example section https://git-scm.com/docs/git-send-email
*rekado_ updates R
<rekado_>zimoun: funny, I thought you’d suggest Magit for send-email. I also use git send-email on the command lin.
<rekado_>*line
<ani>will look into it.
<ani>Also, does anyone know, whether thinkpad X200 will support external monitor with
<ani>1920x1080 resolution ?
<zimoun>rekado_: yeah it is really missing upstream.
<janneke>yeah, magit needs to support git-send-email ;)
<ani>in cookbook $GUIX_CHECKOUT means where we have our .scm file or our working directory where we are editing our files isn't it?
<rekado_>ani: I think it does.
<rekado_>ani: I no longer have an X200, but I do think I used it with my old HD monitor before.
<ani>Cool.
<wleslie>I miss the days where you could tell what resolution your computer could support by multiplying the size of your graphics ram by the colour depth
<wleslie>or, you know, divide
<bonz060>Hi guix! How would you get the r/ship between inputs using guix-graph? I want to find out which package has, as a dependency, some other package.
<ani>So I guess now I am ready to make R package, patch it and then send the patch. But before that I have few doubts
<zimoun>rekado_, janneke: saddly the Magit authors do not seem interested by git-send-email support. Because there are some “closed” issues asking for the support (checking before open another one). However, GitHub pull-request is now supported. :-p
<ani>zimoun: I am using building from git guide. Have downloaded latest git clone
<ani>and now did run "guix environment guix --pure"
<ani>now shall I start packaging R packages?
<zimoun>ani, yes please go ahead
<janneke>zimoun: oh, that's unfortunate; maybe it could help to ask again?
<ani>I found R package in guix/guix/build so shall I do "guix import cran --recursive" to know which packages are not packaged?
<zimoun>maybe since Kyle contributes to both Guix and Magit
<ani>zimoun: which package shall I package?
<ani> https://bioconductor.org/packages/release/bioc/
<ani>these are the packages which aren't been packaged?
<zimoun>some are, some aren’t :-)
<ani>How do I which aren't ?
<zimoun>you could try to find one from this list: https://cran.r-project.org/web/packages/available_packages_by_date.html
<ani>also after running this command "guix environment guix --pure". I can't run any guix command
<ani>like error I am getting guix not found
<zimoun>it is expected since ’–pure’ erase all your env variables.
<zimoun>once in the environment, you have to run “./bootstrap && ./configure –localstatedir=/var/ && make” and then “./pre-inst-env guix <sucommand>”
<ani>Okay
<ani>./pre-inst-env is like python virtualenv?
<rekado_>bonz060: you can use “guix graph --path” if you know that a package is an indirect dependency but you’d like to know how indirect the relationship is.
<rekado_>ani: no, it just makes it so that Guix will use your source directory.
<nefix>hello! How can I get the path to a binary in a scheme file? I want to generate a file with the path to Nix hardcoded in it
<nefix>I'm not sure if I've explained myself :S
<ani>nefix: If you haven't then you can explain again.
<rekado_>nefix: can you provide a little more information about *where* you want the absolute file name of *what* binary?
<vits-test>nefix: binary from store, or home-maded?
<rekado_>nefix: what “scheme file” do you mean? Do you mean in a package definition?
<nefix>I'm using guix home-manager and I want to hardcode in my bashrc the path of a nix script to setup the environment variables
<rekado_>roptat might be able to help you with that
<nefix>I have a (define bashrc ...), and I want to append it inside this definition
<rekado_>I haven’t used the home-manager yet
<rekado_>you probably want G-expressions if home-manager supports that.
<vits-test>nefix: (define file (local-file "script" #:recursive? #t)) ; to preserve executable bit.
<vits-test>(local-file-absolute-file-name file)
<nefix>right now in my bashrc I have: "source `guix build nix`/etc/profile.d/nix.sh" and I want to remove `guix build nix` and there to be the actual nix path
<rekado_>a G-expression allows you to refer to a package’s eventual output directory
<rekado_>something like that: #~(string-append "source " #$nix "/etc/profile.d/nix.sh")
<rekado_>where “nix” is the package variable
<rekado_>#~ introduces a G-expression, #$ is like an unquote
<rekado_>when this is compiled #$nix is replaced with the prefix directory name of the built “nix” package.
<jlicht>nefix: the `rc` field of bash-home-type should be processed using mixed-text-file, so you can try file-append: (bash-configuration (rc (append default-bashrc (list "\n" (file-append nix "/etc/profile.d/nix.sh")))))
<jlicht>you do need to have the `(guix gexp)' module in scope for this to work, as well as the nix package definition in `(gnu packages package-management)'
<jlicht>nefix: rekado's #~(string-append ...) snippet is cleaner, don't forget about newlines (or ;) though
<roptat>hi guix!
<civodul>howdy roptat!
<civodul>zimoun: Nov. 6 works for me, for the actual release, but of course it's even better if everything's ready earlier :-)
<civodul>we don't have to work until the last minute
<roptat>doing good, but a bit stressed by a deadline today :)
***jess-o-lantern is now known as jess
<zimoun>civodul: cool! I expect to be ready before. And Fri. will be week-end travelling day for me… well if it is still allowed.
<zimoun>roptat: how your atéfact is going?
<roptat>it's ready
<zimoun>\o/
<zimoun>civodul: with this new “target” date, does the proposal of string freeze for the manual and translation is extended or transfered?
<ani>I am inside ./pre-inst-env, and now I am trying to write recipe? For that I want to build a packaged named abc so I click on that I look at its metadata, now I am using one of the package template /guix/build/r-build-system.scm to get reference and edit appropriate values
<ani>am I going in right direction?
<leoprikler>If you're building an R package, looking at other R packages sounds like a good idea, yes.
<zimoun>ani: no. First try “guix import cran -r abc”, this command will give you the recipe. Second, add it to gnu/packages/cran.scm (bottom).
<zimoun>then you go for “./pre-inst-env guix build abc”. Does it make sense for you?
<efraim>the staging freeze is independant of the upcoming release?
<zimoun>efraim: I do not know but it is on point. :-)
<ani>I will do that I got the recipe but it says "Starting download of /tmp/guix-file.QPD259" where does it saves the file. ?
<zimoun>ani: do not worry about that, IMHO.
<ani>Okay so piping the output of "guix import cran -r abc" to a file and then saving it will do the work ?
<bonz060>On debbugs.el, what is the specific name to enter to get the bug list? On the docs, I only see guix-patches for seeing patches...
<roptat>ani, you'll be missing some modules if you do that, instead copy-paste it to gnu/packages/cran.scm
<ani>Ah I have habit of making things complicated. :D Actually now it makes sense after opening the
<ani>cran.asm
<ani>so just pasting the recipe and then commiting the patch isn't it?
<roptat>if there are multiple packages, it's one patch per package
<zimoun>roptat: it is one. :-)
<roptat>you still need to check the output: does it build (guix build), reproducibly (guix build --check) and does it correspond to our standards (guix lint)
<zimoun>let keep thing simple for now ;-)
<ani>roptat: I got it first let me copy paste and then come to this part.
<roptat>you might need to tweak the synopsis and descriptions a bit :)
<roptat>yep :)
<ani>did a search and found out that abc is already in the file. Now I have to look at another package.
<ani>:D
<leoprikler>is this so you can get a contribution for outreachy?
<leoprikler>if not, I suggest the much saner alternative of "building a package once you find out that guix doesn't have it and you really need it"
<bonz060>rekado_: thanks for the guix graph tip.
<ani>leoprikler: Yes, its for outreachy but I don't want to contribute for sake of Outreachy. So what you have suggested I will do it? That will enhance my overall knowledge of using and developing guix. What I was doing was to write recipe and then go as defined in "2.1.1 A hello world package". Like downloading source code, then signature and then doing guix package --install-from-file=my-hello.scm
<ani>I will do it? I will do it!
<ani>*
<nly>where does shepherd store it's logs?
<civodul>nly: it talks to syslogd, so that typically goes to /var/log/messages & co.
<nly>thank you
<zimoun`>ani: from the list I sent you, you pick one and try “guix search the-name” to see if it is already or included.
*civodul updated NEWS for Guile-Git
<ani>zimoun`: Every package I am trying is already included. :D
<ani>Still searching, interesting. Even newer packages are included as well.
*apteryx reads news about guile-git
<ani>So I added a lpme package to cran.scm
<ani>got into trouble.
<ani>[ani@thinkpad guix]$ ./pre-inst-env guix build lpme
<ani>;;; note: source file /home/ani/Development/Guix/guixR/guix/gnu/packages/cran.scm
<ani>;;; newer than compiled /home/ani/Development/Guix/guixR/guix/gnu/packages/cran.go
<ani>error: gpl2+: unbound variable
<ani>hint: Did you forget `(use-modules (guix licenses))'?
<ani>guix build: error: lpme: unknown package
<civodul>ani: did you forget #:use-module (guix licenses) in that module?
<ani>no
<ani>wait
<civodul>oh, should it be 'license:gpl2+'?
<ani> (license license:gpl2)))
<ani>it should be like this I guess
<ani>the generated recipe lacked this I guess
<PotentialUser-35>Note: there is a mismatch between names from `guix/licenses.scm` and the results produced by `guix/import/utils.scm:spdx-string->license`
<PotentialUser-35>(By the way: hi!)
<nefix>rekado_: jlicht: right now I have https://dpaste.com/7NXY75PA3
<nefix>but it's breaking saying it doesn't find gexp (even though it's imported)
<ani>civodul: For one package lpme the command guix import cran -r lmpe generated three
<ani>recipe's
<ani>recipes
<PotentialUser-35>Just a quick question: as per a derivation log, `command "unzip" "/gnu/store/···.zip" failed with status 127` using go-build-system.
<leoprikler>you'll have to add unzip to the native-inputs
<PotentialUser-35>It looks like I don't have `unzip` installed, but it's being used even by the `gnu-build-system`
<PotentialUser-35>Shouldn't it be part of the core build tools?
<leoprikler>nope, normally you'll have tar+gzip
<mfg>ani: -r recursively generates the package definitions for the package you specified an dit's dependencies - it doesn't know about #:prefix definitons one might have used in source files so it can't know that the license should be prefixed, you need to add that :)
<nckx>PotentialUser-35: It's used only when the source is a zip file which is rare.
<nckx>Good morning, Guixen.
<ani>mfg: It generated three recipes
<nefix>hmmm, unbound variable is "variable not found"?
<PotentialUser-35>Then, should I specify it for every packaged in the world if I pull them as ZIP?
<mfg>ani: it doesn't generate the definitons for all dependent packages though, as it seems it only generates definitoins for packages which are not already included :D
<ani>so I should also include those packages in order to properly build right?
<mfg>ani: yes, the first two are dependencies of the last one. They are in the native-inputs section
<mfg>yes
<ani>cool
<mfg>(btw: i didn't know about -r :/ i guess i wasted some time...)
<nckx>PotentialUser-35: For every package that needs to unpack a .zip archive, yes.
<nckx>nefix: Basically. ‘No such label pointing to a value.’
<nefix>:S
<ani>mfg: So it says guix build: error: lpme: unknown package
<ani>because I should first build dependent packages isn't it?
<nefix>nckx: I must be missing something, because it's missing "gexp", but I'm using that module
<mfg>ani: hm, if you just copy and paste the output of the import command into cran.scm and ./pre-inst-env guix build -K r-lpme it should work...
<ani>okay
<nckx>nefix: You're importing (guix gexp)? Then I guess we'll need to see the failing code.
<nefix>nckx: yeah, I think I'm doing: https://dpaste.com/7NXY75PA3
<civodul>ani: pay attention to what comes right above "unknown package"
<nckx>Is this inside a phase or builder?
<nefix>nckx: eeh, not sure. It's line 21 that's making it fail
<nckx>nefix: Why the quasiquote? (`)
<mfg>ani: i should read more carefully, you tried to build the package lpme, didn't you? because it's a r package it's called r-lpme in guix :D
<nefix>nckx: at this point, I was trying different things to make it work. First it was with a normal quote, but it wasn't working neither
<nckx>Why quote at all? Does it work with a plain (list #~...) instead?
<ani>mfg: yes I tried guix build lpme
<ani>so I should do guix build r-lpme?
<PotentialUser-35>Thank you for the clarification, nckx: then I'm going to add it to every package through the build system (https://github.com/guix-mirror/guix/blob/master/guix/build-system/go.scm#L71) and ` #:use-module (gnu packages compression)
<PotentialUser-35>` to avoid repeating myself from the importer, as every package will be pulled from a ZIP archive.
<mfg>ani: yes, exactly. r packages are prefixed with r-, perl packages with perl-, rust packages with rust- and so on :)
<ani>Col
<ani>cool
<nckx>PotentialUser-35: Well, you're welcome to try & see what reviewers say. If Go uses .zip for everything I guess it makes sense. I don't much speak Go.
<nefix>nckx: oh, that has worked! :D thanks! I thought that (list ...) and '(...) was the same
<nckx>Eh, ‘sometimes’.
<nefix>oh :S
<ani>mfg: Done its building I guess without error.
<mfg>ani: nice!
<ani>mfg: So what next, shall I commit and send the patch?
<nckx>nefix: Certain types are self-evaluating (I think that's the word), so '("string" "strung") is equivalent to (list "string" "strung") but that's not true for e.g. '(sym sum) and (list sym sum). The first returns a list of symbols, the second will look up ‘sym’ and ‘sum’ as variables and will fail if they're unbound.
<ani>mfg: or is there anything else require
<ani>??
<nefix>nckx: oh, so using '(<vars>) is like a list of pointers and (list <vars>) are the actual values?
<mroh>nefix: (list 1 (+ 1 1) (+ 1 1 1)) => (1 2 3). But '(1 (+ 1 1) (+ 1 1 1)) => (1 (+ 1 1) (+ 1 1 1))
<mfg>ani: one good thing would be to put your packages inside cran.scm alphabetically ordered. Another thing is: guix lint your definitions.
<nckx>Sure, I guess, if you don't take that too literally. Lisp isn't C. But yes, variables are symbols that ‘point’ to values. An introduction to Scheme would do a much better job of explaining this than I am 🙂
<nckx>But the core concept here is quoting, not so much variables. You can quote entire s-expressions, as mroh illustrates, not just symbols.
<vits-test>sneek: seen quote?
<sneek>I think I remember kete in (here?) 9 months ago, saying: :-) maybe arch wiki will help :-P.
<nefix>hmmm, it's being a little hard for me to understand scheme. But I guess it's just a matter of time! :D
<nefix>thanks!
<nckx>sneek has an odd accent.
<civodul>what's the deal with undo history in Emacs 27?
<mfg>ani: essentially the points listed in: https://guix.gnu.org/manual/en/html_node/Submitting-Patches.html
<civodul>looks like it keeps just 10 elements
<nckx>nefix: Try searching the Web for tuturials/explanations of only Scheme/Lisp quoting without other distractions. Understanding that is probably 33% of understanding Scheme, and will make it much easier to understand the code you're reading to learn the other 66%.
<nefix>nckx: I see, thanks! :D
<vits-test>sneek: ../...-/.-/-./--..-- ..- -././...-/./.-. .--/./.-./. .../--- -.-./.-../---/.../. -/--- ..-./.-/../.-../..-/.-././.-.-.-
<civodul>nckx: what about the remaining 1%?
<nckx>That was deliberate 😉
<civodul>:-)
*nckx TIL #false, BTW.
<lapin>hello i try do make my own package but i cant correct this lint error
<lapin> le nom du fichier source devrait contenir le nom du paquet
<civodul>nckx: rekado_ was proposing using #true/#false all around, which i support, so i think we should mail a heads-up to the list
<civodul>salut lapin
<roptat>lapin, il te manque sans doute le champ file-name dans l'enregistrement origin
<civodul>lapin: this is about a convention where the file name of the origin should match the package name
<civodul>voilà :-)
<roptat>si tu utilise la méthode git-fetch, tu peux rajouter quelque chose comme (file-name (git-file-name name version))
<lapin>then if i define my package as (package (name "dbus-cxx") (version "0.12.0") ...
<lapin>the name of the file should be ?
<roptat>par défaut le nom de la source c'est "checkout", ce qui correspond pas au nom du paquet. file-name permet de changer ça pour avoir un nom plus propre, nom-version-checkout
*vits-test one Noldor.. two.. three.. + Belgian man.. four..
<roptat>it should start with dbus-cxx-0.12.0
<roptat>now if you're inheriting from a package and share exactly the same source, you can ignore the lint warning
<lapin>i think i will ignore this message
<mroh>civodul: maybe undo-limit, because "This variable was added, or its default value changed, in Emacs 27.1."
<lapin>the other package don't apply it, isn't it?
<nckx>vits-test: If that was aimed at me I'm afraid I don't understand. I know my Tolkien but there it ends.
<nckx>civodul++
<roptat>lapin, sorry, I didn't understand
<nckx>civodul: I also support (but perhaps it's already a style rule?) using LIST over '() wherever possible. ‘We’ don't care, but a newcomer should not have to wonder why replacing "--foo" with (string-append "--foo=" x) in a list suddenly ‘fails’.
<roptat>zimoun`, good news I think, the issue we're experiencing with dune is actually an issue in OCaml, and it's fixed in 4.11, so we'll have to upgrade to 4.11; there are still some issues apparently, but probably unrelated to the problem we have right now
<lapin>if i specified the version i need to shange the name of my module ?
<roptat>not the name of the module, only the name of the sources
<roptat>the module can have any name, it doesn't matter
<roptat>maybe share your code (on paste.debian.net for instance) so we can better help you?
<lapin>ok i will do it
<roptat>zimoun`, so I'll review your comments and push the dune upgrade; then send a bug report with all the info I have about and I'll see what needs to be done to update to 4.11
<lapin> http://paste.debian.net/hidden/ab35feb9/
<zimoun`>roptat: cool!
<roptat>lapin, so in the origin record, right before sha256, add (file-name (git-file-name name version)) that will remove the lint warning
<zimoun`>do you think if the upgrade is doable for v1.2 ?
<roptat>sounds tricky
<roptat>depends if I can find a way to do it properly this week-end
<roptat>I think I'll push a change to the dune build system to use -j1, that'll make everything reproducible
<roptat>or #:parallel-build #f by default (but then the dune-build-system needs to support it ^^')
<apteryx>runc fails to build on master
<roptat>I know I can build OCaml 4.11 very easily, but not all package we have is actually compatible, so we'll need to do some upgrades/keep some on 4.09
<apteryx>(breaks dockerd)
<lapin>ok thanks
<roptat>so I'll add ocaml 4.11, then add package-with-ocaml4.09; then I'll need to figure out what to do before I can switch ocaml to 4.11 by default; then I'll see what needs to be done before I can use ocaml 4.09 instead of 4.07, and get rid of 4.07
<zimoun`>roptat: I will see next week if what is done in Haskell about parellel-build? could be mimicked.
<roptat>OK, I guess I'm leaving this to you then?
<zimoun`>well, remove all 4.07 needs some work and I am not sure it is doable for v1.2 whitout too many breakage
<roptat>yeah... that's why I want 4.11 first
<roptat>zimoun`, we also need to work on the guix days though, I think it's our priority right now
<zimoun`>Once ocaml4.11, maybe package-with-ocaml4.11 could be helpful to easily check what is breaking.
<zimoun`>yep! It is on the top of my TODO :-)
<roptat>we really need to release the website change quickly, do you think you can do it before this evening? I guess we'll need some maintainers' approval first :)
<nckx>roptat: Link/#?
<roptat>we've been working on it with zimoun`, but haven't submitted anything yet
<roptat>zimoun`, should I submit the patch to guix-patches now, or do you want to do it yourself later?
<roptat>zimoun`, (for the website)
<zimoun`>I am going to send in a couple of hours with some updates I did, is it ok for you?
<nckx>`, is doing weird things to the Scheme pattern recognition part of my brain. Stop firing, silly neurons. roptat: What are they about and why are they urgent?
<nckx>Or zimoun`.
<roptat>zimoun`, ok, thank you!
<roptat>so we want to have a conference end of november, but we need to get presentations and everything, so the change adds a banner to the website to announce it, with a link to a blog post that explains how it's going to happen
<nckx>Ah supercool.
<roptat>basically, we want to have talk proposals before next week (it's basically just filtering on what people want to talk about, to prevent off-topic), then we give them some time to prepare a video and we release them one week before the conference
<roptat>that way, people can watch them beforehand and prepare questions, we won't have a live presentation, only some Q&A and discussion (BoF)
<zimoun`>nckx: I do not know how to rename me. Since I logged with zimoun and then I do not know what happened and paf! I am zimoun`.
<nckx>What does ‘/nick zimoun’ say?
<OriansJ>Day 3 of guix source tarballs collection: I have finally processed 60% of the links and have only obtained 23.8GB of the estimated 42.5GB that is expressed in that download percentage
<civodul>nckx: re using 'list', sounds good (but only in package definitions i guess)
<zimoun`>nckx: the proposal should be on your guix-maintainer mailbox, somehow :-)
***vits-test is now known as zimoun
<zimoun>zimoun`: dont do this!
***zimoun is now known as pink-elephant
<civodul>:-)
<nckx>I want whatever toxic metals are in the Siberian tap water.
<OriansJ>I should have the final third party health report before the end of the week
<roptat>we hope that doing it that way, we give more time to people to think about questions, and we'll have more time for Q&A than normal conferences. That's how the activitypub conference did, and I think it was great
<nckx>OriansJ: Cool. Are you trying all mirror:// URLs?
<OriansJ>nckx: just move to Flint Michigan ;-p
<nckx>Oh dear.
<mroh>apteryx: seems, commit "Install license files" (6b793fa662) doesn't work in docker,docker-cli builds for some reasons. (missing "src/" dir?)
<zimoun`>nckx: /nick zimoun says already in use
<OriansJ>zimoun`: use shadow
<OriansJ>correction: msg nickserv ghost USERNAME PASSWORD
<nckx>zimoun: but ‘/ns info zimoun’ is you, right?
<nckx>(/ns is short for /msg nickserv, at least here.)
<zimoun`>nckx: yes. Sorry for these naiveness about IRC
<OriansJ>as registered users can always reclaim their nicks
<roptat>oh, I registered 5 years ago already!
<zimoun`>how can I reclaim my nick?
<nckx>zimoun: OriansJ's right. If the person currently using ‘zimoun’ is not you (logged in elsewhere), ghost them like a bad ex.
<roptat>/ns ghost zimoun PASS
<OriansJ>zimoun`: here are some basic notes for you: https://paste.debian.net/1167313/
<roptat>thanks for /ns, I didn't know that :)
<zimoun`>nckx: that’s said: not online
<nckx>Are you registered with NickServ?
<zimoun`>OriansJ: thank you. I should find my way :-)
<zimoun`>nckx: yes
<nckx>Sorry, I meant ‘identified’.
<nckx>/msg NickServ IDENTIFY <Nick> <Password>
<nckx>If you're using SASL you're auto-identified. If you don't know what that is, that's fine too.
<zimoun`>ok
<lapin>Did we have in the package definition a way to do the equivalent of bash export "export VAR=value" to be used by the compilation process ? something like (compile-env '(var value) )
<nckx>(setenv "VAR" "bar")
<nckx>In a phase.
***zimoun` is now known as zimoun
<nckx>E.g., (modify-phases %standard-phases (add-before 'configure 'set-GUIX (lambda _ (setenv "GUIX" "neat") #t)))
<nckx>zimoun: \o/
<zimoun>\o/ Thank to OriansJ pastebin :-)
<nckx>lapin: Er, sorry, #true instead of #t, now 😉
<nckx>Although (civodul) wasn't the whole #t) thing supposed to be a temporary kluge?
<OriansJ>it is in emacs org-mode format for easy addition to org-mode note files
*nckx takes curious lookings at OriansJ's pastebin.
<lapin>thanks it's workking as expected
<nckx>OriansJ: ‘Authenticate to Nickserv’ == ‘Authenticate to server’ no?
<nckx>I'm guessing it's an amalgamate of sources.
<roptat>what's the difference between nickserv and NickServ?
<nckx>None.
<OriansJ>nckx: I am king typo for a reason ^_^
<nckx>Nicks are case-insensitive bastards.
<roptat>oh
<OriansJ>good thing too; but unicode support those that benefit out the window (see wikipedia incident for further info)
<OriansJ>^those^Throws^
<nckx>OriansJ: Which Unicode support?
<nckx>sway[754]: segfault at 12fcb80 ip 00000000012fcb80 sp 00007ffc9091a098 error 15 cpu 0
<nckx>:-/ Goodbye, 12 workspaces of state.
<drakonis>nckx: see my messages elsewhere
<nckx>👍
<OriansJ>nckx: some services allow unicode characters in nicks; which presents a considerable problem when you have some unicode characters that look like ascii characters people use in usernames
<nckx>OK, I thought you meant Freenode.
<nckx>Said services cray, 'nough said.
<nckx>It sounds welcoming & all but it's risky beyond all hell.
<PotentialUser-47>Hello, can someone help me with this "guix build" error: "ice-9/boot-9.scm:3300:6: In procedure resolve-interface:
<PotentialUser-47>no code for module (guix packages python-xyz)"
<PotentialUser-47>I am trying to build a package that depends on an existing python-* package using the python-build-system.
<zimoun>Why the devel/en/manual is 26 August 2020 and for example the Getting Starting section is absent
<zimoun>?
<roptat>did it stop building?
<janneke>zimoun => https://guix.gnu.org/development/manual/en/
<roptat>it's also dated from august 26
<janneke>oh wait
<janneke>=> https://guix.gnu.org/manual/devel/en/html_node/
*janneke had this confusion too
<zimoun>janneke: yeah and I am almost sure it was up to date. I remember checking the recent Channels move.
*civodul pushed initial documentation of (guix build utils)
<civodul>long overdue... but it needs more love!
<raghavgururajan>roptat: Are you available to do some pushing? 🙃
*raghavgururajan is desparate about #43575. 🥺
<roptat>raghavgururajan, maybe this evening
<roptat>raghavgururajan, looking very quickly the content, you'll need to add a line or two at the beginning of the patch for farstream, say where it's from
<roptat>also, why gajim-next? not gajim? add a comment to explain why gupnp-igd and libxss are commented out (TODO? build issues?)
<civodul>hey raghavgururajan!
<civodul>raghavgururajan: what happened to your desktop branch?
<civodul>i remember asking dannym about the merge plan, but i don't remember reading a reply
***stikonas_ is now known as stikonas
<zimoun>roptat: building the website is really painful! Too much warnings. And a single tweak implies rebuild a lot. Hum?
<roptat>zimoun, yes, but I don't know why
<roptat>normally haunt doesn't have to rebuild all of guix :/
<zimoun>changing a comma and my CPU is burning more than recompling all the OCaml packages ;-)
<roptat>isn't the website building on a single core?
<zimoun>not yet. :-)
<roptat>so, haunt has its own guile, /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2/bin/guile which seems to be the culprit (from a repl, loading (guix build utils) gives the warnings about incompatible bytecode)
<raghavgururajan>roptat: Thanks! I think you are looking at old patches. The new ones are different. :-)
<roptat>raghavgururajan, ah, ok
<roptat>zimoun, maybe it's time to use --with-graft?
<raghavgururajan>Regarding gajim-next, the new version has drastic interface changes. So good to have gajim-next for some time and then deprecate the older version.
<nly>man, this is rough. An incomplete i2p-service-type: https://cutt.ly/zgfStQw
<raghavgururajan>civodul: Hey! Some are under review by Danny at #42958
<roptat>zimoun, yes --with-graft is wonderful :)
<roptat>do guix environment --ad-hoc haunt --with-graft=guile@3.0.2=guile -- guix environment --ad-hoc guile guile-json guile-syntax-highlight gnutls
<raghavgururajan>civodul: More will come soon. I will be back to working on that this Monday. Had some work in the past days.
*zimoun is trying roptat command.
<siginT`>Hi guix can some one give me some insight on the emacs-guix geiser no prompt found error
<zimoun>roptat: hum? it does not work for me, as-is. Need investigation. I will do later
<siginT`>I havent been able to find a solution, I checked the bug report on the emacs-guix repo but it hasnt been solved
<roptat>zimoun, I might have ommited some packages that are specified in the README
<mroh>siginT`: I stay at emacs-geiser@0.11.2, emacs-guix works (more or less/good enough for me) with that version.
<zimoun>I have run with all the required packages. I just did C-a and add the “guix environment –ad-hoc haunt –with-graft=… --”. Anyway, I am done with building the website. :-)
<siginT`>?
<siginT`>sorry not intended new to irc
<rekado_>raghavgururajan: I think it’s very unusual to keep an older version of gajim.
<rekado_>raghavgururajan: the new version is the latest official release, so we should just name it “gajim”
<rekado_>if someone needs the old version they can use the time machine.
<raghavgururajan>rekado_: Okay, can I make a patch that removes older version of gajim in messaging.scm and rename the gajim-next to gajim in gajim.scm?
<siginT`>siginT:
<rekado_>raghavgururajan: yes, but then you can just squash these two patches into one, no?
<zimoun>help: English proofread required for #44022 (guix day announce) co-authored with roptat
<raghavgururajan>rekado_: you mean remove and rename in a single patch?
<rekado_>raghavgururajan: sorry, maybe I’m missing something here
<rekado_>raghavgururajan: if gajim-next doesn’t exist yet there’s no need to rename it
<rekado_>you’d just upgrade gajim to the latest version
<raghavgururajan>rekado_: I see. The pack-def I made for gajim-next is different from the older definition. May be for the newer definition, I use the package name as "gajim" and variable name as "gajim-next"? In this way, guix install gajim installs the latest version.
<rekado_>raghavgururajan: I’m confused: why not upgrade and make all the changes necessary for the upgrade in one commit?
<rekado_>we often do that
<rekado_>if an upgrade needs new inputs we add them in the same commit
<raghavgururajan>I could. I am often told that, too many changes in one commit. If I can make changes needed by upgrade, in a single commit, is that okay?
<rekado_>yes, certainly
<raghavgururajan>Cool!
<rekado_>if they are necessary for the upgrade they can all go in one commit
<raghavgururajan>roptat: let me send a revised patch-set.
<rekado_>if you *also* add optional stuff … that wouldn’t be great
<raghavgururajan>Ah okay.
<rekado_>e.g. enabling an extra feature that requires more inputs, etc
<raghavgururajan>Gotcha!
<roptat>raghavgururajan, for optional stuff: do one commit to upgrade the package, and antoher commit to add the feature
<raghavgururajan>roptat: What about missing inputs? Some dependencies are shown as "foo not found" during config phase. Those can be added as inputs in the upgrade commit right?
<roptat>that's in the upgrade commit
<roptat>you can't have a commit where a package is broken
<raghavgururajan>Also, the newer version doesn't depend on foo anymore, the foo input can be removed in upgrade commit right?
<rekado_>yes
<rekado_>it should be removed with the upgrade commit
<raghavgururajan>Cool!
<raghavgururajan>Same for arguments right? Remove those no longer apply and add new ones?
<rekado_>yes
<raghavgururajan>Okido (quoting nckx).
<rekado_>as long as that’s part of the upgrade and not something that adds or removes features beyond what’s needed for the upgrade
<raghavgururajan>Btw, I think #41111 was closed by Danny accidentally. The patch-set had 6 patches, but only 2 were pushed and closed.
*raghavgururajan notified Danny
<joshuaBPMan>Does anyone have any experience making a smart (or dumb) phone?
<jonsger>joshuaBPMan: in which way?
<mfg>joshuaBPMan: Do you mean designing custom hardware?
<joshuaBPMan>I just mean a DIY dumb or smart phone. It only needs to be VoIP and preferably free software only.
<joshuaBPMan>Thought with the pinephone only costing $140...it may not be worth me DIY-ing it.
<raghavgururajan>joshuaBPMan: Necunos C1 ?
<joshuaBPMan>raghavgururajan I've heard of that. I wonder if they've shipped yet.
<raghavgururajan>First batch sold out. Second batch yet to come.
<joshuaBPMan>ok. Do you know the price tag on that? Shipping to the U.S. from finland is probably expensive....
***jess is now known as j
<civodul>roptat, zimoun: we should change to guile-3.0-latest in the .guix.scm file of the web site, if that's an option
<cbaines>I wonder if it would be useful to have some way of annotating Patchwork/Mumi with some details for the submitter, something to tell you if they have commit access, they've had a few patches merged, or if this is the first patch they've submitted...
<cbaines>In other news, I rebooted the server running patchwork.cbaines.net, and it came back with colours https://patchwork.cbaines.net/ it must have been updated at some point.
<roptat>civodul, but that would rebuild guix with that other guile, no?
***j is now known as jess
<joshuaBPMan>cbaines: I'm all for that! We could have little badges: this person helped write a blog post. This person wrote a service definition. It would be a way to motivate and encourage users to contribute!
<cbaines>joshuaBPMan, that sounds like https://contributors.debian.org/ instead, which would also be nice to have
<cbaines>In this instance though, I'm thinking about patch review, so it would be helpful to know if they're a committer, as then I'll just say it's OK, and won't push it. Or if they're a first time contributor, I'll know to explain things a little more.
<civodul>roptat: we could just define a variant of haunt with guile-3.0-latest as an input
<civodul>dunno, i haven't checked
<roptat>yay, that would work I think
<joshuaBPMan>cbaines...hmmmm maybe I've got a project to start working on then for guix...
<cbaines>joshuaBPMan, I think what you're describing would probably work for the simpler use case I have in mind as well
<civodul>cbaines: yay for the colors at https://patchwork.cbaines.net/ :-)
<zimoun>civodul: about the website, I am not sure to understant what is the issue
<zimoun>what I was doing before (sources.json) raises a lot of warning and I do not see what have changed since then
<civodul>zimoun: i guess it's the .go file incompatibility between 3.0.4 and 3.0.2
<civodul>(Guix uses the former, Haunt the latter)
<zimoun>cbaines: cool for patchwork. How the Under Review state is done?
<cbaines>zimoun, manually by someone (me) changing it through the web interface
<cbaines>I also added a "Work in progress" state just now, as I wanted to skip over some patches that still need some work
<jonsger>uff, that is strange. I'm working on phoc, a compositor. In the test suite it compares a certain state as png with a ping in the source repo. It's almost the same but "our" mouse cursor is a bit different then the one upstream used. So the pngs differ :P
<zimoun>civodul: ah yeah. that’s make sense. :-) Is it not possible to update haunt?
<zimoun>cbaines: :-)
<zimoun>civodul: hum? guile-3.0-latest as haunt inputs leads to a lot of failure and the end result is: “successfully built” :-)
<raghavgururajan>roptat: I have sent revised patches for #43575 :-)
<civodul>jonsger: it's the kind of test suite that's interesting :-)
<jonsger>yeah, but I disabled it for now
<zimoun>civodul: is it expected: “guix environment --ad-hoc haunt --with-input=haunt=guile@3.0.4 -- haunt -h“ that returns ‘no haunt’
*zimoun is puzzled by transformations
<civodul>zimoun: it's not haunt that you want to replace by guile
<civodul>it's guile@3.0.2 that you want to replace by guile@3.0.4
<civodul>but if you try that, that'll rebuild the world
*civodul -> zZz
<civodul>night!