<brendyn>ng0: Is libressl set to replace openssl completely? <ng0>the parts it intends to replace it does. the others are dropped. there's the libressl website and documentation itself, and there is also https://wiki.gentoo.org/wiki/Project:LibreSSL .. with choosing exact versions of software which had been tested with libressl already and possibly patched, i was able to setup a functional desktop system 6 months ago or e ven earlier.. the early blockers, last year were mysql which has also been fixed by now. <brendyn>Well Guix can have everything all at once \\o/ <ng0> 'hasufell committed on Jul 13, 2014' .. first commit when work on libressl testing started in gentoo, at that time not an official community project. <ng0>i still have to test my own ebuilds and packages against libressl.. i was focused more on fixing the features rather than testing ssl. <ng0>i think I can unbundle fonts in 0ad-data.. some we already packaged. i also see no mention of https://www.latex-project.org//lppl/ this license, yet gentoo claims this is used in 0ad-data or was it 0ad.. licenses can be added later though. <ng0>s/idontknow. something somewhere i will just read the sources and add what find <brendyn>I've played 0ad before, but I got bored pretty quickly <ng0>huh. don't we have icu packaged? searching for icu returned nothing directly icu. or do I have to use icu4c then? <brendyn>Is there a process for taking package descriptions from places like debian and getting their translations into the translation project? <brendyn>Where can I find info on how translations are shared between projects? <brendyn>For Guix on foreign distros how do I set the locale? Does it simply use my system locale? <lfam>Regarding translations, I'm not sure. I would ask the Translation Project <brendyn>I have read that but it doesn't explain <lfam>ng0: The icu4c package's description calls itself ICU, so I would try that <ng0>yes. seemed to work. <lfam>brendyn: Basically, install glibc-locales for the user whose locales you want to set. Then, export that GUIX_LOCPATH variable wherever you configure your login shell. <lfam>brendyn: For some cases, the smaller package glibc-utf8-locales might work. It contains a subset of glibc-locales <brendyn>GUIX_LOCPATH=$HOME/.guix-profile/lib/locale <brendyn>I don't get it? This is configuring where glib is, not which locale to use <lfam>brendyn: glibc is different from glib, but I get it. Are you asking how to choose a particular locale? <lfam>That's for the Zsh shell <lfam>For Bash, you'd use ~/.bash_profile, I think <brendyn>Ok, so there is no /etc/locale.conf? <lfam>That file doesn't exist on this Debian system <lfam>To be honest, I'm not sure if I'm doing this right. But, it's working for me <brendyn>Ok so regardless, it's all about those env variables being set, right? <brendyn>lfam: Why does LANG settings have X_Y.UTF-8 but LANGUAGE just has X_Y ? <davexunit>the sooner we all realize we should be farmers, the better. <lfam>maybe `man 7 language` can help <brendyn>Just make it so everyone can set their keyboard layout and language.... It'll be easy, they said. <brendyn>Currently there are 4 different places I need to deal with keyboard layout settings. The login shell, login manager, wayland, and X <brendyn>I think Guix currently has not a single line of Chinese translation ;/ Gotta start somewhere I guess <ng0>O.o nvidia-texture-tools last release tarball is from 2010.. i'm picking patches from commits between 2010 and 2016 and I wonder if I should just use a commit from this year instead. one of them fixes gcc 6 compilation for example <lfam>Maybe I should be setting LANG instead, I don't know <ng0>another commit 'fix memory leak reported by...' why don't they just release a new version <brendyn>Maybe this will work. LANG=zh_TW.UTF-8; LANGUAGE=zh_TW:zh_CN:zh_SG:en_AU:en_NZ:en_GB:en_US <ng0>yeah. i'll pick that <brendyn>Is it safe to have downloading and extracting a zip file without hash checking it, but hash checking the extracted contents? <davexunit>could be that the zip is designed to exploit the unzip utility and execute arbitrary code <davexunit>likely? no, but that's a realistic attack vector. <brendyn>davexunit: Ok well this zip file may be updated often, but some of the contents won't. I suppose I'll just have to deal with that. <brendyn>well, not often. every few months I guess. And the contents make up two packages. <brendyn>So is it correct that Guix does not have a locale-gen command, rather the package contains compiled locales? <brendyn>ACTION now has 2 contributions in Guix \\o/ ***Digitteknohippie is now known as Digit
***harlequn79 is now known as harlequn78
***harlequn79 is now known as harlequn78
***harlequn79 is now known as harlequn78
<jmd>How can I get a reference to the source directory during build? <efraim>cwd for current working directory? <jmd>Unfortunately the build system keeps cding <jmd>I suppose I could save it at the start. <jmd>Is there a convenience function which can do (begin (chdir "x/y/z") (let ((x (zero? (system* "xxx")))) (chdir "../../..") x)) ?? <ng0>and darcs compiled \\o/ i noticed that transformers is part of base and needs to be ommited. it's not done, but it succeeds the first part of build <ng0>so how do other haskell applications deal with finding terminfo, which comes with ghc itself? I accidentally packaged it, figured out this causes problems to darcs, but correcting it does not make haskeline detect terminfo.. any info for someone who knows ntohing aboiut haskell? <jmd>I thought terminfo was part of ncurses. <ng0>si. but ghc-terminfo isn't. <ng0>look at ghc itself to see the only example i found how it's done in haskell. but i don't know if i should apply htis ***Digit is now known as Guest46160
<ng0>it almost works.. the test suite shows that i need to patch something in darcs, but so far i'm positive that it will work soon <ng0>famous last words of every sinking ship captain. ***Guest46160 is now known as Digitteknohippie
***Digitteknohippie is now known as Guest81592
<cehteh>that makes me thinking about how would one package such conviniently in guix, of course one package for the resize tool, but then it would be nice to have some facility which generates and installs scaled cursor sets <bavier>cehteh: could just be a procedure that produces a scaled font package from an existing X font. <cehteh>either generate a package on the fly which then gets installed, or provide parameters in installation (which cursor set, scaling factor) <cehteh>has guix a notion of jit-packaging? <bavier>cehteh: there are some facilities for modifying inputs and source on the fly, but not build steps or general package transformations. <cehteh>could be a thought to add that, but its not pressing to be done soon <cehteh>ACTION just wants to become more familar with guix and improve things which he feels are more important <davexunit>packages are just regular scheme objects, so you can do whatever you want <cehteh>guix edit --clone <packagename> would be cool .. if GUIX_PACKAGE_PATH is set then copy the package definition there and open that for editong <davexunit>there are several instances of writing procedures that return packages <cehteh>davexunit: i am not a regular scheme object yet :) <davexunit>or procedures that take a package as an argument <bavier>something like 'guix package --transform=foo -i bar' might be fun, where foo is some package-transformation procedure. <cehteh>either way, even if anything could be done in scheme, some things prolly should not be done and/or need some agreement <davexunit>not nearly as much agreement as a change to the CLI <cehteh>well i'd like to push some things to the cli, not there yet, i have to learn more about guix first, but will do so <bavier>cehteh: yeah, discussions welcome <cehteh>bavier: suggested some times ago to have a guix hash --exclude facility to exclude .git and build/ dirs for example, and i think i can explain that this wont break reproducible builds <bavier>cehteh: recently was pushed an --exclude-vcs option <cehteh>i like more generic ways, else we end up with definition for each and every vcs <cehteh>with a generic --exclude the packager would care, and can handle build systems too <cehteh>ignoring caches and build dirs generated by cmake, scons etc <bavier>the implementation is fairly lightweight, and corresponds to the directories that would be removed by the various vcs download methods <bavier>cehteh: you're suggesting something that could be used in a dirty source tree? <cehteh>yes, *but* only for software which is known to build clean of course, i know that many software fail that prerequisite <cehteh>but its easy to find out if a build system is properly set up and does the right thing <cehteh>if not one (the packager) could always run the correct cleaning procedures first <cehteh>git reset --hard; git clean -dfx ... <cehteh>but copying the build tree around has a lot overhead <cehteh>if we can get deterministic builds out from persistent (git) checkouts w/o copying a massive amount of files around for building that would safe a lot resource <cehteh>of course with a big 'IF' .. no shortcuts, that idea only works when it holds the same determinism gurantees that the current build does <cehteh>but IF it works, then i think there should be no much arguments against it <bavier>remind me again, what leads to the non-determinism with the .git directory? <ng0>the -x for guix hash was the best minor addition recently for me. copying my working repos only to hash them was annoying. <ng0>i have 20 failing shell tests for darcs out of 430 total tests, so that's something which should be fixable. and if it's just the tests andcan't be fixed right now tests can be disabled. <bavier>ng0: are they failing because of /bin/sh paths? <ng0>there's something the haskell importer should get.. a list of 'base' packages which do not have to be packaged.. so you get 'inputs ghc-terminfo' and you think you need to pacjage it while you actually just have to use ncurses as input and let ghc handle it as it is already existent. <ng0>at least 1 of them, yes. <bavier>ng0: that would be nice for the importer. shouldn't be too hard to do <ng0>had a phone call i'll investigate today or tomorrow the actual failures. <ng0>there's also a funny thing about the python importer. i should post it to the bugs list.. guix-devel was the wrong place <bavier>ng0: would be nice to mention what your invocation of 'guix import' looked like <bavier>e.g. which pypi package you were trying to import <ng0>one of the larger projects i am packaging.. kallithea-scm: 'guix import pypi kallithea' which is just lazy for getting more inputs etc.. <wilo>hi guys, i have a question, ¿how to install GuixSD and set home directory to another partition? <ng0>sorry, wrong pypi import.. <ng0>let me try to remember <ng0>guix import pypi searx <ng0>that's the one with optional socks dependency module. <bavier>wilo: it should just work, I think <bavier>wilo: as long as you have the mount point declared in your os configuration <ng0>darcs failed: Not a repository: https://pijul.org (Peer certificate cannot be authenticated with given CA certificates) ... this means, before i debug the 20 tests tomorrow, that darcs also needs one of these ssl pointers I hate and curse <bavier>seems a lot of people like to bundle their own certs <ng0>no, that's just curl_ca, git_ca etc all over again .. maybe one just needs to get used to setting it via environment variables, but it's not ideal imo <ng0>in the web browsers, the cert for pijul.org is accepted <bavier>right, I meant to suggest it's not a nice practice <plskillme>hi, I'm just dropping by to bitch a bit, hope you don't mind. See, first time I got guix it was version 0.9 I think. I liked it, it would install seamlessly which nearly no other GNU/linux distribution does for me <plskillme>just following the steps, no nasty surprises <plskillme>but new releases of guix always fail with an error and I never can get it done, at all <plskillme>the reason is also never helpful, this time gtk+ something failed <plskillme>last time (in v0.10) guix itself (the package manager) failed to even build <bavier>we can't help if you don't stick around to give details... <ng0>the best bug reports... <ng0>at least try to let us analyze and fix it :/ <ng0>60 days are enough to move a font from one url to another, I think.. i have initiated a renaming of my sdf.org account, where guix currently pulls one font from due to upstream being broken and not responding.