IRC channel logs

<davexunit>is sudo packaged?

<davexunit>there is no package named sudo. is it part of another package?

<mark_weaver>I'd guess that we don't have it.

<davexunit>mark_weaver: yeah seems so. I just wasn't sure because sometimes many programs are rolled into one tarball like coreutils.

<davexunit>well, now I know what to work on. :)

<mark_weaver>one issue is that the guix builder can't install setuid binaries. I don't know what the plan is for that.

<davexunit>sudo's configure script checks for the presence of programs like mv, bash, vi, and sendmail. it has hardcoded a set of possible paths. in the case of mv, the paths it checks are "/usr/bin/mv" "/bin/mv" "/usr/ucb/mv" "/usr/sbin/mv"

<davexunit>when mv is found, _PATH_MV is defined. mv is not found when I build when I include coreutils as an input.

<davexunit>and the build fails because of the undefined _PATH_MV

<davexunit>should one of those paths work at all when building? do I need to patch the configure script somehow?

<mark_weaver>typically that's solved by adding a phase that uses 'substitute*' to replace those paths with the corresponding exact paths.

<davexunit>okay, I will look for examples of that.

<mark_weaver>search for 'patch-/bin/sh in scheme.scm for example

<mark_weaver>the substitute* macro can accept multiple things to search for, so you can do all the replacements with one substitute* use.

<mark_weaver>but I wonder, did you see my comment before?

<mark_weaver>"one issue is that the guix builder can't install setuid binaries. I don't know what the plan is for that."

<davexunit>mark_weaver: I missed that. my x server crashed.

<davexunit>and I lost my emacs that had my IRC session.

<mark_weaver>okay

<mark_weaver>you'll have to ask civodul what the plan is for that.

<davexunit>okay.

<davexunit>thanks for repeating.

<mark_weaver>I suppose for now you could make the package and then copy the actual 'sudo' binary into a private ~/bin and give it setuid perms there.

<davexunit>okay. I'll ask civodul about this sometime. thanks for the help!

<davexunit>I'll add sudo to the list of packages that I can't quite package.

<davexunit>going to go to sleep. ttyl.

<mark_weaver>okay, good night!

<phant0mas>good morning guix

<davexunit>good morning #guix.

<davexunit>when I try to source a file from my bash shell, it tells me that lesspipe is not found.

<davexunit>is this _the_ lesspipe? http://www-zeuthen.desy.de/~friebel/unix/lesspipe.html

<davexunit>it seems that debian maintains their own lesspipe script.

<davexunit>it's odd that bash relies on lesspipe when its not even distributed with less.

<davexunit>false alarm, the problem was with my .bashrc that has a bunch of debian stuff in it.

<phant0mas>Could someone explain what is the use of the flag --log-file?

<phant0mas>when I add it to my guix build command , it just prints a path

<mark_weaver>did you try looking at the file of the path it printed?

<phant0mas>yes

<phant0mas>it's a compressed file

<davexunit>how does one go about removing a configure flag from a build process?

<mark_weaver>did you try looking at the uncompressed contents? did you read what it says in "guix build --help" ?

<mark_weaver>it's a log of the build process

<mark_weaver>davexunit: normally, if you have to remove a flag that would be added automatically, it indicates that it's a custom configure script, and you probably need to replace the configure phase with a new one.

<davexunit>mark_weaver: gotcha, thans,

<davexunit>thanks*

<mark_weaver>np!

<phant0mas>mark_weaver: I have read the --help output, and yes I checked the contents , it contains only the phase till the patching

<phant0mas>I just thought it would have all the building output

<zacts>lo #guix

<phant0mas>that's why I am confused

<mark_weaver>phant0mas: it would have all of it if the build continued to completion. I guess the build was aborted

<phant0mas>but why? normally without the flag it goes on as expected

<mark_weaver>or perhaps this was the build for an origin (source).

<mark_weaver>I don't know why it would have aborted.

<phant0mas>okay, till I figure out what's wrong I will just redirect the output to a file

<mark_weaver>phant0mas: I should mention another possibility: if you look at the log for a build that's currently in progress, there will usually output that has not yet been written to the file, because it's compressed with bz2 which is a block compressor.

<mark_weaver>*usually be

*mark_weaver goes afk again

<davexunit>I am working on a package whose makefile has no install rule.

<davexunit>all there is to install is one executable file in the bin directory, but I haven't been able to figure out how to do it correctly.

<davexunit>I've replaced the install phase with my own.

<mark_weaver>davexunit: so the phase should start with (lambda* (#:key outputs #:allow-other-keys)

<davexunit>but I can't determine the correct installation path. I tried using what was in (assoc-ref outputs "out") but I'm not able to install to that directory.

<mark_weaver>and then you get the output directory with (associ-ref outputs "out")

<davexunit>mark_weaver: I have that much.

<mark_weaver>and then (mkdir out)

<davexunit>that's it!

<mark_weaver>(mkdir (string-append out "/bin"))

<davexunit>I didn't know that the directory didn't exist yet.

<mark_weaver>then copy-file, etc.

<mark_weaver>okay, happy hacking!

<davexunit>thanks yet again.

<mark_weaver>np!

<davexunit>I knew it had to be something simple.

<davexunit>bam. I have a working dtach package now.

<davexunit>do we not have the 'man' program packaged?

<mark_weaver>that's correct. crazy, huh?

<mark_weaver>I just use "M-x woman" in emacs

<mark_weaver>but yeah, it would be good to have man :)

<davexunit>mark_weaver: I will go package it, then. I have been working on packaging notmuch and the test suite invokes man for a few tests.

<mark_weaver>we're also missing a bunch of man pages.

<mark_weaver>oh, nice! I packaged most of the prerequisites for notmuch, but then got distracted. I'll be glad if you finish up that work :)

<davexunit>I packaged talloc and I just finished dtach which is needed for the test suite.

<davexunit>notmuch builds without error but has problems in the test suite.

<davexunit>one problem is the lack of man, and it also seems to timeout on a json test.

<mark_weaver>I wonder if it's trying to access the network

<davexunit>maybe, need to dig into it more.

<civodul>Hello Guix!

<mark_weaver>hi civodul!

<davexunit>hey!

<davexunit>would it be okay to put a library package in the same module as the package that uses the library? I don't think it's used by much else.

<davexunit>in this case, libpipeline was written by a man-db maintainer for man-db.

<mark_weaver>sounds reasonable to me

<civodul>same for me

<civodul>there are a few precedents

<Steap>civodul: should I do the Python patch for core-updates or for master ?

<davexunit>where do I look for my failed builds? /gnu/store? I started guix-daemon with the --cache-failures flag but I can't find the cache.

<davexunit>I find a .drv file corresponding to the failed build, but I'm looking for a directory where I can find the generated log files.

<civodul>Steap: core-updates is no more, so for master :-)

