IRC channel logs


back to list of logs

<mood>guix pull (and guix package -i guix) keeps failing when running tests for texinfo. It appears to have trouble forking
<mood>Any ideas?
<alirio>bavier: for, i think the best is replacing "<metadata>\\nCreated by FontForge %d at %s" by "<metadata>\\nCreated by FontForge %d"
<mood>It looks like I solved it! The problem was caused by systemd's TasksMax. Setting it to 1024 for guix-daemon.service makes the build run
<civodul>mood: interesting; could you report it to
<civodul>we should probably change the .service file
<phant0mas>davexunit: thanks :-D
<phant0mas>I have some old ps2 controllers back at my island which I will play with during easter :-)
<phant0mas>but I need to get a better solder
<mood>civodul: I will
<mck>rekado: was wondering what you use for a truststore with icedtea
<sneek>mck, you have 1 message.
<sneek>mck, rekado says: I haven't used Java with certificate stores at all. I'm not a Java developer and I know very little about Java use in practise. Sorry.
<mck>rekado: ah saw your last message. np, thank you for all the effort packaging up icedtea, and for the response
***Digit is now known as Guest94719
***Digitteknohippie is now known as Digit
<lfam>davexunit: Should I push the static util-linux and btrfs-progs patches to core-updates?
<davexunit>lfam: core-updates sounds good.
<lfam>Okay. Thanks to you and Mark for handling the reversions while I AFK!
<civodul>Hello Guix!
<slim404>guixsd ships without ssh client in the default install
<slim404>seriously guys?
<df_>there isn't really a 'default install' as such
<df_>it will install what you tell it to in the config file
<civodul>slim404: "guix package -i openssh" should do the trick :-)
<wingo>also s/guys/people/ :)
<civodul>someone made a nice CSS for the manuals!
<rekado>very clean
<rekado>I wonder if we can get syntax highlighting for the many code examples.
<civodul>i don't think so, because @example does not provide info about the source language
<civodul>but maybe we could have paren matching when we hover over parens?
<wingo>perhaps we can extend texinfo
<wingo>afaiu @example must be on its own line
<wingo>so it could be @example scheme
<civodul>yes, definitely
<wingo>or @example lang=scheme
<civodul>there's also @lisp
<wingo>what i do in guile-present is to handle some texinfo comments specially
<civodul>comments as in "@c foo"?
<wingo>ACTION looks
<wingo>humm, i don't have an example on-hand
<wingo>anyway :)
<rekado>civodul: thanks for 7d27a0259 and my apologies for not getting it done myself.
<rekado>my boss showed me that the R consortium is willing to fund work benefiting the R community; he wonders if we can submit some Guix-related project proposal.
<rekado>probably should be more than just "import all of CRAN + bioconductor to Guix"
<civodul>"just" :-)
<civodul>but yeah, sounds like it would be worth submitting something
<civodul>bavier: h01ger would happily accepts additions to blog post #50 at git:// (aka.
<civodul>i think it'd be nice to mention what alirio & you did around Fontforge
<civodul>i think there were other reproducible issues fixed lately, but i forgot which one
<civodul>err, *reproducibility
<fps>rekado: hmm, the rapicorn patch doesn't apply cleanly to current master it seems
<fps>so should i checkout the version it applies to and then try to catch up to head?
<rekado>fps: oh. I think the review was positive, so I'm going to (rebase and) push it tonight.
<rekado>after renaming libpng12 to what Andreas recommended.
<krl>what would be the relation between docker and guix/nix? are they solving similar problems in a way?
<df_>for certain use cases, yes
<rekado>davexunit: do you think it would make sense to jump onto the docker wagon, add a token docker image feature to guix?
<rekado>I feel that there's little one can do to fight a hype.
<davexunit>not sure, maybe we could copy nix in this.
<wingo>i think it would be super-useful
<davexunit>but we have our own container implementation
<wingo>sometimes i need to make docker images and blah, other things are terrible
<davexunit>and I want to fight docker.
<davexunit>someone besides me should make this decision. ;) I'm too close to the issue.
<civodul>we could do both
<rekado>I understand and I don't really want to boost docker, but if people are so in love with docker, it might be the right thing (strategically) to offer a way to create a docker image from guix
<davexunit>I wouldn't attempt to block a patch that does what nix does, but I won't be the one to write it.
<wingo>yeah we can do both
<civodul>we could have 'guix system docker-image', say, even if it hurts a bit ;-)
<wingo>even at work we have some nixos machines, i don't feel like bothering to set up guix there, but if i could just copy over a docker image, that would be useful
<davexunit>civodul: yeah
<wingo>useful for deploying guix-based things on non-guix systems
<wingo>i.e. even without /gnu/store
<civodul>wingo: would binary tarballs fit the bill for such applications?
<rekado>in the bioinfo world a big tool many people use is Galaxy and it uses Docker in the background.
<davexunit>I need to rant about docker, coreos, and the so called "open container initiative" on my blog sometime
<wingo>civodul: it could but it's somehow more work to think about different versions of the same thing in that context
<rekado>it would be great if we didn't have to make a decision "either guix or something that works with docker".
<wingo>of course it's a waste of space to have a directory with a bunch of images
<wingo>but it saves some mental space ;)
<davexunit>I think people have made a very big mistake by thinking that the disk image *is* the container
<rekado>I discussed this yesterday with someone and it was very hard to make them understand what containers are
<wingo>davexunit: i would enjoy that rant :)
<wingo>i see it like, we have guix the user-space package manager and guixsd for systems. guix-based docker is like the user-space guix -- a useful tool to get stuff done, and a vector for further guixification
<wingo>we don't really see guix and guixsd as competing with each other, so we shouldn't see guix-on-docker as competing with guix containers either
<wingo>imo anyway :)
<rekado>wingo: I agree
<wingo>& likewise guixsd wouldn't be here if it weren't for user-space guix, so i suspect to a degree guix-on-docker will help people know what they want out of a guix-container 'ecosystem'
<wingo>and probably to bring more people away from docker to guix containers, eventually, as people also migrate from other os's to guixsd (muahaha world domination etc)
<wingo>ACTION opinions today apparently
<civodul>if we can show the benefit of declaratively building Docker images, then it's easier to show the benefits of declaratively building OSes in general
<civodul>i guess all we need is a Docker package now :-)
<davexunit>where is that go package?
<davexunit>need to do that and then recursivelu unbundle docker...
<rekado>do we need docker to build the image?
<davexunit>go projects just bundle all the source of their deps and statically link, terrible.
<wingo>rekado: i have that same ignorant question
<wingo>would be nice to avoid it if possible
<civodul>yeah, dunno
<wingo>i guess we have to package docker to give it a try tho ;)
<davexunit>I would like a way to make standalone binary bundles that don't rely on /gnu/store
<davexunit>that someone could just unpack and run
<davexunit>would give me a way to distribute games to people that don't run guix
<davexunit>but I'd get the benefit of using Guix to develop it
<civodul>the format looks rather simple
<civodul>davexunit: i think this would require either relocatable binaries (hard) or chroot/container on the user side
<davexunit>yeah containers would obviously work, but most distros disable user namespaces by default
<civodul>"most" or "some"? :-)
<wingo>how do most distros run docker then?
<davexunit>docker doesn't use them
<civodul>yeah it has its daemon to set up containers, IIUC
<wingo>ACTION was not aware of that
<davexunit>only recently did it add support
<davexunit>but yup, everyone runs containers *as root*
<wingo>ah the daemon is run as root, and can make namespaces in children?
<wingo>haha loldocker :)
<civodul>yes, that's my understanding
<davexunit>even then they didn't use them
<davexunit>because they were deemed insecure
<davexunit>but running as root is fine, apparently
<wingo>ah they chroot then
<wingo>sorry, i am so ignorant
<davexunit>yes, but if you escape..
<wingo>they have to do something namespace-related, so i guess chroot is the thing
<davexunit>chroot + 5 namespaces
<davexunit>no user namespCr
<wingo>network and pid and everything else
<davexunit>no user namespaces until recently
<davexunit>uts, IPC, and mount namespaces are the others
<wingo>ACTION nod
<df_>isn't it that most distros disable user namespaces for non-root users?
<df_>so the daemon running as root could still run things in separate user namespaces?
<davexunit>which makes distributing a binary bundle that requires a container to run not worthwhile
<davexunit>df_: yes
<wingo>df_: apparently the daemon doesn't use user namespaces -- it uses chroot + mount namespaces
<wingo>i mean, user-mode filesystem namespaces, is what i meant
<davexunit>it can do it now, but this is very new to docker
<wingo>ah cool
<wingo>ACTION becoming less ignorant, slowly
<efraim>what's our minimum kernel version?
<efraim>3.16 for running and 3.18/19 for containers?
<davexunit>wingo: that's what we all try to do ;)
<davexunit>slowly but surely
<davexunit>efraim: 3.19 IIRC, but kernel version isn't a good measurement because distros backport things
<davexunit>I'm running a 3.13 at work (ubuntu 14.04) but I can do all the container stuff with guix
<davexunit>and in fact I'm using 'guix environment --container' quite frequently now to isolate environments from Ubuntu things
<civodul>davexunit: did you show off with your colleagues? ;-)
<davexunit>which, speaking of Docker as a bridge to get people more into Guix, is a great half-way solution for certain tasks
<davexunit>civodul: yes, I showed them.
<davexunit>some thought it was cool.
<davexunit>I've also showed off how I use Shepherd as a user service manager to control the many many daemons we need to run to do development
<davexunit>today I'm going to try to package up some speech recognition related things
<davexunit>hopefully they will be upstreambale.
<davexunit>x11 licensed
<davexunit>but has a crappy build system. the makefile has no 'make install'
<efraim>davexunit: I have a growing collection of arm64 boards I wanted to work with, hopefully the ancient kernel they ship with will work well enough
<davexunit>efraim: guix-daemon works with pretty old kernels
<civodul>davexunit: speech synthesis
<civodul>Festival uses an old Scheme dialect, which is fun
<davexunit>oh really? neat. I haven't used it yet.
<davexunit>so this synthesis tool is part of a bigger speech recognition toolchain.
<civodul>it even has a texi manual
<civodul>isn't it great?
<civodul>feels like at home :-)
<davexunit>I'll try to get something packaged. will probably require some odd hacks.
<davexunit>what I've learned through this project is that the "secret sauce" of speech recognition is not software, but data.
<davexunit>which leads me to wonder if there is an equivalent of OpenStreetMap for speech data
<davexunit>and if not, there should be, so that we can build up a common corpus that cannot be exploited by companies without reciprocating.
<davexunit>there's freely available audio out there that does get used, but it has no copyleft to protect it.
<efraim>davexunit: I have a growing collection of arm64 boards I wanted to work with, hopefully the ancient kernel they ship with will work well enough
<phant0mas>efraim: I am currently trying to build the bootstrap-tarballs for an arm64 juno board
<phant0mas>we could work together on porting to arm64
<efraim>phant0mas: awesome, I bought a pine64, odroid-c2 and lenovator hikey board
<davexunit>old, non-mainline kernerls is what worries me about all these ARM boards
<davexunit>that said the new beagelboard x15 looks cool
<davexunit>if only the GPU was liberated :(
<phant0mas>this is a big problem with all those boards
<phant0mas>efraim: I will send my patches to the list
<efraim>i'll have to check out that board also
<davexunit>phant0mas: attempting to build the AVR toolchain with GCC 5
<efraim>i tried to buy boards that boot from usb stick, comparing how easy it is to update the RPi vs my other arm board that boots from emmc
<phant0mas>davexunit: it should work
<phant0mas>acording to avr-libc's manual the latest version works with gcc5
<mark_weaver>efraim: the minimum kernel version for running guix binaries is 2.6.32
<mark_weaver>efraim: see "--enable-kernel=2.6.32" in our 'glibc' package in gnu/packages/base.scm
<efraim>$239 is a bit steep compared to the other arm boards out there
<efraim>for the beagleboard-x15
<efraim>but I don't use most of the board
<davexunit>it's a big board
<efraim>oh wow juno's a big board too
<davexunit>if I have packages for both avr-gcc version 4.9 and 5.3, should the variables be named avr-gcc-4 and avr-gcc-5?
<davexunit>or could avr-gcc-4 just be avr-gcc because it's the default gcc version?
<phant0mas>efraim: it's not mine, I am just borrowing from the lab :P
<mark_weaver>davexunit: avr-gcc-4.9 and avr-gcc-5
<mark_weaver>davexunit: the reason for the change in number-of-components is that upstream has changed their version numbering scheme
<davexunit>mark_weaver: okay, thanks.
<civodul>rekado: BTW, how far did you go with GHC bootstrapping?
<civodul>ACTION tries upgrading our default GCC to 5.3, worries about bootstrapping
<bavier>civodul: I went as far as the first publicly-available C source, but IIRC it only builds with some early version of gcc 4
<bavier>if that's relevant
<civodul>bavier: yes, that's useful info
<civodul>we should create
***Digitteknohippie is now known as digit
***digit is now known as Digit
<davexunit>sounds fun
<davexunit>are you posting this because you see potential for bootstrapping goodness here?
<civodul>davexunit: yeah i'm in a bootstrapping mood today :-)
***mv is now known as marxistvegan
<rekado>civodul: I didn't continue bootstrapping GHC because even the oldest sources can only be built with generated C.
<civodul>Someone could Just rip this code and write a C-to-GuileVM compiler
<rekado>so I didn't think it's worth pursuing.
<civodul>we're all screwed!
<davexunit>this kind of stuff scares me off of haskell entirely
<rekado>well, there's yale-haskell
<civodul>ah yes, that's the one in Scheme?
<davexunit>the complexity of haskell itself is crazy.
<rekado>it's implemented on top of mumble (a Scheme dialect) which is written in CL.
<civodul>ah ha :-)
<rekado>I've been trying to write a Guile backend, but only during my really short commute
<civodul>then all we need is SBCL, which itself can be bootstrapped from CMUCL, which itself...
<rekado>so I really have nothing to show yet
<rekado>recently I'm doing so many things at the same time I might as well do nothing at all.
<rekado>ACTION hurries off to another appointment
<civodul>i know that feeling
<davexunit>ACTION might make 'guix environment' do that shebang thing that nix-shell does
<bavier>davexunit: where you can put 'guix environment' in a shebang?
<paroneayea>ACTION installs fonts-google-noto in his environment
<paroneayea>I wonder if I'll regret it :)
<paroneayea>er, profile
<davexunit>what's potentionally regrettable?
<davexunit>ACTION is ignorant about this font
<paroneayea>davexunit: the package install is >500mb :)
<paroneayea>but it has like, fonts for all unicode glyphs
<df_>linguistic imperialism?
<paroneayea>including all the cool kid emojis
<paroneayea>df_: I don't think it's imperialist to be accomodating of all glyphs...
<bavier>that's an impressive feat
<df_>not all glyphs are created equal
<bavier>reads like a conspiracy theory
<paroneayea>df_: I guess so... it looks like they're working on it
<df_>see also: han unification
<df_>(ok, that was the unicode consortium's decision, but I suspect it was driven by those that wanted unicode to fit into 2 bytes, such as microsoft)
<paroneayea>df_: I guess I don't know enough about it
<paroneayea> seems like an interesting read, for later.
<df_>not that noto is a bad thing in itself
<df_>it's great in many cases
<paroneayea>it might be that there is systemic imperialism, it might not really be one actor
<df_>just that maybe we should be wary about who has control over our writing systems
<paroneayea>sure, though releasing everything under the OFL is a good step by Google on that front
<paroneayea>also, sadly, Google is pretty much funding almost the entire state of "open fonts"
<paroneayea>though they're being pretty loose about letting David Crossland and his team have a lot of free reigh if I understand also
<df_>the old, old, problem
<paroneayea>nobody else is funding it
<paroneayea>so it's hard to fault google also
<df_>we need funding but sometimes we must accept it from those whose goals differ from ours
<paroneayea>it would be nice if we could get other actors involved
<davexunit>shebangs are literally the worst
<davexunit>what an absolutely awful interface
<paroneayea>davexunit: heh
<davexunit>in more ways than I already knew
<paroneayea>davexunit: I didn't think they were bad until I saw how guile handles shebangs and realized the rationale :)
<davexunit>#!/usr/bin/foo arg1 arg2 arg3
<paroneayea>and of course spending time in guix too
<davexunit>that launches a program whos ARGV only has 2 members!
<davexunit>"/usr/bin/foo" and "arg1 arg2 arg3"
<paroneayea>davexunit: yes very confusing
<davexunit>instead of what it should be: "/usr/bin/foo" "arg1" arg2" "arg3"
<davexunit>127 byte limit
<paroneayea>davexunit: pose-icks
<davexunit>no portability
<davexunit>/usr/bin/env is a nasty hack
<davexunit>my conclusion is that I don't think 'guix environment' will have the shebang stuff that nix-shell has
<davexunit>because they rely on /usr/bin/env for everything
<davexunit>on top of the complexity of actually implementing this because shebangs don't work right
<paroneayea>the difficulty of being pure about everything is you learn about how impure the rest of the world is?
<davexunit>it's not even purity, in this case.
<davexunit>shebangs are just completely broken.
<paroneayea>davexunit: and now I just ran into shebang stuff again
<paroneayea>davexunit: having a little script like ./syncbot.scm --foo --bar
<paroneayea>doesn't work so nicely once you're on guixsd
<davexunit>huh? that should work just fine
<paroneayea>there's no easy #!/usr/bin/guile
<paroneayea>davexunit: so without a pre-install-env
<davexunit>right, shell scripts are not portable on their own.
<davexunit>it's because of FHS *global state* that they *seem* portable.
<davexunit>would be the equivalent for "portable" GuixSD scripts
<paroneayea>ACTION nods
<paroneayea>oh hey :(
<paroneayea>someone else took "syncbot" as a user in the last few months
<paroneayea>I never got around to registering it
<davexunit>darn :(
<paroneayea>ACTION uses zincbot
<davexunit>civodul: idea for 'guix environment' shebang interpreter
<davexunit>basically what guile does
<paroneayea>davexunit: guile's looks a bit differently
<davexunit>oops, typo
<civodul>davexunit: looks good
<davexunit>!# at the end
<paroneayea>it also uses that \\ hack
<davexunit>not sure if that's absolutely necessary
<davexunit>for our case
<davexunit>when 'guix environment' runs with no arguments it will attempt to read from stdin up to the !# and parse out the real args
<davexunit>the rest of stdin will be available for the launched program to read
<davexunit>I tested that 'guix environment' already does the right thing when using pipes
<davexunit>this works:
<davexunit>echo foo | guix environment --ad-hoc --pure sed -- sed s/foo/bar/
<civodul>i guess it doesn't work with --container, does it?
<davexunit>civodul: it does!
<civodul>woow, cool!
<davexunit>I double-checked
<civodul>i would have expected something fishy to happen :-)
<davexunit>but I remember explicitly making sure that stdin/stdout were piped correctly
<davexunit>using dup
<davexunit>or something...
<davexunit>nah, didn't need dup. I needed to close different sides of the pipe in the parent/child process
<davexunit>it was so long ago, can't remember clearly ;)
***Digitteknohippie is now known as Digit
<kyamashita>So Red Eclipse binaries built by replacing DESTDIR with INSTDIR as used in its Makefile.
<kyamashita>But data won't extract to the installation folder...
<bavier>kyamashita: what do you mean? there's an error while extracting? or the data doesn't end up where you expect?
<kyamashita>I don't see the data folder in redeclipse's /gnu/store folder
<kyamashita>The data and config folders have to be with Red Eclipse or it won't launch.
<bavier>kyamashita: how are you handling the extraction? maybe you need to pass -C to tar?
<kyamashita>I'm passing "-Cdata" to tar, but I see no data folder... Perhaps I'm missing a copy step.
<bavier>kyamashita: "data" will probably extract into the build folder; which would need an additional copy to the installation folder. You might also do something like (system* "tar" (string-append "-C" %output "/data") ...)
<bavier>so that the data is extracted directly to the store
<kyamashita>Trying this now.
<kyamashita>Now everything is laid out nicely in the /gnu/store directory, but it still reports not being able to find the config directory.
<kyamashita>I'll be back shortly.
<lfam>mark_weaver, civodul: What do you think about the OpenSSH patch? It's an upstream patch for a named CVE. Debian has applied it, but there is not much info on the net, yet.
<suitsmeveryfine>civodul: I'm trying to fix the xscreensaver locking screen but have a problem with the code you posted.
<suitsmeveryfine>I though we could maybe discuss it here rather than to send a lot of emails back an forth.
<davexunit_>sigh, I used nmap from an EC2 VM and Amazon sent my boss and abuse notification
<bavier>that's quite the assumption
<davexunit_>I was troubleshooting some weird networking issues
<paroneayea>civodul: re: bootstrapping....
<davexunit_>so I port scanned a server to see if what nmap reported was what I expected to be open
<davexunit_>an external server, which I guess was the problem
<paroneayea>mark_weaver: ^^^
<paroneayea>maybe you already knew about it :)
<davexunit_>paroneayea: "scheme in one defun" I like it!
<paroneayea>davexunit_: it lied! I'm reading it, there are multiple defuns ;)
<paroneayea>still, very little
<lfam>Should I push this OpenSSH patch?
<htgoebel>What updating package descriptions (in gnu/packages/*.scm), do I need to restart the daemon, too? Or is it okay to only use the freshly build guix?
<htgoebel>Or can I even save building guix?
<mark_weaver>paroneayea, davexunit: Guile was derived from SIOD
<mark_weaver>more precisely, SCM was derived from SIOD, and then Guile was derived from SCM
<lfam>htgoebel: If you change a package definition, you don't need to restart the daemon to get the updated package definition. You just need to do a `guix build foo` against some copy of Guix that has the new foo.
<lfam>Sorry, that's unclear
<paroneayea>mark_weaver: huh! wow!
<lfam>To get the software provided by the updated package, do as I said. To get the updated package definition itself, you'll either use `guix pull` or you can also build against a copy of the Guix source tree in git
<davexunit_>cool history lesson.
<davexunit_>I took a quick look at the festival Scheme code. there's a lot of it. pretty inelegant code, but I'm happy to see it.
<davexunit_>funny that it won't be me that introduces the first Scheme tool at work.
<davexunit_>I have an almost working version of the festival speech tools, then it's off to build festival itself.
<htgoebel>lfam: I need to test the changes I made the git checkout. So what do you mean with "build against"? When using pre-inst-venv, it tries to connect to the daemon on a non-existing socket
<lfam>I was reading htgoebel's java patches, and I'm wondering. Does this method of creating package aliases work?
<lfam>I tried (define-public openssl libressl) and that did not work
<lfam>htgoebel: Is the daemon running?
<lfam>What version of Guix do you have installed, and is the git repo up to date?
<bavier>I was wondering why introduce the java aliases at all? why not just do a global rename? AIUI there aren't many packages currently
<lfam>bavier: You have a good point. The only reason I can think of is 3rd party private packages
<lfam>But, my question is more general. Does that method work?
<bavier>lfam: I should, it's done in some other places I think
<davexunit_>htgoebel: ./configure --localstatedir=/var
<htgoebel>lfam: The demon is runnig. It belongs to my system-wide installation. But the guix build from the git-checkout wants to connect the daemon on a different socket.
<bavier>e.g. for "gcc" in gnu/packages/gcc.scm
<lfam>htgoebel: Did you ./configure as suggested by davexunit?
<lfam>That variable is important
<htgoebel>lfam, davexunit: will try. MOMPL. Prior I've done as written in the manual
<lfam>MOMPL = (One) moment please
<davexunit_>lfam: third party private packages don't matter
<suitsmeveryfine>civodul: never mind. I'm sure you have more important things to do.
<htgoebel>lfam, davexunit: This works. Thanks. I'm wondering how to describe this in the manual?
<lfam>It is described, but the description is oblique. I think that section (8.1) could be improved.
<htgoebel>davexunit: 3rd party packages have been the reason why I've put the aliases in. If these do not matter, simply drop that patch
<lfam>I wonder if anybody has ever not had this problem the first time?
<htgoebel>lfam: This is the section I tried to follow.
<htgoebel>lfam: Maybe this section should be restructured: Maybe 1) building from git with some guix already installed 2) ... without same guix already installed 3) Hacking the daemon
<lfam>htgoebel: I really think that section should be more descriptive. It would be helpful if you could review past discussions that mention 'localstatedir' on guix-devel, and then file a bug with an outline of proposed changes.
<lfam>I would not spend too much time writing the actual changes at first. Most likely you would need to revise them quite a bit.
<lfam>Oh, I see you want to change that section more broadly. Then, you'd probably want to search for more than just 'localstatedir' on guix-devel.
<lfam>I think the need to set localstatedir appropriately needs to be communicated more clearly in the manual.
<civodul>the manual mentions localstatedir at and
<civodul>but yeah, maybe that can still be improved
<htgoebel>lfam: communicating localstatedir would be the minimum. But maybe it is enough to simply add one sentence or two
<lfam>It is mentioned, but I think many users are just reading 8.1. We might as well put the information where they are looking for it.
<htgoebel>civodul: But when I want to build guix, I'm not locking into "The Store", would I? Neither would I read the requirements, if I already have it running.
<civodul>but nowadays 'configure' warns and hints at a solution, did you get this warning htgoebel?
<lfam>It seems that in order to replace openssl with libressl, I have to set the name like this: (define-public openssl (package (inherit libress) (name "openssl)))
<lfam>I did not realize that our configure script had a warning now.
<lfam>There is a typo in that code. s/libressl)/libressl)
<civodul>htgoebel: right, "Building from Git" should say something
<lfam>Bah. The 'l'
<htgoebel>civodul: As usual for a configure-run it floods the screen. I never ever check all this blurb for warnings.
<htgoebel>But no warning anyway
<lfam>civodul: I need to figure out the difference between the OpenSSH repo that you linked to and the openssh-portable codebase that we use.
<civodul>htgoebel: actually it should be an error by default
<lfam>I wonder if your link is to the non-portable OpenBSD-only version?
<civodul>see GUIX_CHECK_LOCALSTATEDIR in m4/guix.m4
<civodul>i did test it quite a bit
<htgoebel>checking the current installation's localstatedir... none
<htgoebel>is all it says
<civodul>right, that means it didn't find any existing Guix installation
<civodul>is there one?
<civodul>maybe there's one but you built in 'guix environment' so it didn't find it?
<htgoebel>ACK, I'm builting in an env, as suggested in sec. 8.1
<civodul>in that case it cannot find the existing installation, hadn't thought of that :-/
<civodul>well we need to update that section
<civodul>not sure about the configure warning/error
<civodul>htgoebel: in other news, i'm looking at your Django patches, nice work :-)
<civodul>do we need a "python2-django" as well?
<civodul>hey, quiliro
<quiliro>civodul: hey!
<quiliro>is all ok with hydra?
<quiliro>> Estimado Frank Villarreal: > > Gracias por enviar su correo. Espero que algunos alumnos o docentes se > encuentren interesados. Por el momento estamos interesados en recibir > un pasante que sepa desarrollar aplicaciones para Android, si lo > tienen disponible. Ya tienen algunpasante para nosostros? > Además, me gustaría saber si ya tienen personas interesadas en los > otros proyectos que le he planteado. Ya se resolvio este ot
<quiliro>guix substitute: error: download from '' failed: 503, "Service Temporarily Unavailable"
<quiliro>that was the text i wanted to paste
<htgoebel>civodul: Thanks, but it's not much more then guix import pypi :-)
<htgoebel>python2-django would be a good idea, since many django-projects out there still use python2.
<quiliro>this is happenning for a long time
<quiliro>is that normal
<htgoebel>Do we have a change getting a collaboration platform like gitlabs for guix? I find it extremely ineffective and tremulous updating the patches. With gitlab I'd simply push the updates to my merge-request - done.
<quiliro>is that error with hydra normal?
<quiliro>civodul: do you have any idea?
<civodul>quiliro: which error?
<civodul>ah yes
<civodul>yes, it's normal
<civodul>that's because Hydra does not distribute texlive-texmf, which is very big
<civodul>so you need to use --fallback as the message suggestse
<civodul>arguably not optimal, but that's what we have now!
<kyamashita>civodul: Cool! I didn't know that Hydra didn't distribute that package. I thought I was just always unlucky.
<civodul>heh, maybe 503 is misleading?
<civodul>what better error codes do we have in store? :-)
<kyamashita>No kidding.
<civodul>yeah, i understand this is confusing
<quiliro>civodul: it works now...thanks
<civodul>yw, but beware of texlive (4 GiB)