<kyamashita>How do I check the build log for a package I built in my copy of the guix tree? <bavier>kyamashita: `guix build --log-file foo` <yoosty>janneke: Thanks for the gnome-tweak-tool patch! Will try it later.. <kyamashita>Has anyone gotten the Tor Browser Bundle working on their GuixSD installation? <jlicht>Good {evening,morning,afternoon} guix! I was wondering what the policy is for having multiple version of (guix import'ed) packages definitions in guix <jlicht>davexunit: good, good. I already saw a few packages like this, but was not sure wether this was something to be avoided or not :-) <Steap>jlicht: it's best not to have N versions of the same package though <Steap>but sometimes it is necessary to bootstrap some packages <jlicht>Steap: of course, but I was mostly looking at bootstrapping a set of packages. <Steap>I've been trying to package a single python library all day <Steap>I've got a sheet of paper with a drawn graph of billions of dependencies <Steap>To think people do that with broken distros <efraim>packaging python programs often leaves me working hard with setting commits in git as fixup or squash <efraim>there's also that firefox CVE set to take care of in icecat, I might look at that instead of gcc <katco>efraim: hey ty for the help earlier <katco>so i'm trying to understand how guix does dynamic linking. i read somewhere it tweaks the rpath? i currently have a package that builds a binary, but it can't find libgcc... is there an example package i could look at to figure out how to point it to guix's libgcc correctly? <efraim>katco: np :) I can never remember if its ,gcc "lib" or ,gcc:lib <katco>efraim: i found out that gnu-build-system automatically passes in the gcc folder, so i was able to use that <efraim>libgcc_s is in gcc.scm, which is what needs to be played with for go and gccgo to work <efraim>I haven't managed to work my way through it yet <katco>efraim: are you working on a go package? <efraim>I have one that builds but it doesn't actually work <katco>efraim: ha! me too. the binaries are there, but i can't get run.sh to run because it can't link to libgcc_s.o.1 <katco>Dynamic section at offset 0x6710e0 contains 20 entries: <katco> 0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1] <efraim>I got around that by passing (setenv "CGO_ENABLED" "0") <efraim>which is also what makes it not work <katco>efraim: i was trying: (setenv "LDFLAGS" (format #f "-Wl,-rpath=~a/lib/libgcc,--enable-new-dtags" libgcc-path)) <katco>but that doesn't seem to work <mark_weaver>efraim: if you're looking for something to do, I think we should update our poppler <mark_weaver>there are apparently security issues with our current poppler. <lfam>Apparently the bug is present in poppler < 0.40.0, so hopefully it should be enough to update to the current stable version (0.42.0) <katco>efraim: fyi, CGO_ENABLE=0 gets me a workable go binary, but tests are failing because they're attempting to introspect the filesystem that's jailed <Steap>it is such a pain to package A which requires B@X, when B requires C, and C is packaged in a version != X <Steap>seems like we somehow end up with two versions in the profile <lfam>B and C have to be the same versions? <lfam>Two versions of what in the profile? <robsyme>Hi all. I'm getting failures in the 'test' step when building ruby. Specifically, 'test_thread.rb' includes a step that spins up 5000 threads. My guix builder processes fail with "can't create Thread: Resource temporarily unavailable (ThreadError)". The output of `cat /proc/sys/kernel/threads-max` is 62692, which should be more than enough. Does anybody know if there is a limit on how many processes the guix-builder <iyzsong>robsyme: do you use systemd to start the guix-daemon? I see some discuss about it in guix-devel where the number of processes is limited by systemd. <rekado>sneek: later tell civodul Ah, I didn't think of duplication. I was only working on http-client.scm. <sneek>civodul, you have 1 message. <sneek>civodul, rekado says: Ah, I didn't think of duplication. I was only working on http-client.scm. <civodul>anyone interested in giving "patches" a try? <civodul>just run the commands in that message <civodul>and then try to see how well it works etc. <civodul>sometimes it seems to get the status of some patches wrong <cbaines>The commands in the message seem to work fine, I'm just reading the README now <civodul>i've just sent an update to that message :-) <cbaines>"status:unapplied" does not work for me "Exception: Unknown status `unapplied'" <cbaines>Interestingly, status:broken gives some results <civodul>the latest version of "patches" that i committed yesterday has status:unapplied <robsyme>civodul: I don't see the patch I submitted earlier this morning. I probably messed up the formatting somehow. <civodul>robsyme: no, it's just that i haven't setup a crontab entry to update the database :-) <civodul>if you refetch now it *should* be there <robsyme>In which file would people here recommend I redefine $PATH to include ~/.guix-profile/bin? <robsyme>so that `guix environment` subshells have a clean environment. The problem is then that no terminal I open has my guix profile in $PATH. <robsyme>My thinking is that I should add ~/.guix-profile/bin to $PATH if $GUIX_ENVIRONMENT is unset. ***_hubertus84_ is now known as _hubertus_
<rekado>I only do this in ~/.bash_profile and I have it in my PATH in new terminals. <robsyme>rekado: So you have ~/.guix-profile/bin in $PATH in your guix environment subshells? <rekado>with "guix environment --pure ..." I don't. With "guix environment --ad-hoc hello" I do as the environment's bin directory is just prepended to the PATH. <davexunit>robsyme: set env vars in .bash_profile, not .bashrc <davexunit>.bashrc is for nonlogin shells so you should be careful not to clobber env vars there <robsyme>davexunit: I don't think my terminal emulator (gnome-terminal) is a login shell, so it wouldn't read .bash_profile, so I'd never see the variables set there. <davexunit>robsyme: it's sourced on login to your desktop <davexunit>the Guix manual has a note specifically about this situatiin <robsyme>davexunit: I think that gdm sources ~/.profile instead, so sourcing ~/.bash_profile from ~/.profile works a charm. <rain1>this is the email if you want to help out by informing them about sourceforge inserting malware into programs <rain1>they are 'sorry' and 'wont do it again' <rain1>the public still deserve to know about their abuses <rain1>If you agree GNU should not cover up for attacks on innocent peoples computer then please feel free to send an email asking them to list this information <cehteh> /. changed ownership .. didnt sf too? i meant it would be bad to blame a new owner for things the previous owner have done <cehteh>(i am still very sceptic on centralized hosting sites and dont like them much, but it should be fair) <rain1>sure if you feel this information should be buried/forgotten that is fine but I strongly disagree <rain1>imo it is swings and roundabouts - nobody is responsible for anything because they can just put on a different mask <cehteh>not forgotten but dont point the finger at SF., rather generalize that *any* such service can tamper with your tarballs when you dont secure that cryptographically <cehteh>possibly even then, because its often hard to build a trust chain <rain1>I completely agree that we should secure these things cryptographically <rain1>that's one wonderful aspect of guix! <civodul>rain1: i think SF did that several times actually ***kratbdfhngl is now known as pmal
***pmal is now known as melfice
<civodul>the special "dev" output propagates all other outputs of a package <rain1>civodul: In thread Call for screencasts! <rain1>it doesn't say what program to use to do it <rain1>there might be a few programs but it can be done with simplescreenrecorder <rain1>(if that makes it easier for people to create them) <bavier>civodul: I was thinking the other day that a file pattern might be a nice way to declare what goes into an output, rather than having to move things manually <rain1>oh okay recordmydesktop, i have'nt seen it :) <bavier>e.g. (outputs '(("doc" "share/man") "out")) <civodul>bavier: the 'configure' phase in gnu-build-system.scm tries to guess the right things, though in some cases that's not enough <civodul>but we should do the same in other build systems <bavier>civodul: right, it would be for packages that are less well-behaved <civodul>perhaps the validate-documentation-location phase could do that? <bavier>sure, if there's a "doc" output, make sure there's nothing obviously documentation in "out" <civodul>though currently, "doc" is only for --docdir, not for --mandir, which is usually a good idea <civodul>because --docdir is for heavy HTML/PDF stuff, whereas man pages are usually much smaller and more widely useful <Steap>I'm tryign to package tons of stuff <Steap>basically I try to build python2-barbicanclient <Steap>it fails while building python2-unittest2 <Steap>but I can build python2-unittest2 <rekado>Steap: but why would it rebuild python2-unittest2 if you had already built it successfully? <Steap>I think I kind of got things working somehow <Steap>but I've spend too much time debugging Python craziness lately, I'm tired :D <yoosty>is there a step-by-step guide in getting from point "Yay I installed GuixSD!" to "Yay I've edited something from the Git repo, run a test on my system, and am ready to submit a patch!" <yoosty>I've gone from "Yay I've installed GuixSD!" to "I've installed a few packages and reconfigured my system a few times" but would like some more hints as to where to go next <davexunit>yoosty: there's no step-by-step walkthrough at this time, but the "contributing" section of the manual should help you get started. <yoosty>more than willing to take just a few comments (e.g. Normally one would do the following 1: ... 2: .. 3:..) and expand on it <yoosty>kk, I'll attempt it but I'll be bugging everyone here while I stumble through the process :-D <yoosty>dumb question #1: Is there a list of Git repos? <ng0>the url can be shorter iirc: origin git://git.sv.gnu.org/guix.git (fetch) <ng0>and even this has a shorter one iirc <ng0>g.s.gnu.org or something? <rain1>I was just curious why not have /usr/bin/env? <ng0>is the website of guix all that is in the repository, or is there static data which lives outside of it? <rain1>please could someone tel me the output of which env ? <rain1>I don't have access to guix at the moment <paroneayea>sorry I've been less present in guix stuff lately! <paroneayea>busy getting 8sync to a usable point has been my main priority <jchmrt>rain1: for me which env returns: /run/current-system/profile/bin/env <slim404>I finally managed to get slim display manager to work with my french keyboard in guix sd <rain1>could you tel me readlink of it too? <rain1>i wanted to know the /gnu/store one to <jchmrt>rain1: /gnu/store/34j2zmi69mqwrslpyizbi9mcxmn2hzgb-coreutils-8.24/bin/env <slim404>here's what I did to my config.scm script <slim404>in the (service) declaration : I added (slim-service #:startx (xorg-start-command #:configuration-file (xorg-configuration-file #:extra-config '("Section \\"InputClass\\"\\nIdentifier \\"system-keyboard\\"\\nOption \\"XkbLayout\\" \\"fr\\"\\nEndSection\\n")))) <slim404>and changed %desktop-services to (cdr %desktop-services) <ngz>Hello. While writing a package, I noticed that unpack phase (from cmake, but I guess this one is inherited from gnu) leaves me in a subdirectory instead of the root directory of the source. Is it intentional? <ngz>It seems dubious, because I have add a new phase right after 'unpack so as to (chdir ".."). <ajgrf>basically, no that shouldn't normally happen <ajgrf>but i could see how it could happen if your source doesn't extract everything into a neat directory like most packages <ngz>Ah, you're correct, this is a tarbomb <ajgrf>you can use url-fetch/tarbomb instead of url-fetch <ngz>ajgrf: Much better. Thank you. <kyamashita>If I was to package adb for Guix, would it be better to create a separate android.scm file for the necessary packages that don't fit into another category (like adb)? <davexunit>I imagine packaging android stuff is a real challenge <davexunit>kyamashita: wow, simpler than I thought! suspiciously so... <davexunit>but if that's all it takes, that is awesome. <kyamashita>FreeBSD pulls tarballs from a github mirror. I think I'll use those as opposed to a git checkout. <davexunit>tarballs are always preferable to VCS checkouts <phant0mas>janneke: changes to cross-gcc should not cause rebuilds of parts in commencement :-) <janneke>hmm, are you sure? the Bootstrapping chapter says a linux->linux compiler is used in the process <janneke>i should test it, though -- i've seen quite some rebuilds <janneke>yes, wingo suggested to make a write-up with mingw details somewhere <janneke>why not add it to the doc or contributors guide? <janneke>as it turns out, i don't think much mingw-specific things are to be told? <phant0mas>no, no don't take my question wrong, it's a nice idea :-) <phant0mas>which is the first psudo cross-compiler build in the native system <janneke>yes, i'm reading commencement now, cross-base seems unrelated...hmm <phant0mas>I don't see any any references to cross-base inside there <janneke>i'm wondering now what triggers all the world rebuilds, with 4 compilers and several glibc's, possibly just ncurses ;-) <phant0mas>commencement uses the bootstrap-inputs, which contain the cross-build toolchain, to create a fully independent final native toolchain to be used on the system <phant0mas>by cross-built I mean the bootstrap-tarballs <janneke>about context, aiui it's especially all those pesky details we discovered/fixed, like CPATH/C_INCLUDE_PATH/CROSS_C_INCLUDE_PATH; etc that triggered the need for a write-up <phant0mas>well you are right we need to explain it somewhere for future references <kyamashita>I notice that some package files use a "license:" prefix and others do not. Is there a convention that I'm missing? <janneke>yes, now it's fresh in memory, details will fade soon <ajgrf>davexunit: i've seen you comment several times that you use shepherd as an unprivileged user, but how do you start shepherd when you log in? <davexunit>ajgrf: desktop environments have some autostart mechanism <janneke>kyamashita: that's because of name clashes <janneke>eg, there's a zlib license and a zlib package, iirc <kyamashita>janneke: Okay. So do I leave it out when possible? <janneke>kyamashita: yes, until we have a policy you can probably choose what to do <janneke>phant0mas: anyway, every addition/removal/correction/full rewrite you can offer to what i mailed is much appreciated :-) <janneke>if you can learn make, you might as well learn a real programming language ;-) <phant0mas>this is what I use to understand the dependency trees <janneke>just looking at guix graph, but i don't see how i can extract info about, say, the impact of changing ncurses <janneke>with dotty i only see many many many arrows on non-scalable window that's about 10 times the size of my screen <civodul>janneke: try "guix refresh -l ncurses"