IRC channel logs


back to list of logs

<Apteryx>I'll now open the bug to track shutdown & affected packages.
<Apteryx>Anyway to get the full list of packages defined in Guix at the Guile REPL?
<amz3>I'd like to know too
<amz3>Apteryx: ^
<Apteryx>amz3: I used rgrep with emacs, this was faster for this time ;)
<Apteryx>(I was interested in filtering packages based on their origin's URI)
<Apteryx>Another question: How can I convince IceCat to display PDFs using its builtin pdf viewer?
<Apteryx>I'm trying this answer ATM:
<Apteryx>pdfjs.disabled is false in "about:config". I guess this is OK. I also flipped the inContent toggle to true, but still no joy.
<Apteryx>Is the in-browser PDF viewer of IceCat working for anyone else?
<lfam>Yeah, I can open a PDF from my hard drive in IceCat
<lfam>Do you have javascript disabled?
<Apteryx>No, javascript is on.
<Apteryx>I think it used to work. Maybe I tried associated *.pdf files with Emacs or even IceCat at some point.
<mekeor>Apteryx: it also depends on the mime-type of the pdf. instead of opening a pdf from the web, you could try to open a local pdf file.
<Apteryx>mekeor: I just tried that, to be sure. It poped the "Open with/Save" dialog box.
<mekeor>mh. :/
<mekeor>it works for me.
<Apteryx>OK. Thanks! I'll try a couple things :)
<mekeor>Apteryx: visit about:preferences#applications and select "preview in icecat" for pdfs
<Apteryx>Settings -> Applications > Portable Document Format was set to Always ask. Eh. Thanks :)
<Apteryx>It's working here as well now.
<mekeor>nice :)
<davexunit>Apteryx, amz3: fold-packages iterates over the list of all known packages
<Apteryx>davexunit: Sweet! Thanks for letting us know.
<Apteryx>Alright. I'm going to try to fix some of the fedorahosted packages from now, at least xmlto which blocks my system reconfigure.
<lfam>Apteryx: I'm about to push a change for xmlto, which can be found on Debian's site
<Apteryx>Oh, great!
<Apteryx>So this one can be considered fixed alreadyÉ
<lfam>About to be fixed already ;)
<Apteryx>hehe, thanks!
<quiliro>thank you Apteryx
<Apteryx>quiliro: what did I do? ;)
<quiliro>(15:17:15) Apteryx: quiliro: No! It uses shepherd, a guile service manager.
<Apteryx>I see! :)
<mekeor>shepherd is written in guile? wow, cool
***Piece_Maker is now known as Acou_Bass
<chatter29>hey guys
<chatter29>allah is doing
<chatter29>sun is not doing allah is doing
<chatter29>to accept islam say that i bear witness that there is no deity worthy of worship except allah and muhammad peace be upon him is his slave and messenger
<rekado_>jmd: yes, it’s on bayfront, and that server seems to have problems :(
<jmd>Isn't that the one that Guix eV paid a huge amount of money for?
***jonsger1 is now known as jonsger
<Isorkin>how to install custom package - perl v 5.10.1?
<snape>Isorkin: you could use the --with-source option of "guix package"
<snape>or, alternatively, write a custom package that inherits the one that is packaged
<Isorkin> guix package -i perl --with-source=perl-5.10.1.tar.gz - not work - ERROR: In procedure mkstemp!: No such file or directory
<Isorkin>guix package -i perl --with-source=perl-5.24.0.tar.gz - normal work
<rekado_>Isorkin: that’s because the recipe for version 5.24 performs work that is not valid in the context of 5.10.
<rekado_>Isorkin: here’s a recipe for an older version of perl:
<Isorkin>how to specify guix package to build perl5.10.1.scm
<mekeor>Isorkin: you can put set the environment variable GUIX_PACKAGE_PATH and then put your package definition in there and then just 'guix package -i perl@5.10.1'
<thomasd>rekado_: I did a small demonstration of Guix to our sysadmin. He would consider setting it up on a system here, but wanted some more info on how it would work out with shared storage on NFS etc.
<thomasd>I've read . Are there any issues with putting a store on NFS that I should be aware of?
<rekado_>thomasd: it’s very slow
<rekado_>at least here
<rekado_>If you can build things locally and export the local file system over NFS that would probably be faster.
<rekado_>to minimise downtime the guix server writes to an external NFS share.
<rekado_>so our Guix server can go down without affecting software that runs on the cluster.
<rekado_>I don’t know of any other issues.
<thomasd>is it only slow when building things, or also when accessing something over nfs
<rekado_>you should make sure that uids are controlled centrally
<thomasd>I believe we would have to put the store on an external NFS share, too.
<rekado_>reading is somewhat slow, but just executing a programme from NFS seems fine.
<rekado_>rebuilding profiles is very slow in our case
<rekado_>i.e. creating a new generation
<rekado_>as profiles grow large this gets much worse
<thomasd>yes... itthat's slow even on my laptop
<rekado_>I would love to be shown that this is a problem with our NFS configuration.
<thomasd>could you define slow? does it take minutes to build a profile or tens of minutes (or hours? :-/ )
<thomasd>as for central control of uid's (which I believe we have): is this to make sure store access rights stay consistent?
<rekado_>that depends on the size of the profile.
<rekado_>it seems to be linear in the number and size of files in the profile.
<rekado_>re central uids: yes. You also want to be sure that all hosts that can mount the share over NFS have read-only access. Only the “guix builder” host should have write access.
<thomasd>rekado_: thanks, it all sounds doable within our setup! (but I'm no sysadmin myself, so there are likely some details I'm overlooking)
<rekado_>thomasd: I have a couple of unpublished scripts and snippets for a cluster deployment
<rekado_>all the nodes where users should be allowed to manage their profiles should redirect guix RPCs to the guix builder host.
<rekado_>to achieve that I listen for RPCs on the network using socat.
<thomasd>ah, that's a new step compared to your blog article. As a first step, I'd aim for the setup you describe (with a dedicated host running guix), but it'd still be great if you're willing to share the scripts. (never heard about socat until now, but I'll figure it out :) )
<rekado_>it’s still a dedicated host running the daemon.
<rekado_>but the daemon listens on a socket, which is exposed to the intranet.
<rekado_>a script “guixr” is installed on /gnu/remote/bin
<rekado_>and all that does is run the actual guix script (also shared on /gnu/remote) with a few variables set to redirect RPCs to a temporary instance of socat that connects to the exposed daemon socket.
<rekado_>annotation 1 shows a systemd service that runs socat on the guix builder host to listen for RPCs over TCP and forward them to /gnu/var/guix/daemon-socket/socket, i.e. the daemon’s socket.
<thomasd>rekado_: thanks! so if I understand correctly, guix runs on every “profile-managing node”, but RPC's are forwarded to the unique “builder node”, which manages the store
<thomasd>do I understand correctly, that users are always using a fixed guix version (namely the git checkout where the guixr script runs pre-inst-env)? i.e. “guixr pull” does not have any effect?
<rekado_>that’s right. It’s possible to make it work with user versions of Guix.
<rekado_>but I haven’t had to do this yet.
<rekado_>those people who want to use their own version don’t normally use our shared installation anyway.
<rekado_>Guix normally checks the user’s ~/.config/guix/latest symlink
<rekado_>but it doesn’t do it when pre-inst-env is used.
<rekado_>it’s possible to do without pre-inst-env, but I didn’t have a need for that yet.
<thomasd>yes, it would probably be fine here, too (we would start with a try-out phase anyway). By “people who want to use their own version”, you mean people can use their own checkout, and connect to the remote daemon on the build host in the same way as your guixr script?
<rekado_>thomasd: they would have to have ~/.config/guix/latest pointing at their version of Guix. No other change would be required on their side. But this is currently not supported as the guixr uses pre-inst-env.
<thomasd>yes, but they could run their own “guixr”, too, I think? Also, do I get it right that your guixr setup even allows people to use “guix environment” from the remote machines?
<efraim>i see hydra is still trying to cross build from armhf/i686 to aarch64, anyone know how to disable that? I'm not familiar with the build-aux/hydra code
<rekado_>thomasd: yes, they could have their own “guixr”. It just has to talk to a socket that is forwarded to port 9999 on the remote server.
<rekado_>thomasd: “guix environment” works fine on all nodes.
<thomasd>rekado_: neat, can't wait to have it running here :)
<ng0>hi, has the urwid failure already been resolved? I just ran into it while initing a new system
<ng0>fixed itself as I used xfce-service now ... I think
<ng0>without this error, a guix system installation, including a guix pull, takes 2 - 3 hours on hardware from around 2010 / 2012 .. including compiling with --fallback etc. Might this be worth to add to the documentation to give an average expectation of how long it could take to set up the system?
<rekado_>ng0: I don’t think we should add this to the manual.
<civodul>Hello Guix!
<sneek>Welcome back civodul, you have 2 messages.
<sneek>civodul, wingo says: did you forget to push guile-web update for 2.0.14? if so would you please rebase and push and regen the guile web site; i think we might have lost 2.0.14 news item from the feed
<sneek>civodul, ng0 says: Is (#18483 Fwd: Dmd tries to initialize my network interface before it become available.) fixed now?
<wingo>sneekpounce :)
<wingo>greetings civodul :)
<wingo>hope you had lovely holidays:)
<civodul>very nice!
<civodul>oops, sorry for the news entry, i've pushed it now
<civodul>it was good to be under the coconut trees far away from keyboard ;-)
<ng0>good :)
<Apteryx>civodul: Welcome back! Good to see you again :)
<Apteryx>ng0: Regarding the urwid problem; yes, it's been fixed by lfam.
<methalo>after run 'guix pull' show error
<methalo>on GuixSD
<Apteryx>Is there a way to define a bazaar commit/tag as origin URI for a package? I'm looking at packaging dvc for emacs, and the options are scarces.
<civodul>Apteryx: no, but you can write it based on guix/git-download.scm
<ng0>if there's no (bazaar-uri) yet you could write it
<Apteryx>OK. Would this introduce a bazaar dependency for Guix in general?
<ng0>only when the module is used
<Apteryx>OK. Neat.
<ng0>so lowlevel i ngeneral no
<ng0>I mean guix has no dependency on cvs, and cvs-download exists :)
<ng0>civodul: is guix pull over onion disfunctinal as it is currently? I'm trying to figure out by replicating locally, why the .onion of bayfront is not picked up. I don't want to confuse bancfc with this input, but it would fall into the scope of the questions askec
<ng0>over the onion of bayfront I mean. it's never picked up, even when it's defined.
<ng0>I guess the onion is just for ssh then
<ng0>efraim: the firefly is this: ?
<catonano>in configuring Artanis I get
<catonano>./configure: line 5018: syntax error near unexpected token `GUILE_LIBS,'
<catonano>./configure: line 5018: ` AC_LIB_LINKFLAGS_FROM_LIBS(GUILE_LIBS, $GUILE_LDFLAGS, )'
<catonano>and previously, running I got this
<catonano>the version is 0.1.2
<sneek>gnu_guix, you have 2 messages.
<sneek>gnu_guix, Apteryx says: About pip not finding python packages, this is a "known" issue. I haven't bothered opening a bug about it but it's on my fixing todo list. Even have a branch with some hacking on it. The problem is how we define the searchpath (and use PYTHONPATH). We should create a distinct GUIX_PYTHONPATH for that instead.
<sneek>gnu_guix, adfeno says: continuing Apteryx's message: Also check that there is a file at "$HOME/.pip/pip.conf" and see if it has "target=" set to some place you can write to.
<gnu_guix>I have problems with connection.
<gnu_guix>Can I download big package?
<gnu_guix>I have problems with connection.
<civodul>ng0: for substitutes over Tor, you need to use an HTTP proxy that talks to Tor and set 'http_proxy'
<civodul>not related to 'guix pull' per se
<civodul>catonano: AC_LIB_LINKFLAGS_FROM_LIBS comes from Gettext, so you should add Gettext to your env
<civodul>(admittedly confusing)
<ng0>civodul: so far I assumed what we tried to fix up with http_proxy while you were away was broken for me. One way could be iptables style as a last solution
<ng0>what I had with the new http_proxy is:
<ng0>need to searc hthe right config
<ng0>actually I think I posted this.. I'll searc hthe mail
<ng0>also there's this patch which was never applied:
<ng0>I can't find the config atm but I used this (http_proxy "") in a modify-services i think
<ng0>resulted in guix-daemon becoming completely disfuntional and I had to roll back the generation of the system
<ng0>maybe I was just doing it wrong
<catonano>civodul: thank youu
<catonano>anyway, in orderr to attempt to build Artanis, I had to add autoconf, automake, libtool, flex and finally gettext as --ad-hoc things
<catonano>and after all that, make can't find /bin//bash
<catonano>how was this package built ?
<rekado_>catonano: in Guix we pass CONFIG_SHELL to point at the actual bash executable.
<rekado_>catonano: when you have to add autoconf and others you are working with sources that have not been bootstrapped. Are you trying to use the development version? If not, try a proper release tarball.
<rekado_>gah, I’m still working on Hartmut’s java patches.
<catonano>rekado_: I am using a released tarball: 0.1.2. I just saw autogen and I assumed I had to run it.
<catonano>I think I uuunderstand, now
<rekado_>I just thought I could add a few dependencise to run tests and I haven’t yet hit a proper leaf node.
<ng0>humpf. new neomutt release.. I'll prepare the patch
<rekado_>the bootstrapping story for Java is one of many disappointments.
<rekado_>catonano: if you see “configure” in the tarball you probably don’t need to run autogen.
<catonano>rekado_: ok, thanks
<ng0>before I send this, should we revert the tokyodb for neomutt patch so that I can add kyotodb?
<ng0>I think lfam suggested reverting it after I found out that kyoto is supported
<ng0>does it make sense if I just locally revert it and send the patch for that, or is that better up to people with commit access?
<rekado_>I’m missing context but this depends on whether the commit has already been published.
<ng0>it has been commited
<rekado_>a revert is just a regular commit
<ng0>afterwards I realized that the docs said tokyocabinet and kyotocabinet, and kyotocabinet is more current. So lmdb + kyoto makes more sense
<ng0>is it just "git revert $commit ?
<ng0>okay, got it
<ng0>almost done :) I think if some patch ticket for this is still open I'll close it when I have submitted the 3 new patches
<efraim>You can also 'git revert HEAD~2'
<efraim>ng0: I backed that one on kickstarter with the 4GB of RAM, they also have an earlier model with 4GB of ram
<ng0>ah :)
<ng0>okay, can take a minute or two more, kyotocabinet is not as easy recognized as tokyo
<ng0>I need to get the build log for something which was just grafted.. '--no-grafts --check' would give me a full build?
<ng0>I keep getting 'no build log for /gnu/store/ahhhhh…-neomutt-version.drv'
<ng0>okay I've got it.. more or less
<Apteryx>Some elisp code I'm trying to package (emacs-dvc) attempts to create a config directory in $HOME/.dvc when it gets compiled. What should I do in this case?
<Apteryx>OK, I think I have to check if I can somehow disable running the "dvc-autoloads.el" file.
<quiliro>i have the following error on guix system reconfigure:
<quiliro>builder for `/gnu/store/w4awi92nn3pam0kdfh1dac0nxa35yfbj-gnupg-2.1.19.drv' failed with exit code 1
<quiliro>on what bug-guix thread should
<quiliro>i report it?
<quiliro>be back after reboot
<lfam>quiliro: Please copy the output of the command that failed to a paste site such as sprunge.
<lfam>rekado_: I replied to your question about the texlive bug fix:
<lfam>rekado_: I'd like to push it ASAP. Please let me know what you think
<quiliro>lfam: before restart, i had pipe broken error when using sprunge
<quiliro>i will paste on bug-guix
<quiliro>or not?
<quiliro>now i am connected via ethernet instead of wifi
<quiliro>to see if that is the problem
<lfam>quiliro: Don't pipe to sprunge. Redirect the output to a file, and then send that file to sprunge
<lfam>That way, you don't have to keep the connection to sprunge for the duration of the build process
<quiliro>guix system reconfigure /etc/config.scm 2>&1 | curl -F 'sprunge=<-'
<quiliro>is what i did
<quiliro>what is the command now? name_of_file after | ?
<quiliro>guix system reconfigure /etc/config.scm 2>&1 | name_of_file
<quiliro>is that correct?
<lfam>`guix system reconfigure /etc/config.scm 2>&1 > name_of_file`
<quiliro>cat name_of_file | curl -F 'sprunge=<-'
<lfam>Try it :)
<quiliro>what is the difference between | and > ?
<ZombieChicken>Anyone know if there is some unwritten rule about forwarding an email from one mailing list to another?
<ZombieChicken>I received an email about a CVE for Qemu I'm thinking of forwarding since it includes a link to a patch
<lfam>quiliro: One is a pipe, the other is output redirection. It's a UNIX / POSIX thing
<lfam>ZombieChicken: Which CVE is it?
<lfam>There's no rule about forwarding messages. But, it would be better to send a patch than a forwarded email :)
<lfam>ZombieChicken: Our QEMU and related packages are currently vulnerable to maybe a couple dozen CVEs from the past few weeks. Help wanted!
<ZombieChicken>lfam: I don't have any patches myself, but I'm on the oss-security mailing list and saw one related to Qemu that had a patch attached
<ZombieChicken>well, linked, not attached
<lfam>Yeah, I subscribe to that list too. I have all messages corresponding to unfixed Guix packages on my to-do list
<quiliro>lfam: i know their names. would you please suggest something to read ... i sincerely want to learn
<ZombieChicken>As for the CVE: CVE-2017-6505
<ZombieChicken>lfam: Ah, in that case I'll assume you have it as well and I'll save everyone the bandwidth
<lfam>ZombieChicken: Save the human bandwidth by sending patches :)
<lfam>quiliro: This is a decent answer:
<lfam>quiliro: The best way to learn this is to try writing some shell scripts to simplify or automate some tasks that you do
<ZombieChicken>Well, if you're on that mailing list then there is a patch for the package in the email. As for a package patch, I don't know enough to do that and other things are more pressing (like finally ditching Gentoo)
<lfam>ZombieChicken: We *should* do a better job patching QEMU, but the volume of security issues published about QEMU is insane.
<lfam>Often, they get published when the patches are still in the RFC stage, so we can't address them at that time
<ZombieChicken>Ideally Qemu's devs would fix things and push updates to fix it and devs would just need to update the version number
<lfam>Yes, that would be best
<lfam>Second best: More Guix contributors do security patching :)
<ZombieChicken>I'm really, really torn on that idea tbh
<ZombieChicken>I don't like downstream patching
<lfam>Well, in most cases, either downstream applies the bug fix patch or the users wait some months
<ZombieChicken>Too easy to break something simple because you don't know what you're doing
<ZombieChicken>Yeah. Security patches are certainly a grey area imo
<lfam>I think there's a difference between writing a patch and cherry-picking an upstream patch
<lfam>The former is discouraged
<lfam>If you grep our commit log for CVE, those are almost all things that Guix users would be vulnerable to if we hadn't cherry-picked the patch
<ZombieChicken>and given this CVE is apparently just a way DoS from within the guest (causing a crash of the VM), I'm a little curious as to how important patching the build is in Guix
<ZombieChicken>a way to DoS*
<lfam>Exactly, a QEMU DOS is not my priority. But there is an open bug that gives the QEMU guest full host filesystem access
<Isorkin>ldd command not support?
<ZombieChicken>Isorkin: huh?
<lfam>I'm relatively sanguine about fixing QEMU bugs quickly. It seems that if you want a QEMU exploit, you can find one with a few hours of looking
<ZombieChicken>Which doesn't say much for Qemu to begin with
<Isorkin>ldd - print shared object dependencies, not found
<lfam>Anyways, I'd like to clarify my position and say that if some upstream project makes a bug-fix patch that I can understand, applying it is not a grey area at all.
<ZombieChicken>That I can understand
<lfam>But I am skeptical of writing patches from scratch
<lfam>The problem with QEMU compared to other big C programs in our tree is that we rely on QEMU for some functions of Guix
<ZombieChicken>Which, iirc, is what caused the long-standing Debian OpenSSL memory leak "fix"
<lfam>Right, that famous example
<ZombieChicken>Anyways, off to (re)start backing up a few hundred gigs of data over USB 2...
<lfam>Although I must be fair to the Debian maintainer. It was extremely difficult for downstream maintainers to communicate with the OpenSSL project at that time. There are some important projects that are still like that...
<lfam>You would not be able to ask their advice about a change or issue even if you tried
<lfam>quiliro: Are you using an i686-linux system?
<ZombieChicken>Always nice to have uncommunicative people writing important software. It really helps you feel confidant that they'll fix bugs instead of ignoring them
<lfam>I found a gnupg test failure when building for i686-linux
<ZombieChicken>lfam: On a somewhat related note; does GuixSD support LibreSSL?
<lfam>What do you mean by "support"?
<ZombieChicken>Repacing OpenSSL with LibreSSL
<lfam>You could try it relatively easily
<lfam>You could use package-input-rewriting to do it selectively for certain packages.
<lfam>Or you could try replacing the openssl variable entirely
<lfam>You'll be on your own re: substitutes if you do that
<ZombieChicken>Yeah, I thought that would be the case, but I wasn't sure if anything had changed on that front recently or not
<ng0>ZombieChicken: it was discussed in the past, but i think it just has to be done, later on
<ZombieChicken>meaning someone just needs to write up the package, handle the substitution, and integrate it with the configure system?
<lfam>Can you clarify what you mean?
<ZombieChicken>I'm just guessing at what would need to be done to have LibreSSL replace OpenSSL on systems where people prefer LibreSSL
<ng0>I thought it was discussed to replace where possible and applicable openssl with libressl
<ZombieChicken>Oh, you mean outright replace OpenSSL?
<ZombieChicken>I thought you were talking about making it an optional replacement
<ng0>iirc there have been discussions, or I imagined them
<ZombieChicken>I know I've mentioned it before, but I don't recall anything on the mailing list related to it
<ZombieChicken>but then again i have a bad memory
<ng0>i think searching libressl in my mails will turn up too much, but i can try
<ng0>yep, nothing related
<ng0>than it was just on irc always
<ng0>for services on GuixSD it's difficult i think (haven't bothered to figure out yet), but I keep some packages in my pakcage_path which are variants of the master ones, *-libressl
<ng0>where openssl is replaced with libressl
<lfam>Services should take a configuration option where you select the package they use. I just added this to the openssh-service so I could use my openssh-libressl package
<civodul>hey lfam
<lfam>Hey civodul, welcome back!
<civodul>lfam: i realized i probably messed up a bit by telling efraim to apply the GCC patch on core-updates
<civodul>sorry about that!
<lfam>The aarch64 patch?
<civodul>that's due to me reading messages mostly in chronological order
<lfam>I think that without a resolution for the flex problem, we are going to have rebuild from scratch anyways
<civodul>that's right
<civodul>i think we should just keep both versions for now
<buenouanq>anything big/cool happen in the last month I've been gone?
<lfam>I guess we'll need to keep the latest flex (2.6.3) and create a 2.6.1 package. There are many problems in 2.6.2
<paroneayea>civodul: !!!!
<paroneayea>welcome back :D
<paroneayea>we've missed you!
<paroneayea>I hope your vacation was good.
<quiliro>lfam: yes, my processor is 32 bits
<quiliro>lfam: did you find error in gnupg?
<quiliro>lfam: for 32 bits
<lfam>quiliro: I found a problem building GnuPG for 32 bits and reported it to GnuPG:
<lfam>Is that the same problem that you saw?
<quiliro>lfam: let me paste
<lfam>quiliro: It's the same problem
<quiliro>Skipped tests: ssh-import.scm
<quiliro>guix system: error: build failed: build of `/gnu/store/sa6fgn2ms2nip96pckv0yw7fxjc4pfcq-gnome-3.22.2.drv' failed
<quiliro>lfam: can i avoid gnupg for the moment?
<lfam>quiliro: I reverted the change. Run `guix pull` again
<lfam>Off-topic: Why does GNOME include both the 2.0 and 2.1 releases of GnuPG in its dependency graph? :/
<lfam>I really think it's a bad idea for other programs to try driving the gpg command-line
<quiliro>lfam: running `guix pull && guix system reconfigure --fallback`
<quiliro>lfam: as rooot
<nliadm>rooot is like root, but with even more permissions
<nliadm>rooot can execute in ring 0
<ng0>texinfo @command does exist, right?
<slyfox>looks like it does: