IRC channel logs

2019-11-27.log

back to list of logs

<jboy>I using guix environment as an interpreter shebang in scripts now possible (the way that nix-shell can)? I saw that it was discussed once many moons ago: http://logs.guix.gnu.org/guix/2015-06-13.log
<jboy>Is*
<ScaredySquirrel>guys will you help me fix my xorg server?
<ScaredySquirrel>my xorg server is really broke it cannot find any input drivers
<leoprikler>jboy: I'm not aware of any such option, but have you looked into Guile's extended shebangs?
<jboy>leoprikler: yes, but I think the use case for those is different
<leoprikler>Indeed it is.
<leoprikler>sneek, later ask davexunit did you ever get to implement the guix environment shebang?
<sneek>Will do.
<leoprikler>Reading the thing itself, it still sounds like a rather trivial script in and of itself.
<leoprikler>And I don't know how to words again
<ScaredySquirrel>hello I need help with my xorg server not finding any input device drivers
<ScaredySquirrel>I have all the xorg input and video drivers installed but xorg doesn't find them all
<nojr>Hi, could someone help me understand guix environment?
***catonano_ is now known as catonano
***jonsger1 is now known as jonsger
<dongcarl>sneek: botsnack
<sneek>:)
<ScaredySquirrel>sneek: determine guix fate
<KE0VVT>Hm. GNOME Software won't work on Guix System until support for Guix (an Nix?) are added to PackageKit.
<KE0VVT>Then again, the features of Guix and Nix might make forking GNOME Software worthwhile.
<khimaros[m]>On GuixSD, are there packages which SHOULD or MUST be installed system wide rather than in a user profile?
<lispmacs>Hi, what do I install in Guix to run Java apps?
<bdju>lispmacs: openjdk maybe
<bdju>or icedtea
<apteryx>leoprikler: thanks for the hindsights regarding emacs
<apteryx>I've just implemented a two patches with your suggested changes, will be testing it shortly!
<xvilka>Hi! Whom I have to ping about the old package version in Guix? https://repology.org/project/ocaml/versions shows GNU Guix has 4.07.1, while the latest available version is 4.09.0, with many important improvements and fixes
<khimaros[m]>xvilka: it looks like repology is pulling that data from https://guix.gnu.org/packages.json which currently says `{"name":"ocaml","version":"4.07.1"`
<roptat>xvilka: thanks for the info, I'll take care of the update this evening
<xvilka>roptat: khimaros[m]: thanks!
<roptat>mh? I'm running guix pull --commit=aca2bf5 for two different users on the same machine, and I get a different derivation for compute-guix-derivation. Is that expected?
<paprika>hello
<paprika>I have trouble playing mp3 and mp4 in icecat
<paprika>on Guix System
<roptat>same here :/
<paprika>I've installed mpg123 but no luck
<paprika>you don't know how to fix it, roptat? you're always the one providing answers to me...
<roptat>no, sorry :(
<Franciman>same here
<roptat> https://issues.guix.gnu.org/issue/38045
<Franciman>paprika, my current workaround is using mpv and youtube-dl
<Franciman>otherwise you can try ungoogled-chromium
<paprika>thanks for the tip Franciman
<paprika>is ungoogled-chromium a fork of chromium?
<paprika>ah, according to the github it is
<paprika>oh it's actually not as bad as I feared
<paprika>but I still prefer icecat to work soon...
<lurch>roptat, thanks for the link (https://paste.debian.net/1118032/) short question: every double quote is escaped except for the ones at "tapping" - this is a error, right?
<zimoun>rockandska: thank you. I prefer the discussion over email, it eases my "batch workflow". :-)
<roptat>lurch: right, they should be escaped
<zimoun>hi roptat, have you seen nix-home-manager ? https://github.com/rycee/home-manager
<zimoun>and see this (french) post https://linuxfr.org/news/gestion-de-paquets-evoluee-avec-nix-cachix-overlays-et-home-manager
<roptat>Haver't read yet
<zimoun>just for sharing in case you have missed it :-)
<lurch_>thanks for your help roptat! :D
<zimoun>roptat: thank you to open the discussion about the Cookbook. I was reading similar thing than https://www.divio.com/blog/documentation/ considering what we could prepare to submit proposal for the next round of GSoD (if any). However, I am not convince by the 4 parts. I will answer to your email, instead. :-)
<zimoun> https://developers.google.com/season-of-docs
<davie`>zimoun: nice article!
<grumbel>Given a definition like (package ... (source (local-file ...) ...) is there a way to include additional files/patches in the source or combine multiple (local-file ...) into one?
<roptat>grumbel, you could use a computed-file instead, I think
<roptat>that uses a gexpression, and you can put multiple local-file in it
<roptat>zimoun, yes, please do!
<roptat>zimoun, I just read the article, so I probably am too enthusiast and didn't see the drawbacks :)
<Franciman>how can I make hexchat open links with icecat?
<Franciman>looks like it uses gio to manage mime
<Franciman>mimes
<Franciman>but I don't know which package to install
<Franciman>I installed xdg-utils and everything is set correctly
<Franciman>but hexchat still doesn't open links with icecat
<roptat>Parameters -> URL manager (or something equivalent, I have it in French here :))
<roptat>although that's for when you right-click on a link
<Franciman>I'd liked to directly click
<Franciman>but it's better than nothing, thanks roptat !
***sturm is now known as Guest84978
<civodul>Hello Guix!
<civodul>woow, lots of people here
*civodul just restarted cuirass on ci.guix.gnu.org
<janneke>hello civodul!
<civodul>hi janneke!
<civodul>roptat: i'm forcing an update of the web site, too
<roptat>thanks
<civodul>it seemed to have been updated, but for some reason your post didn't show up
*vagrantc waves
<civodul>hey!
<roptat>is some metadata broken in my article?
<rockandska>civodul: Hi ludovic, i will reply on ML but i think to start what's happening with my problem on 'guix pull' under docker with alpine
<civodul>roptat: i don't think so, but lemme check
<civodul>rockandska: oh good!
<rockandska>civodul: i didn't take the time to search inside source code but i think many actions are based on $HOME / $USER, but for some reason, under alpine $USER is not defined and even force it doesn't work
<rockandska>civodul: so i think guix use $USER to create the symlink, and since $USER is not set, truncate the part 'per-user/root/' to only let 'default'
<rockandska>civodul: this behavior let me think that guix maybe need to use '~user' instead of $HOME, and 'whoami' instead '$USER' in case those env variables are not set
<civodul>roptat: actually it's just that it was marked as coming from *October* :-)
<roptat>oh, oops :)
<roptat>can you fix?
<civodul>done
<civodul>so it should show up Real Soon Now
<civodul>but i think aggregators like planet.gnu.org will be a bit confused
<civodul>or gwene.org
<g_bor[m]>Hello guix!
<civodul>rockandska: Guix uses /per-user/$USER
<civodul>so it can be "/per-user/default", but it cannot be "/default" i think
<civodul>that's why i was surprised :-)
*civodul goes afk for a bit
<rockandska>so maybe it is not the real reason.... i rebuild my images by forcing $USER and will see if it solves the problem or not
<zimoun>civodul: context: the "guix pull" Docker Alpine blah issue. Why does "guix pull" migrate stuff? I am reading the code but not sure to understand.
<g_bor[m]>rockandska: similar issues has been discussed in relation with sudo behaviour.
<zimoun>civodul, rockandska: it is "guix pull" that changes "profiles/per-user/root" to "profiles/default".
<zimoun>g_bor[m]: do you remember more?
<rockandska>zimoun: indeed, and didn't get why at this time. but guix pull recreate symlink, that's why i was thinking doesn't have $USER set could be the cause
<zimoun>rockandska: I see.
<g_bor[m]>zimoun: I believe there was an intentional mismatch introduced there. I can't remember the rationale, but part of the code uses the environment variable, while another part not...
<zimoun>g_bor[m]: I see. Thank you.
<g_bor[m]>That was around the same time when we discovered that ubuntu provides a patched sudo by default...
<g_bor[m]>I am on mobile right now, so my possibilities are limited...
<g_bor[m]>Issue 36785 might shed some light.
<g_bor[m]>It discusses the profile migration code and its interaction with sudo.
<zimoun>g_bor[m]: thank you. I am learning :-)
<davie`>Hi Guix! Exited to e-meet you all.
<davie`>Im have big plans with Guix. I'm working on IPDB (ibdb.io) and we are going to integrate guix in all sorts of development activities.
<davie`>I've done package definitions for our python app - BigchainDB and tendermint packages are on the way too
<roptat>davie`: cool :) if it's free software, don't hesitate to contribute :)
<davie`>The cool thing is that we have plans of building global decentralized multi-federated-network of ipdb nodes. So we need to have means to deploy our software on different platforms an architectures and guix feels like a perfect fit for this task.
<davie`>roptat: Yep its 100% open source. It's core components BigchainDB and Tendermint currently under Apache license
<roptat>I have no idea what those are, but they're welcome in guix, then ^^
<davie`>I need to do some preps I'll do our guix channel first and test thing out first
<raghavgururajan>Hello Guix!
<nckx>o/ raghavgururajan.
<raghavgururajan>o/
<Franciman>I am writing a package in which I use a trivial-build-system
<Franciman>but I need to run tar -xzf, because the source is a tar.gz file
<Franciman>which native-input should I use?
<Franciman>using only tar doesn't work
<nckx>Franciman: And yet, ("tar" ,tar) is the correct answer. What's your exact problem?
<Franciman>tar (child): gzip: Cannot exec: No such file or directory
<Franciman>this is the error I get
<Franciman>so I should add ("gzip" ,gzip) too
<Franciman>?
<Franciman>but I am afraid that tar won't see gzip
<nckx>Because t-b-s doesn't even set PATH for you. You need to specify the full path: (string-append (assoc-ref %build-inputs "tar") "/bin/tar").
<nckx>Franciman: Yes, same for gzip. 🙂
<Franciman>nckx, how do i tell tar where gzip is?
<Franciman>ah probably I need to run gzip separately
<nckx>No, for that I'd use (setenv "PATH" (string-append gzip "/bin")) so tar can find it with "z".
<Franciman>cool
<Franciman>and it's only local to the build, right?
<Franciman>I mean the env change
<nckx>Where gzip is (let ((gzip (assoc-ref %build-inputs "gzip")))-bound to keep things neat.
<nckx>Franciman: Yep!
<nckx>The build environment is as isolated as can be. If not, plsease report a serious bug.
<Franciman>it works!
<Franciman>thanks
<nckx>Cheers 🙂
<Franciman>oh I see ok
<Franciman>one more question. The program I want to install comes with a default config I should put in $HOME/.config/
<Franciman>but I can't put it there from my build env, right?
<Franciman>this would contradict everything
<nckx>Franciman: Indeed. I usually put stuff like that in /etc or /share/doc/,name-,version/examples.
<Franciman>perfect
<nckx>If it's only ever stored in $HOME I'd choose the latter.
<Franciman>thnx
<Parra>I'm having a very strange problem, I'm doing: guix pull && guix package -u && guix package -i nss-certs
<g_bor[m]>davie`: hello!
<g_bor[m]>This looks really promising
<Parra>after last command, I have this error: updating substitutes from https://ci.guix.gnu.org 80%guix substitute: error: TLS error in procedure 'read_from_session_record_port': the TLS connection was not properly terminated
<g_bor[m]>You might be also interested in guix deploy on the long run
<Parra>and it's strange because a docker image that I built in the past with the same exact commit is working properly
<Parra>if I rebuild the same commit now this happens
<Parra>and I have the image on my local working properly
<davie`>g_bor[m]: Yep, found out about guix deploy just recently. Looking forward to try it out!
<g_bor[m]>Parra: is that consistent? Looks like a network issue to me
<nckx>Parra: I don't quite understand your last 3 lines, but the above looks like a ‘mere’ networking error to me. Not a fault with your installation.
<Parra>also: guix package error: substituter "substitute" died unexpectedly
<Parra>it's seems a network error but it happens in all enviroments I try ir
<Parra>on local, and on Travis
<Parra>it started happening recently
<nckx>Parra: That dying is just Guix not handling network failure very well.
<roptat>yes, it happens to me too, but it works after a retry
<nckx>Parra: The networking error is probably on ci.guix's end, not yours.
<Parra>:/
<Parra>now what?
<Parra>if I disable the ci it will take hours to compile
<Parra>but it can be a workaround, isn't it?
<roptat>yes, it would not trigger the issue
<nckx>for i in `seq 1 50`; do guix whatever; done ? :-/
<nckx>Then go get lunch.
<Parra>XD
<Parra>dude
<nckx>I agree, it sucks, and CI is definitely a very weak link in the Guix chain right now.
<Parra>another alternative apart from disabling the ci?
<nckx>I don't have any other ideas, but I don't deal with the CI often.
<Parra>like make -k when doing the substitutes
<Parra>but when *
<nckx>Guix is just too damned fragile when networking starts to fail.
<nckx>s/Guix/Guix or Guile's HTTP client/
<Parra>ok
<raghavgururajan>nckx You were referring me to this (https://guix.gnu.org/manual/en/html_node/Building-from-Git.html#Building-from-Git) correct?
<Parra>so I will try to build everything by hand, avoiding the ci
<Parra>it may exceed the travis timeout of 50min
<Parra>when doing guix pull, does it download many things?
<atw>would --fallback ("When substituting a pre-built binary fails, fall back to building packages locally") be worth trying, Parra?
<Parra>that would be excellent
<Parra>how can I set that flag, in what command?
<nckx>That would definitely help mitigate substitution failures, but I don't think it affects the initial ‘updating substitutes’ probe.
<Parra>guix package --fallback -i nss-certs ?
<nckx>Parra: Yes.
<Parra>the initial seems to work nckx
<Parra>ok, let me try
<atw>yup, --fallback is one of the common build options, I think all your commands support it. If "make -k" does what I think it does, you might be interested in --keep-going too
<nckx>Parra: Oh, you posted ‘updating substitutes from https://ci.guix.gnu.org’ earlier, which is Guix doing a huge (thousand(s)) pipelined HTTP request blast at the CI.
<Parra>blasting XD
<Parra>but this is triggered in the package -i
<Parra>if I do pull && package -u it works perfectly
<raghavgururajan>nckx I successfully did `./bootstrap`. But when I did `./configure` I am getting "configure: error: C compiler cannot create executables".
<nckx>Parra: I don't think that means anything significant. The probe blast happens regardless, also during -i. Once Guix actually starts do download substitutes it already ‘knows’ which are available at the CI and which are not. The probe is a separate step to find that out.
<nckx>raghavgururajan: Are you running in a ‘guix environment guix’?
<nckx>raghavgururajan: I don't remember what we last talked about but that link looks like something I would refer people to, correct 🙂
<raghavgururajan>Yes. nckx Yes `guix environment guix --ad-hoc autoconf automake gettext texinfo graphviz help2man`
<raghavgururajan>nckx We were discussing what to do before doing `./pre-inst-env guix lint gnome-contacts`
<nckx>Parra: And that probe is unfortunately not affected by --fallback. However, results are cached, so if you run it often enough it can eventually succeed.
<Parra>they aren't cached in a CI
<Parra>it's always an image created from scratch
<nckx>Parra: Ah, shite, good point. I've only ever used Travis indirectly (it was the Nix project's CI) but I remember that now. It starts every run from scratch. Right.
<Parra>I don't understand why you mean by probe, I realized that it works if I remove the -i command
<raghavgururajan>nckx * since I get "bash: ./pre-inst-env: No such file or directory".
<nckx>Parra: By probe I mean that Guix first asks ci.guix ‘hey do you have this and this and this and this and this…’ and ci.guix responds ‘yes and yes but no but yes…’. Then Guix will make a plan of what needs to be built and what can be substituted. Only then will it start building and substituting things. That way, it knows which build dependencies need to be downloaded and which don't. Make sense? I'm not saying that's what's failing for y
<nckx>ou now, but it's what was failing in your first pasted error.
<nomr>Hey, where do I find the package for guix itself? I'm looking at the git checkout in pull cache to debug pull issues, and all the package declarations are there except for its own.
<nckx>raghavgururajan: Is there a config.log?
<raghavgururajan>nckx Just a sec.
<nckx>nomr: Not in package-management.scm?
<Parra>nckx: thanks, I'm going to experiment and I will come back with results
<nomr>hmm that file is not in this guix git repo: where do I find it?
<raghavgururajan>nckx https://bin.disroot.org/?bb2a82922a7c8316#C7wVdFVUZbJtCTrMZyfKAEQ5Vf8vEP2ysRg53g8L2X5m
<nomr>whoops nm typo searching
<nckx>raghavgururajan: I just did ‘echo 'int main() { return 0; }' > FOO.c && gcc FOO.c && ./a.out’ in the same environment you pasted above and it can definitely create executables. Probably a symptom of another error (missing dependency?).
<nomr>Thanks nckx
<raghavgururajan>nckx Hmm! I adhoced required things. `guix environment guix --ad-hoc autoconf automake gettext texinfo graphviz help2man`. Anything else required?
<nckx>raghavgururajan: No, and that's the command I used.
<nckx>ld: cannot find crt1.o: No such file or directory
<nckx>I don't get it.
<nckx>It works fine here. raghavgururajan: Could you add --pure before guix?
<nomr>My 'guix pull --commit=' is making manifests with empty propagated-inputs, not sure whether it is related to a previously-working channels.scm breaking
<raghavgururajan>nckx Sure, let me try with --pure
<nckx>nomr: How does a channels.scm break?
*raghavgururajan oops! gotta run.
<nomr>nckx: I'm using one from ludo I found online to use more substitutes on my ancient slow i686. It's giving 'Wrong type argument' on some json data and I noticed guile-json is no longer in current-guix profile.
<nckx>nomr: I still don't really understand how a channels.scm could do that. Could you paste it to paste.debian.net?
<nomr>My browser access is limited atm but here's his ml post: https://www.mail-archive.com/help-guix@gnu.org/msg05697.html
<nckx>nomr: Thanks.
<g_bor>oops... istm that the matrix is playing things on me...
<Parra>can I set maximum verbosity for substitutes?
<Parra>it always fails at 77.8%
<nckx>Oh, okay, wow, you are in fact parsing JSON in your channels.scm 😃 Colour me floored & corrected.
<nckx>DSLs == awesome.
<nckx>Parra: While downloading a specific substitute? Which one? (If you pass -M1 to guix whatever it will run one job at a time so the log output is in order.)
<nckx>Parra: If its during the ‘updating substitutes’ probe, then no, I don't think you can.
<Parra>exaclty nckx, during that phase of download substitutes
<Parra>oh shit
<Parra>the --fallback didn't work
<Parra>:/
<Parra>I'm going to try to disable substitutes
<nckx>So ‘download’, not ‘update’? OK. Then it should already tell you what it's substituting. Use -M1 to avoid overlapping output.
<Parra>it's during package -i, sorry about using incorrect terms
<nckx>Parra: You'll have to give some kind of ‘base image’ to Travis or that will take a very long time (and can easily exceed 50 minutes).
<Parra>ok
<Parra>I have another option
<Parra>I cam do the base image with Travis, with substitutes
<Parra>then disable it
<Parra>for compiling metacall I have a 20 core machine
<g_bor>nckx: i can't see you messages from matrix
<nckx>Parra: I don't seem to have made myself clear either: http://paste.debian.net/plain/1118231
<nckx>g_bor: Oh no! (…they told they person who couldn't hear them)
<Parra>it's the first one what fails
<nckx>Huh.
<Parra>I'm gonna do something
<nckx>I do not know how to debug that without looking at server logs.
<Parra>I'm going to change base image from alpine to debian
<Parra>alpine fails with dns resolution sometimes
<nckx>Parra: OK, good luck, I'll hold your $beverage.
<Parra>hahaha
<Parra>otherwise I will disable the substitutes
<Parra>but I have an image that it's working inside the 20 core machine so, whatever XD
***nckx is now known as _nckx
***_nckx is now known as nckx
<nckx>‘You were kicked from #guix by @appservice-irc:matrix.org / Reason: IRC connection failure.’
<nckx>Halp how do I Matrix.
<civodul>zimoun: oh it's the migration code in 'guix pull' that does that?
<civodul>roptat: https://guix.gnu.org/blog/2019/guix-on-an-arm-board/ \o/
<civodul>thanks for the post!
<roptat>yay \o/
<civodul>it shows up at the bottom on planet.gnu.org and scheme.dk/planet
<civodul>so be it!
<zimoun>civodul: apparently ;-) guix/scripts/pull.scm:l.467 I mean the function migrate-generations is applied, I guess.
<zimoun>civodul: in that case, %profile-directory is set to /var/guix/profiles/default
<narispo>hello, I see here: <https://guix.gnu.org/manual/en/html_node/Invoking-guix-deploy.html#Invoking-guix-deploy> the documentation promotes Digital Ocean, is that OK..?
<davie`>Yes, I thought of it too.
<davie`>It's a non-fee network service right?
<zimoun>civodul: which comes from an `or' case. The "culprit" is the "and=>", i.e., the (getenv "USER"), (getenv "LOGNAME"). As roptat, you and g_bor[m] said.
<roptat>did I say anything?
<roptat>what is a "non-free network service"?
<davie`>network service run by proprietary software
<civodul>narispo: Digital Ocean is not software, it's neither free nor non-free
<leoprikler>Isn't this the typical PaaS deal?
<civodul>i think so, though i'm not an expert
<civodul>so essentially they give you access to "machines", virtual or not
<narispo>civodul: Digital Ocean is a company that provides a service with a proprietary API that GNU Guix seems to explicitly support, so it would count as promoting non-free network services
<roptat>but it's not: you're not running the software
<roptat>essentially, even if they were running free software, it wouldn't change anything for you
<roptat>and I suppose the API is documented, since we implemented it
<narispo>It does change things for me. If I want to create another organisation because Digital Ocean's way of doing things doesnt fit me, I cannot because Digital Ocean keeps it's software being a proprietary walled garden.
<narispo>behind a *
<narispo>Supporting OpenStack API would be OK, supporting Digital Ocean is uhm
<civodul>like roptat writes, the API itself is not "proprietary"
<narispo>The API's documentation isnt what makes it free, otherwise MSDN would make all of their library support free, which they obviously arent
<narispo>YouTube is a non-free service that has a documented public API for uploading videos, same deal
<narispo>Kubernetes has libre implementations, it would be OK to support
<civodul>"free" or "non-free" doesn't apply to a service; however, you can talk about whether a service is running free or non-free software
<narispo>Same for OpenStack
<civodul>Kubernetes is software; Digital Ocean is not
<civodul>see also https://www.gnu.org/philosophy/who-does-that-server-really-serve.html
<narispo>The API you are supporting through GNU Guix is powered by software, whatever Digital Ocean calls that software internally
<roptat>also https://www.gnu.org/philosophy/network-services-arent-free-or-nonfree.html
<civodul>narispo: you're right, but it's not SaaSS
<civodul>IOW, it's not software that we actually "run", it's really a service to us
<narispo>I know, I already read this. And I do not agree, per these articles, supporting Digital Ocean deployments counts as promoting non-free services, especially how it's the only remote API that's documented in that page.
<roptat>well, we don't have any other, which is a bit sad
<civodul>right, we should work on that
<narispo>Right now, GNU Guix makes it easy to deploy arbitrary machines onto Digital Ocean because that's the only remote service that seems to be documented or even implemented, is that the message you want to communicate with FOSS?
<civodul>but it's very recent code too, so no wonder
<narispo>Right. Glad we are on the same page here!
<civodul>if you look at the doc above, there's also managed-ssh-machine or whatever it's called
<civodul>that's the backend we use to deploy build machines on ci.guix.gnu.org, for instance
<narispo>I think there is some cross-vendor deployment APIs that you could support. Interopability I think is at the core of the FLOSS philosophy.
<civodul>sure
<civodul>"guix deploy" was designed to allow for that flexibility
<narispo>Such as OpenStack or Kubernetes ones
<civodul>so each <machine> record has an 'environment' field
<narispo>OK, is there a reason to choose Digital Ocean more than a more libre friendly host?
<civodul>and there could be an openstack or kubernetes implementation of that
<civodul>it's just that "guix deploy" is roughly 2/3-month old :-)
<civodul>but you can help!
<davie`>I would be interested in it too
<civodul>i'm sure many people would like that
<leoprikler>narispo: there has been prior work for using Guix on Digital Ocean (in form of blog posts etc.)
<narispo>Mhm. I wouldnt have posted vendor specific things. It's advertisement, endorsement..
<leoprikler>i.e. people were using it before there was official Guix support and those prototypes eventually ended in Guix deploy
<narispo>Even though, Digital Ocean has been a corporate altruist with libre communities, they still develop and depend on proprietary software for their commercial services.
<leoprikler>I get where you're coming from, but unless the FSF starts their own free software hosting platform, you will always have to endorse some third party in some way.
<davie`>There are people hosting their channels with non-free packages. Same thing can be applied to deploy targets
<narispo>I would run CI in-house and upload signed artifacts onto distrusted commercial hosts
<leoprikler>I don't really get the difference between uploading signed artifacts or some arbitrary unsigned data to some third party to be honest.
<nckx>narispo: I second the call for your help with that!
<davie`>by the way I want to include "About CNU Guix" footnote in our channel RADME. Shall I include GPL license with it?
<narispo>leoprikler: Users of GNU Guix trust an infrastructure that's controlled by GNU Guix teams rather than Digital Ocean
<nckx>They own your RAM, uploading signed anything is just theatre.
<narispo>No, because the GNU Guix clients verify the signature?
<leoprikler>No, they verify the hash.
<leoprikler>And the hash itself can be manipulated if you're sufficiently malicious.
<narispo>I would like to help, I have complicated time availability, and my main workstation is a powerpc64le-linux-gnu machine which GNU Guix currently doesnt run on
<nckx>Your Guix client is completely replaced with a malicious copy on the virtual disc (owned by the host) and the RAM (owned by the host).
<narispo>I do not think we are talking about the same thing here. I'm speaking of the CI infrastructure maintained by the GNU Guix teams.
<nckx>narispo: Hehe, Power is another area in which we really appreciate help!
<narispo>That apparently is hosted on Digital Ocean
<davie`>nckx: life sucks
<leoprikler>It is not?
<nckx>narispo: …what? Not at all.
<nckx>Where would you get such an idea.
<leoprikler>CI is hosted on gnu.org
<narispo>OK, I misread what Ludo said.
<narispo>Everything's fine then.
<leoprikler>The only connection between Guix and DO is that you can host a Guix machine on DO using a guix deploy configuration.
<narispo>nckx: I already patches GNU Guix as much as I could to make it work on powerpc64le-linux-gnu but to go further I would need some experienced GNU Guix contributors, I've had a few calls for help here and the mailing list but I failed to gain interest.
<narispo>patched *
<civodul>narispo: i think jonsger (right?) is working on powerpc64le-linux-gnu as well
<civodul>you should team up!
<nckx>narispo: I'm sorry to hear that. I don't know your real/mail name, but I didn't get that vibe from the lists, just that the community of PPC64LE owners is, well, tiny, and the union of those and Guix contributors even more so.
<narispo>What needs to be done is upgrade the bootstrap path so that :
<narispo>Bootstrap gcc 4.9 is used to build gcc >= 6.2 with glibc <= 2.25 then take that newer gcc >= 6.2 to build it itself again with glibc >= 2.26
<narispo>civodul: I saw on the mailing list, he basically duplicated work that I already had done with the help of some guy called simplet? Few months ago already.
<civodul>bah, too bad!
<civodul>well we need to get the ball rolling
<nckx>narispo: samplet.
<civodul>upgrades need discussion with janneke & others working on bootstrapping for other arches
<nckx>narispo: That's really unfortunate, but it's quite the opposite of lack of interest from my POV.
<narispo>Yes I would really like if we could spend an afternoon, even this one. I can provide remote access to powerpc64le!
<narispo>I am not experienced enough with LISP-like languages and GNU Guix in general
<narispo>AFAICT, all of GNU Guix is currently built with gcc 4.9?
<civodul>i think the problem here is not going to be Scheme but rather all the nitty-gritty details of bootstrapping on ppc64le :-)
<civodul>narispo: nope, it's gcc 7
<narispo>on master?
<civodul>you can see that in (gnu packages commencement)
<civodul>on master, yes
<nckx>narispo: Power 9 machines for the Guix CI farm (you know, the one made of 100% real machines, not DO 😉 ) are even being considered. One of the worries is set-up & maintenance compared to x86. Sounds like you could provide some expertise there.
<narispo>civodul: for me, Scheme is a bit mystical
<civodul>nckx: "considered" in the sense that we'd accept donations, right? :-)
<narispo>I run POWER9 since a while, of course!
<civodul>those are costly
<narispo>You can have a CI machine for $5000-$6000
<narispo>With 8 cores, 32 threads, 32GB of RAM let's say?
<civodul>that's what i meant :-)
<leoprikler>The Guix CI farm, where 100% organic machines roam freely :)
<narispo>However, OSUOSL has an in-house OpenStack on POWER9
<narispo>They donate machines very easily to libre projects
<narispo>I could get a few for some projects
<civodul>that'd be sweet
<narispo>There's a simple form
<nckx>civodul: Aren't we always accepting donations? I meant buying them outright.
<nckx>Like the aarch64 boxes.
<narispo> https://osuosl.org/services/powerdev/request_hosting/ civodul
<civodul>nckx: well that'd need discussion, but AArch64 is arguably more popular and generally more affordable
<civodul>i think we have several OverDrive 1000's for the price of a single POWER9 machine
<narispo>Literally just send a request, they'll handle it in maximum a week and you got yourself a machine to do anything you want on
<nckx>civodul: It is being discussed, nothing more. Hence ‘considered’.
<narispo>aarch64 is less attractive for libre
<civodul>yup
<nckx>narispo: Problem is the average Guix hacker probably won't be able to very much.
<nckx>narispo: No argument there.
<nckx>s/to very/to do very/
<narispo>civodul: are you going to send that request or should I do it in the name of GNU Guix and hand you access later?
<narispo>s/later/as soon as I get it/
<civodul>narispo: i guess i & fellow maintainers would be happy to send a request on behalf of the project
<civodul>but we need to have a prototype before
<civodul>IMO at least
<civodul>and that's where you come in :-)
<nckx>narispo: I certainly would be, but we need your expertise too.
<nckx>I've never even seen or used one.
<civodul>same here
<narispo>nckx: Yes, I'm here for this.
<civodul>narispo: so my advice would be to not hesitate and ping people when you have questions about Guix and going further
<narispo>I run POWER9 as my main workstation since a year if not more already, it's very well supported across the whole echo system
<civodul>we could push your work in a branch or something
<narispo>eco system *
<narispo>I am not convinced that my work is of high enough quality though, you can have a look here: https://gitlab.com/lle-bout/guix
<nckx>narispo: Forgive my noobey when it comes to terms like OpenStack: does that mean they could deploy Guix System to a bare-metal machine once it's ready? Or are these more virtual?
<nckx>* noobery, I can't type today.
<narispo>OpenStack is virtual but it's powerful still.
<nckx>narispo: Your work *exists*, that's all that matters.
<narispo>On request, I believe they could do baremetal
<nckx>OK.
<narispo>Basically IBM sponsors OSUOSL with big machines
<nckx>That would be preferable from a trust standpoint, even if the emulation's perfect.
<narispo>IBM is willing to sponsor the whole Free Software eco system, it's a win move for them.
<narispo>The more POWER9 is supported, the more they can sell their CPUs
<narispo>Considering their firmware stack is Free Software, that's fine by me!
<kmicu>Those are mainly B2B solutions.
<narispo>POWER9? Well yes. https://raptorcs.com progressively enters the consumer market.
<nckx>narispo: I'm willing to sit down & read & fill in that form this evening if we can actually start using that machine (in whatever rickety wat) right away. You're saying that's the case?
<narispo>nckx: the approval is manual but it's quite quick, also #osuosl is a channel here!
<nckx>narispo: Right, I meant that I don't want a generously donated machine to sit idle while we (well, someone knowledgeable) hammers Guix PPC64 support (back) into shape. Then I'd rather wait.
<nckx>If your work is rudimentary but runs, that would be great.
*kmicu goes back deploying Guix System on iMX6 aka Poor2Poor solution (◍•ᴗ•◍)
<narispo>nckx: It runs, it can't compile "GNU Hello" because of the floating point problem that's to be fixed but it runs
<narispo>I have Gitlab CI set up on that repo, if I add you as a maintainer, you could already push and test.
<nckx>I've never personally ported Guix to anything.
<narispo>OSUOSL provides machines for dev/CI which would include hacking ppc support, I have an idle machine where I notified them it would be idle, but they told me that as soon as the fact that it's idle isnt fine they'll notify me.
<nckx>OK, I'll request one for the Guix project and deal with any questions they might have.
<nckx>‘How many estimated users do you have in your community?’ 🙂 civodul?
<narispo>"We do not track our users so we do not know." ;)
<civodul>indeed :-)
<civodul>it's on the order of several thousands i guess?
<civodul>we could check the ci.guix.gnu.org nginx logs
<nckx>narispo: :-D I'd already typed that, but would like to add an estimate anyway.
<wingo>that's probably the best way
<wingo>count monthly distinct ip addresses accessing the substitutes server
<jonsger1>narispo: there was some stuff going on at the powerpc64le see my mail at https://lists.gnu.org/archive/html/guix-devel/2019-11/msg00336.html and the response
<nckx>civodul: Cool, that was my guess too.
<nckx>I have no idea why. Might be laughably off.
<civodul>wingo: what tools are there to analyze logs? i know "goaccess" but it doesn't seem to be flexible
<narispo>jonsger1: Yup! Well I am the response!
<wingo>i don't know tbh :P i had a guile parser at some point but maybe it's slow
<jonsger1>narispo: ah :)
<civodul>wingo: ok :-)
<nckx>civodul: grep | cut | sort -u 😛
<narispo>Just making sure, #f and #t in Scheme is false and true booleans?
<nckx>With wc -l providing the needed statistical analysis.
<nckx>narispo: Yes.
<narispo>Thanks.
<civodul>nckx: but you need that by month, by week, etc.
<anadon>nckx Looks like something didn't get restored correctly with GPG keys from the server recovery. The installation script is failing: https://paste.debian.net/1118255/
<nckx>civodul: I don't follow. Isn't ‘last month’ (i.e. just grep everything after date T) enough for our purposes?
<nckx>anadon: Eh… I have a terrible memory for names & nicks. Why the ping?
<civodul>nckx: oh you're right, that should work
<anadon>I was on the other day trying to get some help with packaging my code.
<anadon>Yeah. I'm going through my GPG setup right now. There may be _other_ issues, but that should work regardless.
<wingo>civodul: found it. it was pretty bare-bones :)
<wingo>gitlab.com/wingo/guile-clf
<wingo>anyway, probably you want something different
<nckx>anadon: Ah, welcome back 🙂 So does it work after importing? Not doing that for you is by design; scripts messing with your keyring is just an evil concept.
<wingo>there is http://www.hping.org/visitors/ also
<bandali>hey folks, anyone else having the substitute die on them constantly?
<bandali>it's gotten *really* annoying :(
<bandali>i can't get through a pull or whatever without the substitute dying on me a couple of times
<bandali>pinging civodul and nckx for good measure
<nckx>bandali: Yes! Parra had some very experiences earlier today.
<civodul>thanks wingo
<civodul>bandali: could you paste what you see?
<bandali>nckx, ah so it's not just me! i was seeing it last night too
<anadon>nckx Seems like it is still a no-go.
<bandali>i've also tried from two different networks, one incredibly stable, same thing
<nckx>While updating the list of substitutes.
<nckx>Not downloading the payload.
<bandali>civodul, i pasted an error or two last night, i think, when you were around
<Parra>so what's the deal?
<bandali>but sure, one sec
<civodul>so ci.guix.gnu.org was lacking disk space, but that's solved now
<Parra>I mean, who can check that ci server that is failing?
<civodul>so i don't know what's going on
<civodul>well i haven't experienced it myself :-)
<Parra>I'm trying random things at this moment XD
<nckx>Parra: I was just heading over to the CI logs, I'll see if there's anything fishy in 'em.
<Parra>thanks
<nckx>Not right away, though. Later today.
<Parra>:)
<efraim>What's blocking staging? Just the qt stuff?
<bandali>also, fwiw, the installer fails pretty badly when connection is unstable, and "retrying" doesn't work either; you have to reboot and start from scratch
<civodul>can someone (re)paste the actual error though?
<bandali>guix substitute: error: TLS error in procedure 'read_from_session_record_port': The TLS connection was non-properly terminated.
<bandali>guix system: error: substituter `substitute' died unexpectedly
<bandali>i saw those two errors both during a guix system init, and now during a guix system reconfigure
<bandali>i'd see similar ones during guix pull as well
<bandali>civodul, nckx, ^
<bandali>not sure how long this has been happening for, since i just started getting back into guix two days ago after a few months
<bandali>but when i last used guix earlier this year, i never encountered this
<Parra>I'm getting exactly the same error
<Parra>bandali: me was the last week
<narispo>do you think it's practical to run GNU Guix as a main system right now?
<bandali>Parra, ha
<narispo>Stability-wise
<Parra>last week worked, now not any more
<Parra>narispo: I'm using it to build and package my software, I use VMs usually
<bandali>narispo, this broken connection nonsense aside, yeah i think it's rather stable. not as stable as debian or more mature distros yet tho
<bandali>still a bit rough around the edges
<Parra>debian is very stable, but they have a lot of history
<nckx>narispo: I've run it for many years, most ‘core’ (ugh) contributors have. But as bandali said, it's still a tinkerer's system. You have to enjoy that.
<Parra>nckx: how can I disable substitutes for one command?
<nckx>narispo: Eventually something will break. 😛
<nckx>Parra: --no-substitutes
<nckx>Cherish this moment of logic.
<Parra>in the same command or daemon?
<bandali>i personally really can't afford to use --no-substitutes on my x200 though... i hope this ci tls issue is fixed soon
<nckx>Parra: The ‘guix …’ command.
*nckx → AFK.
<Parra>thanks
<ScaredySquirrel>why is the ssh daemon just down?
<Parra>narispo: although I'm not using guix as a main system I think it's an awesome project, and it helps to improve the way I develop
<ScaredySquirrel>I put (service openssh-service-type (openssh-configuration (x11-forwarding? #t))) in my config.scm and the ssh daemon won't come up
<ScaredySquirrel>it's in %desktop-services
<ScaredySquirrel>not sure if I have the desktop services enable
***ng0_ is now known as ng0
<g_bor>hello guix!
<civodul>bandali: above that message, do you have a URL?
<anadon>nckx: Did a cursory rebuilding of GPG stuff, install script is still failing on "missing" public key.
<bandali>civodul, it's just "substitute: updating substitutes from 'https://ci.guix.gnu.org'..." and a percentage for me
<bandali>civodul, so Parra says this apparently started happening for them last week or so
<g_bor>huh... matrix seems very broken now...
<nckx>anadon: Forgive me a possibly stupid question, but you did run gpg as the same user the script runs as, right?
<Parra>bandali: let me find the exact build.that was working
<anadon>nckx By all means, right now I'm demoted from programmer to dumb user.
<bandali>Parra, +1
<anadon>Yes? I'm using `sudo`.
<Parra>2 months ago
<anadon>On the script that is, not with `gpg`.
<Parra>haha sorry, I have a very distorted notion of time
<g_bor>nckx: I believe this matrix stuff is not on your site, several peoples' messages are missing.
<Parra>but that one is working, right now on my locally
<bandali>Parra, haha. civodul, 2 months it seems
<nckx>anadon: But won't that use root's keyring? (I'm not sure.)
<anadon>I'll check
<Parra>I have that docker image working right now, and it doesn't fail with that strange error
<Parra>that's what makes me feel like something is broken in guix rather than the ci
<anadon>nckx That was it. I thought is was all using my keys, but `sudo` switched it to root's. Curious.
<nckx>g_bor: Oh, good, since I can't imagine how I could be responsible. 0. Accidentally discover Matrix Stealth Mode 1. Sell it to IRC snobs 2. Profit???
<ScaredySquirrel>I put (service openssh-service-type (openssh-configuration (x11-forwarding? #t))) in my config.scm and the ssh daemon won't come up
<Parra>bandali: but anyway I think that error appeared recently
<bandali>ha
<civodul>bandali: alright i have it now
<nckx>ScaredySquirrel: This answer sucks but: this happens to some people, and we haven't yet found out why.
<bandali>civodul, oh! what seems to be the issue?
<nckx>anadon: Using ‘sudo -E’ probably would have changed that.
<bandali>(if you figured it out, that is)
<anadon>This is why sysads still make me look dumb. I can do math and make things, but FSM help me should I actually need to do something competent.
<nckx>😃
<civodul>hmm nginx says "client timed out (110: Connection timed out) while reading client request headers"
<bandali>hmm
<civodul>408 Request Timeout, but the client doesn't see that response
<civodul>no problem on http://; same problem with an older guix on https://
<civodul>we didn't upgrade nginx or anything recently
<bandali>strange... could it be a bug in a guix dep?
<ScaredyS1uirrel>ok um try when it fails try a locked file on the client machine
<bandali>like gnutls or something. but idk, since you said it also happens with older guix ?
<civodul>bandali: that older guix didn't have that problem back then
<civodul>so it's probably server-side
<ScaredyS1uirrel>scp fails when the target file already exists and the client machine user has no access
<bandali>civodul, hmm
<bandali>ScaredyS1uirrel, are you talking to me?
<ScaredyS1uirrel>yes whomever said they have no idea why scp fails for the community
<ScaredyS1uirrel>scp failed for me because of no rights to access an already existing file on the client machine for the client user
<bandali>ah then not me. we're talking about failures when downloading from ci.guix
<narispo>civodul: I am curious, is there any limitation of the GNU Guix concept that you've met anywhere? especially w.r.t to services or unified configuration
<bandali>civodul, could it possibly be a dns-related issue? e.g. the fsf sysadmins changing something for guix.gnu.org or *.gnu.org ?
<Franciman>I got problems with cargo and SSL again
<Franciman>I am starting to feel repulsion for rust
<Franciman>I don't want to have rust code on here anymore
<civodul>bandali: it's not a DNS issue, the host name resolves correctly
<civodul>bandali: are you familiar with HTTP pipelining and related settings & issues?
<bandali>civodul, ha, i haven't dug much into that; but i wouldn't mind trying to have a look if i could help
<bandali>do you know what exactly we are looking for?
<zimoun>bandali: off-topic, if you are the bandali of the EmacsConf, thank you! Hope to read soon about the audio/video issue you encountered and how you fixed some.
<bandali>zimoun, i am indeed :) and thaanks! doing a tech write up of the conference is still on my todo list
<civodul>bandali: 'guix substitutes' pipelines HTTP requests for /xyz.narinfo, up to 1000 requests
<civodul>i wonder if we're hitting a limit somewhere
<civodul>weird thing is we're not hitting it on http
<civodul>and we were not hitting it two days ago AFAIK
<Parra>I tried --no-substitutes but it exceeds the timeout of travis
<Parra>so..
<Parra>I can try it in my 20 core machine but I fear if I break everything
<Parra>XD
<Parra>if anybody wants to try: docker pull metacall/guix && docker run --priviledged -it guix package -i nss-certs
<Parra>for example
<civodul>Parra: when you get that error you can try again and it'll complete
<Parra>really?
<nckx>Parra: And you mocked my for loop above!
<zimoun>bandali: yes, please. :-) Because it could be an interesting idea to stream some stuff during the Guix Days... or not. :-)
<bandali>zimoun, right :)
<nckx>civodul: Parra said it failed at the same percentage every time, though, which is fishy.
<bandali>civodul, hmm. i'll look around
<bandali>nckx, civodul, Parra, i personally didn't hit it on the exact same percentage, but they're close: 72.8%, 70.8%, etc
<Parra>mine fails at 77.8
<bandali>civodul, btw, can you point me to the nginx configs for the ci?
<Parra>maybd it's because of docker
<Parra>I always run a fresh install
<nckx>bandali: hydra/nginx/berlin.scm in the maintenance repo.
<zimoun>does someone have experience with Ansible? it is about Bug#22196 http://issues.guix.gnu.org/issue/22196 I want not close a bug because of only my little experience
<nckx>bandali: https://git.savannah.gnu.org/git/guix/maintenance.git
<Parra>I'm going to avoid this, it's wasting my time
<Parra>I have other problems to solve
<bandali>nckx, ha, thanks
<anadon>Changing the build mode in a package from autotools to 'cmake' isn't working even with `#:use-module (guix build-system cmake)`. What could I be missing? https://paste.debian.net/1118267/
<nckx>anadon: cmake → cmake-build-system
<nckx>in your (build-system …) field.
<nckx>The module name is correct.
<anadon>Now for the `mit` license...
<anadon>The cmake bit wasn;t clear in https://guix.gnu.org/manual/en/html_node/Build-Systems.html
<nckx>anadon: ‘MIT’ is ambiguous so we don't use it as an identifier, it's either ‘x11’ (unlikely) or ‘expat’.
<anadon>ok
<nckx>anadon: I've never read that page & my eyes go straight to ‘oh I have to fill in a build system’ → ‘Scheme Variable: cmake-build-system’.
<bandali>civodul, btw, what does ci.guix use? is it still aws behind the scenes? if so, could it be that they've changed something?
<nckx>Not saying you're wrong, but could you explain how you read it, how you got ‘cmake’, & how it could be improved?
<nckx>bandali: No, just an nginx caching proxy.
<bandali>nckx, hmm
<nckx>The CDN experiment ended quite some time ago, should have been long before this started.
<anadon>nckx I searched for `cmake`, glanced that that title section had the keyword, then read the body. I'm not used to the titles having information not repeated in the body of a text.
<nckx>Hmm.
<nckx>Even when starting with ‘This variable is’? But OK, point taken. I'm not as convinced as I'd like to be though. So did your eyes see ‘It automatically adds the <cmake> package to the set of inputs’ with cmake in code mark-up and conclude it was what you needed?
<anadon>That is correct. Also, again, dumb user. I'm not claiming finesse as this area is very new to me.
<nckx>This is also the convention [that should be] used in the entire manual, so we can't really afford to mention it again explicitly in every paragraph like it. Would be messy.
<nckx>anadon: Not dumb! Documentation is hard to write for an audience of everyone. It's always a trade-off. Thanks for the feedback, even though I think the status quo is best in this case.
<anadon>Understood. Others may have an easier time than myself. But seeing it as a 'scheme variable' itself doesn't mean anything concrete to me either and so couldn't piece where it might belong in code without direction.
<civodul>another data point: https://bayfront.guix.gnu.org doesn't have that problem
<nckx>anadon: Did you actually read all of the 5 opening paragraphs? If so, maybe adding a ‘…takes one of the scheme variables below…’ somewhere would help. But to be honest, my experience is that people would *not* see it.
<Parra>it worked now: Build #62 passed 12 mins and 45 secs
<nckx>So if you did I thank you for it.
<Parra>so random
<Parra>xD
<nckx>Parra: woot!
<Parra>but without -i
<Parra>I fear of pulling in the 20 core machine... I won't pull until I have metacall finished
<Parra>then I will review in detail this problem
<bandali>civodul, what's the difference between bayfront and berlin?
<anadon>nckx Correct, I skipped over the first 5 paragraphs.
<bandali>like, hardware/purpose-wise, i guess. their nginx configs i could look at, of course
<zig>20 core machine? does it exists?
<nckx>anadon: Heh, no shame in that, but then I don't see an obvious quick fix.
<anadon>I think intel made a 20 core CPU, and certainly 20 core boards.
<anadon>nckx IRC!
<anadon>My intent is that I muddle through a base case that makes me think, then go through documentation more completely when I have context.
***jje is now known as Guest91811
***jje` is now known as jje
<bandali>civodul, nckx, for one thing, i don't see "keepalive_requests 600;" for bayfront, but it is present for berlin
<bandali>have to go afk, will check back later tonight
<civodul>bandali: it's in bayfront-location.conf
<civodul>bayfront-locations.conf
<bandali>ah okay
<bandali>will have a look a little later
<Parra>zig: it's from a friend, it's a server but he uses it as its own personal computer, I use a qemu vm for building metacall fast
<Parra>I think it's 20 cores with 2 threads per core
<Parra>but not sure, I don't have access to the host
<Parra>only the vm
<rekado>zimoun: my colleague Madalin is pretty familiar with streaming video. He isn’t on IRC often and I don’t know if he’s going to be at the Guix Days. But maybe someone can contact him to ask.
<rekado>zimoun: BTW I’m working on 38184; sorry for the delay!
<rekado>the patches don’t apply cleanly for two reasons: 1) I updated some R packages in the meantime and 2) the patches I can download from mumi are missing their headers, so git doesn’t accept them :-/
<rekado>Not sure if that’s a problem with mumi or with debbugs.
*rekado is a bit sad that nobody has picked up the work on mumi
*rekado understands that it’s not a very interesting project
<rekado>I’m thinking that we could add authentication to mumi via SSL client certs.
<rekado>you know, for tasks like closing and merging issues.
<rekado>or even for submission of new issues via the web interface (which probably shouldn’t be enabled for unauthenticated visitors on the internet).
<nckx>rekado: What's Mumi's actual goal?
<rekado>it’s supposed to let people forget that Debbugs is kinda weird.
<nckx>I've (sorry) always just seen it as a pretty facelift for the debbugs Web UI to fool new users into thinking we're hip kids.
<rekado>it tries to accomplish this by providing what is supposed to become a ‘friendlier’ web interface to Debbugs.
<rekado>yeah, that’s one way to put it. I’d like the illusion to become better, though.
<nckx>Does it currently do anything that debbugs doesn't? The keyword: syntax, I guess.
<rekado>that’s one thing. It also has a more convenient search … which is sabotaged by Debbugs’s weirdness for the time being.
<nckx>Web submission of bugs would be nice I guess, and I'm always happy to see client certs get the love they deserve, but then we're back at losing the drive-by GitHub crowd.
<nckx>And I don't know if regular contributors use Mumi.
<nckx>I don't. That's not your fault; it's browser's.
<zig>I use mumi
<zig>sometime.
<zig>but i am not a regular contributor.
<nckx>anadon: I was about to close your past and noticed (inputs `(("C++" ,g++, clang++))). That's… not right 🙂 I assume you've fixed it by now, but a) it should be either ,g++ or ,clang++ and b) the placement of the second , implies you might not know what it does: it unquotes the following symbol, it's not an array separator. ‘,g++ ,clang++’ is sugar for ‘(unquote g++) (unquote clang++)’.
<anadon>That's new to me. What I really want to do is to be able to specify a C++ standard, then just have a package fulfill that standard.
<anadon>Here's where I'm currently at: https://paste.debian.net/1118276/ I was showing my grandma a few things so I didn't get time to try much more.
<g_bor>rekado: i don't think authenticating at mumi would bring a lot, as these actions can be done from debbugs without auth. Am I missing something?
<KE0VVT>They have a "mit" license? I thought Guix used Expat and X11 and not MIT.
<g_bor>I use mumi as much as I can. I also tend to link there when referring to an issue.
<civodul>i have to go afk, but i'd appreciate if people could brainstorm regarding this narinfo/tls issue on berlin :-)
<civodul>brainstorm on what the problem might be, or how you'd go about debugging it
<zimoun>rekado: thank you for 38184. I was not worry. :-) Do not be sorry.
<zimoun>nckx: about Mumi, the goal is so well described by the long thread on emacs-devel. And my preferred answer is https://lists.gnu.org/archive/html/emacs-devel/2019-11/msg00708.html Emacs maintainer said: "I don't know how to close a bug" :-)
<zimoun>rekado: about video and Guix Days, let drop an email to collect ideas to guix-devel. For example, first, do we want? :-)
<zimoun>I will remember your colleague. :-)
<nckx>KE0VVT: We do. That's a WIP package.
<nckx>anadon: Sure, I use ‘abstract’ input labels like that sometimes, although it's not common. Using ("c++" ,g++) or ("c++" ,clang++) will work. See it as defining the default, not as listing the possibilities. You could add supported ones as a comment.
<nckx>anadon: Nixer, perchance? That pattern's more common there.
***modula is now known as defaultxr
<anadon>Nixer?
<nckx>I guess not, never mind 🙂 (Nix user.)
***grubles is now known as Guest56640
<nckx>zimoun: Thanks. I don't read emacs-devel.
<zimoun>rekado: about mumi, whislist: trim when the attachment is very looong. See http://issues.guix.gnu.org/issue/24687
<zimoun>nckx: the thread is really long. Should be read because it provides some interresting drawbacks and newcomer blocker
<zimoun>some days ago, we talked here about sourcehut.org
<zimoun>sourcehut.org should be interresting to replace debbugs. Do not know
<anadon>nckx Now I'm stuck on guix package: error: cannot install non-package object: #<unspecified> but it looks highly similar to the example hello.scm.
<anadon>Google is of no help here.
<rekado>anadon: what command gets you this error?
<rekado>the problem is likely that the file doesn’t evaluate to a package object, but to #<unspecified>.
<rekado>so end it with ‘magic-enum’, which evaluates to a package object.
<anadon>rekado OK. For context, this is the current state: https://paste.debian.net/1118276/
<anadon>With your suggested change, this output: https://paste.debian.net/1118287/ . Heading out for a walk with family.
<nckx>anadon: Inputs need to be Guix package variables. I didn't actually verify that g++ and clang++ exist; seems like they don't. g++ is probably provided by ‘gcc; try that instead.
<Parra>I'm having problems with runpath and the runpath step, if guix cant find a dependency in a specific runpath, that runpath is the one in the target or the one in the dependency?
<Parra>I don't know why but it's using as RUNPATH ..../lib/lib
<Parra>it's so random
<Parra>I'm using cmake to build, and I don't know how to debug this
<Parra>when building on my PC with cmake this does not happen
<Parra>any hints?
<nckx>Parra: It means the rpath of the package that is being built, if that's what you mean. Could you paste the package?
<Parra>do you mean the .scm?
<nckx>Sure.
<Parra> https://github.com/metacall/distributable/blob/ac5de4a36417ef033d9d3b9aa5016fa07d57877e/source/metacall.scm#L1
<Parra>I build it with this: https://github.com/metacall/distributable/blob/ac5de4a36417ef033d9d3b9aa5016fa07d57877e/scripts/build.sh#L26
<nckx>Parra: Ah, you're the Metacall person. Cloning…
<Parra>XD
<Parra>it takes as a base /lib and then adds /lib to it, so it ends with /lib/lib
<nckx>Building…
<g_bor>hello guix!
<Parra>I'm trying to fix it from cmake side
<Parra>but not sure
<g_bor>I've just seen civodul's message about the tls thing.
<nckx>Parra: Where do you see /lib/lib in the output of guix build?
<Parra>what are you building?
<g_bor>Any idea what is going on?
<nckx>o/ g_bor
<Parra>the package metacall.scm?
<nckx>Parra: I did: ~/distributable $ guix build node-addon-api metacall -L source
<Parra>ok, so
<Parra>it should fail in the runpath-check step
<Parra>did it fail?
<g_bor>my connection seems a bit bumpy...
<Parra>you should see in the runpaths, one that says: metacall-0.1.17.../lib/lib
<nckx>Parra: I get this http://paste.debian.net/plain/1118292 . OK, will search.
<Parra>wait
<Parra>error: depends on 'libmetacall.so', which cannot be found in RUNPATH ("/gnu/store/rd6yyxpyz44ijvbyz5dsr2db3kncji1w-metacall-0.1.12/lib/node_modules/metacall/lib"
<Parra>that's an old commit it seems
<nckx>Parra: Hm, I checked out the commit you linked to above and that builds metacall-0.1.12, not .17.
<Parra>I have updated thst
<Parra>sorry
<nckx>Ah.
<Parra>one sec and I commit again
<Parra>but anyway it's wrong
<Parra> /lib/node_modules/metacall/lib
<Parra>it should not have the first /lib
<nckx>My first guess is that the build system automatically sets runpaths for /lib directories, but does not recognise your non-standard /node_modules/metacall/lib.
<nckx>However, I know 0% of Node. I build Node packages on Debian, then copy them to my Guix server…
<Parra>it's a library
<Parra>it's a .so
<Parra>it happens in all libs that depend from libmetacall.so
<Parra>I don't know why
<nckx>I'll take a look at the new commit when you've pushed.
<nckx>There was no ./source on master when I cloned.
<Parra>I'm turning on the pc
<Parra>master isn't the correct branch
<Parra>it is feature/build-guix
<Parra>sorry
<nckx>No problem.
<nckx>I copied the commit from the github URL 🙂
<Parra>done
<Parra>I updated it to the latest
<Parra>I'm gonna merge with master now
<nckx>I'm building the branch.
*nckx → ☕
<Parra>merged into master
<Parra>now I enabled two ports, python and node, both should fail by the same reason
<Parra>_py_port.so: error: depends on libmetacall.so ... runpath ... /lib/lib
<Parra>both fail, the python and node port with the same error
<Parra>maybe it's something wrong with my cmake but I have no idea how to debug
<Parra>I changed the install path and this affected the rpath, before it was that one with node_modules
<mbakke>Parra: you can try to pass "-DCMAKE_INSTALL_LIBDIR" and/or "-DCMAKE_INSTALL_RPATH" in #:configure-flags.
<Parra>but I can't understand why it adds that lib prefix
<nckx>Parra: I can't help you debug your CMake files, I'm afraid. It does sound like there's a /lib too many somewhere and it's not in your Guix package. Try doing the equivalent of adding (string-append "LDFLAGS=-Wl,-rpath=" %output "/lib/node_modules/metacall/lib") as a work-around.
<nckx>Ah, mbakke probably just told you the right way to do that.
<Parra>nckx: yeah that cmake is just a nightmare
<Parra>mbakke: how should I configure that?
<nckx>Parra: Add it under -DCMAKE_CXX_FLAGS=-fpermissive in metacall.
<Parra>but set to ON? or setting a custom path?
<Parra>which path then?
<nckx>Something like (string-append ""-DCMAKE_INSTALL_RPATH=" %output "/node_modules/metacall/lib")
<nckx>If that is the correct path, and ignore my double "".
<Parra>correct path should be /lib alone
<Parra>in debian I just do ldconfig and that's it XD
<Parra>it's dirty but it works
<Parra>I'm going to try and I'll tell you
<Parra>thanks for the help
<mbakke>Parra: good luck! :)
<nckx>Hm, that didn't change the runpath.
<Parra>thanks guys
<Parra>well at least I know something
<Parra>when I did this change:
<Parra> https://github.com/metacall/core/commit/494dba5aeb001141ca3aafc70428260b2368be3c
<Parra>the runpath changed from /lib/node_modules/metacall/lib to /lib/lib
<mbakke>17 hours ago!
<nckx>‘Definitely looks related’.
<Parra>I can force to remove the ${INTALL_BIN} and ${INSTALL_SHARED}
<Parra>they are /lib by default
<Parra>so removing them will place the runtime in /lib
<Parra>it may work but it's a nasty workaround, maybe the libs end up installed in /usr/local/ instead of /usr/local/lib
<Parra>XD
<nckx>Parra: ‘Fixed’ by adding a phase. Will paste.
<Parra>oooooooooooo
<Parra>thanks dude
<Parra>feel free to PR if you want
<Parra>in master
<nckx>Parra: http://paste.debian.net/1118298/
<Parra>haha you went straight
<nckx>And remove any -DCMAKE_INSTALL_RPATH=/LIBDIR= you may have set.
<Parra>I am going to add it now, thanks so much
<nckx>Parra: Sorry, was easier to just pastebin than PR.
<nckx>I'd have to log into GitHub, fork your repo, clone that (or change my origin), commit, push, go back to my browser, ergh.
<Parra>ufff
<Parra>dont worry then
<nckx>Life so hard why.
<Parra>I just like to give people their recognition
<Parra>if you don't care it's ok, but I would like to add you on contributors file
<nckx>That would be cool, thanks.
<Parra>I don't know how irc works but you can send me your name + email in private message if it's possible
<nckx>(We both know that now I'll feel morally obligated to fix more bugs, so good move 😉 )
<Parra>hahahahaha
<Parra>I try not to be annoying
<nckx>Not annoying at all.
<ScaredyS1uirrel>what is wrong with this config.scm? http://dpaste.com/1TEGX1Y
<nckx>Also, you'll have to check whether my fix actually makes sense and isn't just hiding a real bug in your CMake files. But at least you can work from a working package now.
<Parra>yes it may be hiding a real bug
<Parra>but I don't care at this point
<Parra>XD
<nckx>ScaredyS1uirrel: As much as I like riddles, ‘find the bug in this long file’ isn't much fun. Do you have an error message too?
<Parra>I just will add a comment and that's it
<ScaredyS1uirrel>um it just says invalid field seperator
<ScaredyS1uirrel>and unknown symbol openbox
<nckx>I'd bet hard cash it doesn't say separator. Could you paste it?
<nckx>ScaredyS1uirrel: Add ‘openbox’ to (use-package-modules …). It's not in wm if you thought that.
<ScaredyS1uirrel>oh
<ScaredyS1uirrel>that's conveinient
<nckx>ScaredyS1uirrel: This is why I use (packages (map specification->package (list "package" "another" "whee" "fun"))) instead, it auto-imports things.
<nckx>(packages (append (map specification->package (list "package" "another" "whee" "fun")) %base-packages)) in your case.
<nckx>ScaredyS1uirrel: I understand your frustration, but the sarcasm is a bit off since I'm *pretty* sure Guix literally told you: error: openbox: unbound variable / hint: Did you forget `(use-modules (gnu packages openbox))'?
<ScaredyS1uirrel>ok
<nckx>It does here.
<nckx>🙂
<Parra>nckx related to that workaround
<ScaredyS1uirrel>well I put (use-modules (gnu packages)) in there
<nckx>ScaredyS1uirrel: Modules imports aren't ‘recursive’ like that.
<Parra>wouldn't it be better to use $ORIGIN/lib instead of /lib ?
<Parra>so it can be portable
<ScaredyS1uirrel>and the weird thing is I also put (map specification->package+output (list "openbox" "nss-certs")) as well and it gives a huge stacktrace
<Parra>(which is my main idea)
<ScaredyS1uirrel>I think the real error would be unknown package but it doesn't say that
<nckx>Parra: Instead of /gnu/store/…/lib, you mean? Because that is what that string-append produces.
<Parra>nope, literally $ORIGIN
<Parra>it's a trick to make portable libs
<Parra>when you do guix pack -RR it does that
<Parra>not sure if when you do guix pack it replaces all rpaths with the portable version
<nckx>Parra: I know, but the way you word it (‘wouldn't it be better to use $ORIGIN/lib instead of /lib’) would result in /gnu/store/…/$ORIGIN/lib, which is not what you want. Feel me?
<Parra>mmmmmm
<Parra>let me investigate
<Parra>after this what I want to do is a simple automated test, loading metacall from nodejs and testing if it works with some calls to python
<Parra>so we will see then if it fails or not
<nckx>Parra: Because you're still appending output to the string.
<Parra>now I will be able to test, if it works I'm going to promote guix to all my dev friends XD
<nckx>I'd stick with my version, which is how Guix usually does things. Guix packages aren't really portable: hard-coding /gnu/store is kind of their point.
<mbakke>Parra: IIRC the guix ld wrapper replaces $ORIGIN references with the absolute file name, not sure why.
<Parra>well, I'm already doing that XD
<Parra>$origin at the end must be replaced when loaded
<Parra>in the loader it should look like /base/path/../lib
<nckx>It makes the linking more explicit and reduces the chance (if any) of unintended impurities at run time.
<Parra>or something like that
<Parra>aren't portable?
<Parra>but I'm using this due to portability
<Parra>XD
<Parra>it's the most portable thing I've found
<Parra>I'm going to investigate anyway
<Parra>we will see
<nckx>Parra: Well, define portable. You can't plonk /gnu/store/xxx-foo-1.0 into /var/mystuff and then run it. That's not how Guix defines portability, but it seems to be the intended use of $ORIGIN.
<Parra>the idea is that with guix I can generate self contained tarballs that can run on any system no matter what Unix is it
<nckx>Yes. That will be the case with or without $ORIGIN though.
<Parra>and as I'm using docker it will be so easy to build with multiple architectures, avoiding crosscompile shit
<Parra>$origin is the extra
<Parra>it allows me to provide portable packages for other package managers like npm
<nckx>If I turn out to be wrong 1) probably a bug that needs to be fixed in Guix, not worked around here 2) it can be dealt with when it happens.
<Parra>which define the dependencies in relative paths
<Parra>pack -RR is just designed for that
<Parra>I don't think it's a bug
<Parra>I think it's one of the best features
<nckx>Me being wrong?
<nckx>True.
<Parra>XD
<Parra>well it worked dude
<Parra>you are in contributors right now
<Parra>it's a patch I did in docker many times but I'm a noob here
<nckx>Parra: pack -RR doesn't rely on $ORIGIN, though, it works even when using /gnu/store, and all other packages in Guix use /gnu/store. So using $ORIGIN in your package alone ‘for portability’ would be ‘wrong’: we'd rather fix ‘pack -RR’ to replace it instead, so *all* packages magically work. However: it might already do this and the point is moot; I didn't check.
<nckx>Parra: Yay royalties.
<Parra>mmmm
<Parra>so do you mean if I take the resulting tarball, and I paste it in a random folder, then executing something or linking something against it will fail?
<nckx>ScaredyS1uirrel: I think you have another error that's producing that backtrace. (map specification->package+output (list "openbox" "nss-certs")) is perfectly valid and works fine in a REPL.
<nckx>Parra: The resulting tarball of what? ‘guix pack -RR’: no, it should work fine, but your package using $ORIGIN won't change that. Anything else: probably.
<nckx>s/probably/probably won't work/
<Parra>ahhhhh
<Parra>I got you now, I understand what you mean
<Parra>but I only care about guix pack tarball right now
<nckx>Then all should be fine, and if it's not we'll address any concrete problems when they occur 🙂
<Parra>thabk you so much, you really unblocked me
<Parra>now I can try if it really works
<Parra>I want to try this in an alpine, without glibc installed in the system, and see what happens
<Parra> https://github.com/metacall/distributable/blob/master/CONTRIBUTORS
<nckx>It *should* use the bundled Guix glibc (and everything else, too) but I've never tried. Good luck!
<nckx>😃
<nckx>Thanks for the honour.
<Parra>thanks you so much dude
<nckx>Parra: Thank you for developing a new project with Guix-first support.
<Parra>uff it has been the only option that really works
<Parra>none of the others I've tried is comparable
<Parra>and I think it can be a good example of the power of guix
<nckx>Absolutely.
<Parra>because metacall is a Polyglot which includes very complex dependencies like complete runtimes (python, ruby, c#..)
<Parra>if Guix can package it, then it can package anything
*nckx saw the word ‘Node’ in your source and gulped. It's a packaging nightmare.
<Parra>not just that dude
<Parra>I embedded NodeJS in C/C++
<nckx>That pun was both horrible and unintentional but I apologise anyway.
<Parra>which is impossible in their current design
<Parra>I had to do a lot of hacks and tricks in order to allow that
<Parra>I could package the only dependency I had anyway
<Parra>it was easy, (node-addn-api)
<Parra>it can be moved to the master if you want
<Parra>I don't know how to do that anyway but it can be used as example for node-build-stystem
<Parra> https://github.com/metacall/distributable/blob/fd2439e41f3b1b79589c4c875e874eca1260ae93/source/metacall.scm#L39
<Parra>it works but because of node-addon-api has no extra dependencies
<Parra>it doesn't depend on other packages
<nckx>Parra: That would be wonderful! You can send the patch (using git send-email or as an attachment) to guix-patches at gnu.org when you think it's ready. It doesn't have to be perfect at all; we can help bang it into shape if needed.
<Parra>I will, I'm not familiar with that methodology but there is always a first time
<Parra>this is the real pain of NodeJS, check the whole thread where I explain how to embed NodeJS:
<Parra> https://github.com/nodejs/node/issues/23265#issuecomment-452690239
<civodul>hmm my reproducer for the ci.guix bug no longer reproduces it
*civodul would love to just move on
<nckx>Parra: The ‘methodology’ for first-timers is 1) reading ‘Contributing’ in the manual and 2) sending a patch to the best of their abilities. That's it. Better to have a rough patch we can discuss than something that was never submitted because it wasn't perfect.
<nckx>Parra: That looks interesting but too much text for me right now, sorry.
*nckx is actually working with some node.js today and… hates it less than they expected to. Whuut.
***apteryx_ is now known as apteryx
<Parra>nckx: it's very dense, it's focused for the NodeJS developers and software Architects, and related to the pat h, I will send it when I finish this
<apteryx>does anyone have strong opinions on whether the 'guix.d/...' part in the share/emacs/site-lisp/guix.d/name-version/ Elisp installation directory could be elimited? It simplifies things to have every Elisp libraries installed directly under site-lisp/. Think of it of a flat view of the collection, rather than a nested view.
<g_bor>hello guix!
<apteryx>The guix.d was put in place to help ensure there'd be no collision of Elisp file names, but many packages (that use gnu-build-system instead of emacs-build-system) still install their libraries directly under site-lisp/, such as emacs-magit.
<g_bor>Additional info for the tls thing: 408 is not sent by nginx to the client, and this never changed.
<g_bor[m]> https://trac.nginx.org/nginx/ticket/1005
<apteryx>collisions are typically prevented by adhering to a prefix based naming scheme, where the prefix is named after the package name, which must be unique (magit-git.el).
<apteryx>i.e., the same way collisions are prevented in the Emacs global namespace of variables and procedures symbols binding.
<nckx>apteryx: I have mild views against guix.d for the same reasons as you… but then people who know far more about Emacs than I do conceived of it.
<nckx>apteryx: I'd be surprised if there wasn't an ML post arguing for it. Have you found any?
<apteryx>nckx: I must confess I haven't searched the mailing archive for a record of such a discussion. I'll give it a shot. Thanks for the reminder.
<apteryx>nckx: well, what I find is that Alex Kost, the author of Emacs-Guix, had that very same question as I do: https://lists.gnu.org/archive/html/guix-devel/2016-05/msg00241.html
<g_bor>I believe this tls issue on berlin might well have been another resource exhaustion...
<g_bor>For now it's hard to tell...
<apteryx>nckx: and that refers to this answer, which is about file name clashes: https://lists.gnu.org/archive/html/guix-devel/2015-06/msg00398.html
<nckx>apteryx: Hm, ignoring non-.el files, I agree with you that this: ‘I can imagine that someone preparing a package may be unaware of the existence of some other package, possibly not very popular in his circle.’
<nckx>might not be Guix's problem to work around.
<nckx>Yes, I'm being cautious 🙂 But wouldn't such duplicates already break an assumption made elsewhere in Emacs (and the wider Emacs world) anyway?
<nckx>Has anybody actually successfully used (let alone encountered) two identically-named packages even if they're installed into separate dirs? I doubt it.
<apteryx>there's nothing stopping you from naming your package file 'a-package.el' and writing in it (provides 'some-other-identifier), but yeah, I think this would go against what the Emacs community considers good practice. So in the event this is discovered, a bug could be filed against such package and the .el harmessly renamed in a Guix package phase to fix it.
<nckx>No disagreement here.
<nckx>**** **. Berlin has 72 cores? Is that legal?
<g_bor>nckx: I believe so...
*nckx reassured but sceptical.
<jonsger>nckx: maybe 72 threads, like with 2x18 cores
<janneke>we got a web browsers and ui toolkits to build
<g_bor>nckx: what does something like dmidecode say?
<g_bor>That should give the hw layout...
<nckx>OK, ‘only’ 36 physical.
<g_bor>ok
<nckx>g_bor: Doesn't that require root access? That's borked for me ATM.
<g_bor>ok
<g_bor>36 physical is quite ok... :)
<civodul>nckx, g_bor: i've reconfigured berlin so you should be able to log in now
<nckx>civodul: Thanks!
<civodul>yw!
*nckx had already downloaded the full 13 GiB of nginx logs.
<nckx>Let's do some Big Data science on this bad boy.
<g_bor>civodul: thanks.
*nckx types grep.
<g_bor>I am also in.
<g_bor>I noticed hat on my first login my home directory was non-existent. Is that normal?
<rekado>yes
<rekado>was it created, though?
<g_bor>yes, it was.
<rekado>good
<g_bor>thanks.
<civodul>g_bor: i had to restart "user-homes" to have it created, not sure why
*rekado has to leave again, baby cries
<jonsger>nckx: at least you should use a rust implementation of grep. Plain GNU grep is not hip enough :P
<nckx>jonsger: Isn't ripgrep written in Rust?
<jonsger>nckx: yeah, I think that was the name
<nckx>3096 unique IPs successfully requested /nix-cache-info from berlin during the past month.
<lle-bout>hey
<nckx>Not gonna lie; expected more.
<g_bor>I see from the config that the zabbix frontend should be listening on port 7878, but I see noone there.
<nckx>o/ lle-bout.
<nckx>That number includes only "GNU Guile" user agents, not sneeky bots.
<nckx>‘Several thousand (we don't track our users)’ it is.
<g_bor>However the backend of that is up, listening on 10051...
<lle-bout>nckx: I have that tls problem on a brand new install with 1.0.1 iso
<lle-bout>the installer doesnt finish because of it
<nckx>lle-bout: You had a different nick earlier, right? The TLS issue is being investigated (not by me), the only work-around until it's fixed is to use ‘guix system init --no-substitutes’. If instead you mean the graphical installer, I'm not familiar with it.
<lle-bout>nckx: yes I used the graphical.
<lle-bout>hmm, I wonder if you can save the generated configuration to disk instead to use it with guix system init later
<nckx>I'd expect that to be possible, but 🤷
***daviid is now known as Guest93493
<ScaredyS1uirrel>(use-modules (gnu packages))
<ScaredyS1uirrel>(use-service-modules desktop ssh xorg)
<ScaredyS1uirrel>it says with just that that use-service-modules is unbound
<leoprikler>You should (use-modules (gnu))
<ScaredyS1uirrel>with that instead its the same
<leoprikler>(gnu) instead of (gnu packages)
<ScaredyS1uirrel>yes yes with same result