IRC channel logs


back to list of 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>you'll have to ask civodul what the plan is for that.
<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?
<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>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,
<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.
<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>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 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.
<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'
<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>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 :)