<mood>guix pull (and guix package -i guix) keeps failing when running tests for texinfo. It appears to have trouble forking <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 guix-devel@gnu.org? <civodul>we should probably change the .service file <phant0mas>I have some old ps2 controllers back at my island which I will play with during easter :-) <mck>rekado: was wondering what you use for a truststore with icedtea <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? <lfam>Okay. Thanks to you and Mark for handling the reversions while I AFK! <slim404>guixsd ships without ssh client in the default install <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 :-) <civodul>someone made a nice CSS for the manuals! <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 <wingo>what i do in guile-present is to handle some texinfo comments specially <wingo>humm, i don't have an example on-hand <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>but yeah, sounds like it would be worth submitting something <civodul>bavier: h01ger would happily accepts additions to blog post #50 at git://git.debian.org/git/reproducible/blog.git (aka. reproducible-builds.org) <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 <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. <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>someone besides me should make this decision. ;) I'm too close to the issue. <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. <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 <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>& 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>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 <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>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>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 <wingo>how do most distros run docker then? <civodul>yeah it has its daemon to set up containers, IIUC <wingo>ACTION was not aware of that <wingo>ah the daemon is run as root, and can make namespaces in children? <wingo>they have to do something namespace-related, so i guess chroot is the thing <wingo>network and pid and everything else <davexunit>uts, IPC, and mount namespaces are the others <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 <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>ACTION becoming less ignorant, slowly <efraim>what's our minimum kernel version? <efraim>3.16 for running and 3.18/19 for containers? <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>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>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>Festival uses an old Scheme dialect, which is fun <davexunit>so this synthesis tool is part of a bigger speech recognition toolchain. <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 <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 <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>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>but I don't use most of the board <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: the reason for the change in number-of-components is that upstream has changed their version numbering scheme <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 ***Digitteknohippie is now known as digit
***digit is now known as Digit
<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. <davexunit>this kind of stuff scares me off of haskell entirely <rekado>it's implemented on top of mumble (a Scheme dialect) which is written in CL. <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 <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 <df_>linguistic imperialism? <paroneayea>df_: I don't think it's imperialist to be accomodating of all glyphs... <df_>not all glyphs are created equal <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) <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 <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 <paroneayea>davexunit: I didn't think they were bad until I saw how guile handles shebangs and realized the rationale :) <davexunit>that launches a program whos ARGV only has 2 members! <davexunit>instead of what it should be: "/usr/bin/foo" "arg1" arg2" "arg3" <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? <paroneayea>davexunit: and now I just ran into shebang stuff again <paroneayea>davexunit: having a little script like ./syncbot.scm --foo --bar <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>someone else took "syncbot" as a user in the last few months <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>echo foo | guix environment --ad-hoc --pure sed -- sed s/foo/bar/ <civodul>i guess it doesn't work with --container, does it? <civodul>i would have expected something fishy to happen :-) <davexunit>but I remember explicitly making sure that stdin/stdout were piped correctly <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>Now everything is laid out nicely in the /gnu/store directory, but it still reports not being able to find the config directory. <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 <davexunit_>I was troubleshooting some weird networking issues <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>davexunit_: it lied! I'm reading it, there are multiple defuns ;) <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? <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>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_>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 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 <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 <htgoebel>lfam, davexunit: This works. Thanks. I'm wondering how to describe this in the manual? <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>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 <htgoebel>civodul: As usual for a configure-run it floods the screen. I never ever check all this blurb for warnings. <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 <htgoebel>checking the current installation's localstatedir... none <civodul>right, that means it didn't find any existing Guix installation <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>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? <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 <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. <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. <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>what better error codes do we have in store? :-) <civodul>yeah, i understand this is confusing