IRC channel logs


back to list of logs

<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`
<kyamashita>bavier: Thanks.
<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
<davexunit>jlicht: it's fine
<davexunit>we have that luxury in guix, after all.
<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>yeah :/
<Steap>this is so crazy
<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>and everything is broken
<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 to run because it can't link to libgcc_s.o.1
<katco>readelf --dynamic ./go
<katco>Dynamic section at offset 0x6710e0 contains 20 entries:
<katco> Tag Type Name/Value
<katco> 0x0000000000000001 (NEEDED) Shared library: []
<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: I'm working on the icecat update now
<efraim>mark_weaver: good to know :)
<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.
<mark_weaver>it should probably be a graft, though
<mark_weaver>too many dependent packages
<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
<robsyme>s can create?
<robsyme>Actually, lookin closer it looks like only two threads are created (in a loop that runs 5000 times):
<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.
<robsyme>iyzsong: Yes, I do!
<iyzsong>see, I think you can try set "TasksMax=infinity" for guix-daemon.service.
<robsyme>iyzsong: It works! Thanks :)
<iyzsong>cool :-)
<rekado>sneek: later tell civodul Ah, I didn't think of duplication. I was only working on http-client.scm.
<sneek>Will do.
<civodul>Hello Guix!
<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.
<robsyme>Hi all (again)
<civodul>anyone interested in giving "patches" a try?
<civodul>this thing:
<cbaines>What is involved in trying it?
<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
<civodul>so we'd need to see why
<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>civodul: There it is!
<civodul>good :-)
<robsyme>In which file would people here recommend I redefine $PATH to include ~/.guix-profile/bin?
<robsyme>The manual suggests that it should go in ~/.bash_profile:
<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.
<robsyme>(in ~/.bashrc)
***_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
<robsyme>oh, I see.
<davexunit>the Guix manual has a note specifically about this situatiin
<robsyme>one sec, got to logout/login.
<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
<cehteh>didnt they stop that?
<rain1>yeah after they got caught
<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>Guix is wonderful!
<civodul>rain1: i think SF did that several times actually
<civodul>SOURCE_DATE_EPOCH in GCC:;a=commitdiff;h=e3e8c48c4a494d9da741c1c8ea6c4c0b7c4ff934 \\o/
<rain1>that's great
***kratbdfhngl is now known as pmal
***pmal is now known as melfice
<civodul>the recently-introduced multiple-output support in Nixpkgs is fairly aggressive, more than what we do:
<civodul>(a bit too much perhaps, but still)
<civodul>the special "dev" output propagates all other outputs of a package
<civodul>which is pretty clever
<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)
<rain1>there is a package for it
<civodul>rain1: nice, submit it! :-)
<civodul>rain1: note that suggests recordmydesktop
<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 :)
<rain1>that's good!
<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?
<civodul>for this particular case, at least
<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>I'm almost there, and...
<Steap>basically I try to build python2-barbicanclient
<Steap>it fails while building python2-unittest2
<Steap>but I can build python2-unittest2
<Steap>so I'm puzzled
<Steap>Am I misreading the logs ?
<rekado>Steap: but why would it rebuild python2-unittest2 if you had already built it successfully?
<Steap>rekado: I don't know
<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
<davexunit>we'd certainly like a step-by-step guide
<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?
<davexunit>this is the only one you need:
<yoosty>ty ty
<ng0>the url can be shorter iirc: origin git:// (fetch)
<ng0>and even this has a shorter one iirc
<ng0> 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?
<ng0>ACTION is afk
<rain1>please could someone tel me the output of which env ?
<rain1>on any guixsd system
<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>ok thanks!
<rain1>could you tel me readlink of it too?
<rain1>i wanted to know the /gnu/store one to
<slim404>it's ugly but it worked
<jchmrt>rain1: /gnu/store/34j2zmi69mqwrslpyizbi9mcxmn2hzgb-coreutils-8.24/bin/env
<slim404>here's what I did to my config.scm script
<rain1>thanks so much jchmrt!
<jchmrt>no problem :)
<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)
<slim404>I know
<slim404>I'll find a better way
<rain1> /win 15
<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>ngz: is your source tarball a tarbomb (
<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>kyamashita: yeah that sounds good
<davexunit>I imagine packaging android stuff is a real challenge
<kyamashita>Check out
<davexunit>kyamashita: wow, simpler than I thought! suspiciously so...
<davexunit>keep your eye out for pre-built binaries
<davexunit>but if that's all it takes, that is awesome.
<davexunit>I'd like to have the android tools
<kyamashita>FreeBSD pulls tarballs from a github mirror. I think I'll use those as opposed to a git checkout.
<davexunit>kyamashita: that would be best, yeah.
<davexunit>tarballs are always preferable to VCS checkouts
<phant0mas>janneke: changes to cross-gcc should not cause rebuilds of parts in commencement :-)
<phant0mas>gcc-boot0 inherits from gcc not cross-gcc]
<phant0mas>I just saw your email :P
<janneke>phant0mas: ah thanks
<phant0mas>is this a suggestion for the guix manual?
<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>I just wanted to understand the context
<phant0mas>about gcc-boot0
<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>I see
<phant0mas>well you are right we need to explain it somewhere for future references
<phant0mas>because they are really confusing
<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
<davexunit>I use that
<janneke>kyamashita: that's because of name clashes
<ajgrf>ok, thank you
<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 :-)
<kyamashita>Oh my. Google, why you no have Makefile?
<random-nick>pretty sure the java ecosystem doesn't use make
<janneke>if you can learn make, you might as well learn a real programming language ;-)
<phant0mas>janneke: will do :-)
<phant0mas>btw have you used the guix graph command?
<phant0mas>this is what I use to understand the dependency trees
<janneke>phant0mas: great, thanks
<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"
<janneke>civodul: ah, thanks...
<janneke>ACTION -> zZss