<civodul>davexunit: --cache-failures just means that it won't attempt to rebuild something known to fail

<civodul>those failures are stored in the sqlite db

<davexunit>civodul: oh okay, I misread then. there's a test suite log file that I need to see to debug my package recipe.

<mark_weaver>davexunit: build it with "guix build -K <foo>" and then it will be left in /tmp/nix-build-*

<davexunit>I should've looked at the guix build switches. I just assumed it was something that the daemon controlled. thanks.

<mark_weaver>civodul: speaking of cached failures, I get the impression that hydra.gnu.org is caching failures that were transient network problems, or something. for whatever reason, there are hundreds of packages not being built, despite the fact that I attempted a build of the newest version of every package we have on my x86_64, and only a small number failed.

<Steap>civodul: oh, we never do two merges of core-updates ?

<mark_weaver>hydra really seems quite broken right now.

<phant0mas>civodul: if I use the --log-file flag, it writes to the log file only the output till the patching phase and then it stops the building of the package

<phant0mas>while if I don't it goes one normally

<civodul>mark_weaver: yes, many transient failures showing up there, some due to bugs in the offload hook

<civodul>mark_weaver: though some of the packages marked as failed in the UI are actually available on hydra because they've been built in the meantime

<civodul>so yeah, dirty situation

<civodul>phant0mas: no, everything goes to the log file

<civodul>Steap: "two merges"?

<mark_weaver>phant0mas: pass the --log-file flag to what?

<phant0mas>to the guix build command

<phant0mas>as the manual says to do

<mark_weaver>phant0mas: when you pass --log-file, it doesn't do a build at all. it just shows you where to find the log of a previously-done build.

<civodul>ah yes, right

<mark_weaver>builds are always logged. you don't have to ask for logging.

<mark_weaver>I'm actually in the habit of doing: ls -ltr /var/log/guix/drvs/*/* | tail -30

<mark_weaver>so see the most recent build logs

<phant0mas>ah now I get , nice it's all there

<phant0mas>oh god it's 699 logs...

<davexunit>so I'm trying to get the man-db test suite to pass.

<davexunit>some of the tests generate a script called "fake-program"

<davexunit>but the tests output errors like: /tmp/nix-build-man-db-2.6.6.drv-0/man-db-2.6.6/src/.libs/man: can't execute fake-program: No such file or directory

<civodul>davexunit: that's because of its shebang, i bet :-)

<davexunit>the tests make a temp directory, create the fake-program script within it, and then modify the PATH.

<davexunit>civodul: that's my suspicion, too. but I'm having a hard time replacing it.

<civodul>you'll have to patch the thing that creates fake-program, i guess

<davexunit>if I can just replace "#! /bin/sh" with the right path I might be all set.

<civodul>yes

<davexunit>call out to system* to run sed? or is there a better way? patch-shebang is quite complicated and I don't think I need that level of complexity.

<civodul>rather (substitute* "the-file-that-builds-fake-program" (("#!/bin/sh") (string-append "#!" (which "sh"))))

<civodul>better than sed ;-)

<davexunit>civodul: much better, thanks.

<davexunit>today is the first time I've had to add/replace build phases.

<civodul>heh :-)

<davexunit>okay, that got me past a few failures, but not as many as I had hoped.

<davexunit>/tmp/nix-build-man-db-2.6.6.drv-1/man-db-2.6.6/src/.libs/mandb: the setuid man user "man" does not exist

<mark_weaver>yeah, so there's a cache of rendered man pages, and normally man is setuid to allow a single system-wide cache.

<mark_weaver>or at least that's how I remember it

<mark_weaver>probably it should be changed to put the cache in a per-user directory.

<mark_weaver>or maybe the cache can simply be disabled. it's probably less important nowadays. computers are a lot faster now.

<mark_weaver>man, I've probably built on the order of 20 kernels for this Loongson 3A machine, and exactly one of them has ever worked.

<mark_weaver>and unfortunately, that one kernel has DEVPTS_MULTIPLE_INSTANCES disabled

<mark_weaver>and I'

<civodul>heh

<civodul>g'night!

<davexunit>mark_weaver: thanks for that explanation. I used the configure flag --disable-setuid and the test suite passed.

<davexunit>I guess that will do for now.

<mark_weaver>cool!

<mark_weaver>sounds simpler than I expected

<mark_weaver>thanks for doing multiple things that were on my TODO list. so nice to be able to cross those off without doing any work myself :)

IRC channel logs

2014-04-06.log