<lfam>kristofer: No, but there are examples of how to use it in a package definition in gnu/packages <lfam>For example, in tesseract-ocr <lfam>You might also need to run autoreconf, of which there are also examples <kristofer>lfam, the tesseract-ocr example is perfect, thank you <kristofer>weird question, but how might I skip the configure part of the build phase? <kristofer>I'm getting "no binary for 'python' found in $PATH" -- I have (native-inputs `("python" ,python)), is there something else I should be doing? <kristofer>got that problem sorted out, missing parenthesis. ***calher is now known as redstarnoochcomr
***redstarnoochcomr is now known as calher
<kristofer>are there any examples of downloading a library and unpacking it inline after the 'unpack phase, but before the configure phase? <rekado>kristofer: the icedtea packages in java.scm download additional sources and unpack them before configuring or building. <rekado>the sources are added as inputs, as plain "origin" values. <efraim>I forgot to check what time I started building qtbase, but I'm sure I passed the 1hr mark where it failed last time ***bmpvieira_ is now known as bmpvieira
***mattl__ is now known as mattl
<GNUtoo-irssi>"/gnu/store/hg3692jqq4jmhg4qx8d7y67fspimy898-?id=3ba68f9e64fa2eb8af22d510437a0c6441feb5e0" <kristofer>rekado, ty! that's exactly what I'm looking for <kristofer>GNUtoo-irssi, those are unique hashes of specific builds <kristofer>GNUtoo-irssi, did you use the configuration flag --fallback? <GNUtoo-irssi>guix pull --fallback => guix pull: error: fallback: unrecognized option <efraim>if `guix pull --fallback' doesn't work you could try `guix build hello --fallback' and see if that works <GNUtoo-irssi>efraim: it should work, but I've no idea what to do after it: <GNUtoo-irssi>At the end of the day I want to use the binaries and not build everything from scratch <GNUtoo-irssi>And changing laptop is not an option yet, it would require lot of work to have the same level of freedom, privacy, and security <efraim>i'm still trying to figure out why when you have substitutes enabled it's still trying to get you to build it <GNUtoo-irssi>efraim: Am I the only one having similar issues? are there known users of guix in parabola that have or don't have such issue? <efraim>files do get garbage-collected due to limited storage <efraim>I just set up guix on debian on another machine and when I first ran guix pull it pulled down tar and 2 or 3 other programs <efraim>`which guix' shows /usr/local/bin/guix ? <efraim>does it do the same thing if you run `sudo guix pull'? <koosha>How long do you think will take to port Hurd for guixsd ? <efraim>there's a GSoC project to continue the work this year <efraim>I believe there was an issue with properly isolating the build environment that still needs to get worked out <roelj>Is it possible to get the store path for a package definition with Scheme code only? ***mv is now known as marxistvegan
<rekado>roelj: do you mean the path of the package output or the location of the package expression in the Guix source code? <roelj>rekado: The path of the package output. <rekado>roelj: have you tried the "package-file" procedure yet? <roelj>rekado: No, but I'm trying it right away <roelj>(define my-path (package-file bash "/bin/bash")) <iyzsong>roelj: yes, it's a store-monaded procedure. you can use '((package-file glib) (open-connection))' or run-with-store and friends, etc. <rekado>efraim: I noticed that too. I'm on it. <rekado>I'm only held back by a broken Guix... <rekado>I don't understand. I ran "make clean", reconfigured, and reran "make" in a recent guix checkout. <rekado>but I always get this error: substitute: guix/ui.scm:1197:6: In procedure #<procedure tls-wrap (port server)>: Unbound variable: make-session <rekado>doesn't "guix environment --pure guix" provide gnutls? <roelj>iyzsong: Thanks! It took some time to look at the source code for these and related functions, but I start to understand how it works. <roelj>iyzsong: And I now got it working. Great! <rekado>replacing the guile shebang in scripts/guix with the path to the system guile fixed it. <davexunit_>"There is a dependency conflict, but the solver could not determine the precise cause in the time allotted." <roelj>Which package manager produces that? <davexunit_>roelj: Berkshelf, a package manager for Chef, which is a configuration management system. <roelj>Cool. Another package manager I had never heard of. <davexunit_>I'm in dependency hell right now. there's a problem *somewhere* but it's impossible to track down <roelj>So I figured from the error message :) <davexunit_>and I can get the system to produce different results with ease <davexunit_>like, commenting out all of the dependencies and uncommenting in different orders, running 'berks install' in between, produces different results. <davexunit_>I've actually managed to make one Chef cookbook stop complaining about dependency issues <roelj>Doesn't sound like a desirable "feature" <davexunit_>when I move on to another cookbook that uses the previous cookbook, the problem happens again. <davexunit_>by commenting out the problematic cookbook, running 'berks install', uncommenting it, and running 'berks install' again ***orbea_ is now known as orbea
***calher is now known as Emacsite
<lfam>I'm trying graft expat, but it still wants to rebuild everything <lfam>"could conceivably result in remote code execution." <efraim>lfam: did you also grab the updated patch for cve-2015-1283? <lfam>efraim: There is an updated version of that patch? <efraim>according to debian the original patch wasn't as effective as it could've been so they have an updated one <lfam>Can you point me to it? I'm having trouble navigating the other distros' sites <lfam>For some reason Debian's git repos are offline so I can't see their changes. That's usually where I look for these sorts of things <efraim>i'll grab the link for the expat page in a sec <lfam>Okay, thanks. Either way, that shouldn't affect the efficacy of the graft, right? <lfam>Is there another expat variable besides the one in xml.scm? <ifur>im getting a corrupt object when trying to pull the git repo, and guix pull complains about guix/build/pull.scm missing <efraim>lfam: I think that's the only one, for grafting it shouldn't matter what we replace it with, in most terms <lfam>efraim: That's what I thought. I don't understand what's going on. I tried to build ncmpc, and it starts by rebuilding perl... <efraim>maybe expat is part of building the base? didn't think it was <lfam>So, that's basically the whole distro <lfam>efraim: Yes, I just downloaded it <efraim>inside debian/patches/ is the old cve-2015 patch, the new one and the 2016 patch <lfam>I wish they would consider that not everybody is part of their secret club, and thus we haven't been talking about this issue since December. They should publicly state the origin of the patch on oss-sec <lfam>I'm sure everyone on the pre-disclosure mailing list knows how that patch was made, but the rest of us are scratching our heads <lfam>Well, the Debian version is superior because it doesn't require 'patch -p2' <lfam>No difference in actual code <efraim>the refix patch wouldn't apply cleanly for me, 2/2 hunks failed <efraim>when I applied all 3 they applied <bavier>I was able to (finally) get lsh setup between my host and build/offload machine, but offloading still doesn't work because "cat" is not available during in the non-interactive shell <lfam>I'm working on applying all 3 here as well <bavier>are hydra's offload machines not running GuixSD? <lfam>bavier: At least the non-Intel compatible machines must be running something else <efraim>i asked it to build pinentry-tty and now i'm building pcre <lfam>I don't think that should happen... <efraim>it should just build expat and then graft everything <lfam>There is something we don't understand about how expat gets used... <efraim>time to break out the guix graph options! <lfam>I also can't figure out how to add the two new patches while referring to (origin-patches) in the new variable. But that's a minor issue, it works when I copy the old patch into the new variable <lfam>efraim: I'm a moron. The problem is that I tried to remove the old patch from the old expat variable. Of course changing that variable would break the advantages of grafting <lfam>The grafting works as expected when I *don't* mess with the current variable. And, the CVE-2016 patch does apply to 2.1.0 when I don't try to remove the old CVE-2015 patch <lfam>Not sure what I was thinking... <lfam>Do we care about DOS line endings in patch files? <lfam>And we still should figure out the source of the CVE-2016-0718 patch... <janneke>lfam: thanks for helping to get gnome-tweak-tool in! <lfam>janneke: Thanks for working on it, and sorry it took so long :) <lfam>efraim: Updated patch sent to guix-devel <efraim>lfam: your patch looks exactly like what I have, except I didn't rename the patches yet <lfam>efraim: Good! I found the "re-fix CVE-2015-1283" patch in the upstream git repo, so I regenerated that patch and am commenting it now <lfam>Well, that upstream commit doesn't apply. I guess we'll use Debian's version of the patch... <efraim>expat 2.1.1 came out 2? months ago, they might have their patch against that <lfam>Yeah, who knows. It looks like it was merged into master from their "fix CVE-2016-0718" branch ***frafra_ is now known as frafra
<lfam>It looks like Debian maintains their expat packaging in an SVN repo, and the HTTP interface to that repo is offline. I like to include a link to the source of a patch, but I guess it's not possible in this case <ifur>efraim: so no one around that can fix the corruption in the git repo? <lfam>What's up with that? I can build from the git repo. <lfam>But I get the same error with `guix pull` <lfam>The tarball fetched by `guix pull` is smaller than usual (8.7MiB instead of ~10MiB) <davexunit>lfam: perhaps an issue with cgit on savannah? <lfam>I just dl-ed it with curl, inspecting <lfam>The tarball does not contain the 'guix/' directory. Is that expected? <lfam>My understanding is that the tarball should be the full repo, minus the .git directory <lfam>What is the best way to contact the sysadmin's responsible for Savannah? <lfam>Is that really the best way? It has seemed like a black hole in the past <davexunit>ACTION used to work on tickets in that queue <davexunit>that queue receives *a lot* of tickets, and there are only a small number of people that resolve them. <lfam>Should I CC one of our lists? guix-sysadmin or guix-devel? <lfam>Indeed, an issue with Savannah. I can't even clone the repo over http <lfam>I started working on a GuixSD declaration to set up SSH git access and Cgit on Nginx <lfam>Can't clone over the git protocol either <lfam>davexunit, ifur: I've sent mail about this issue. <davexunit>if someone were to setup a mirror to an alternative tarball, 'guix pull' has a flag to specify that url <lfam>I've never hosted a public Git repo. Does it require a lot of resources? I wonder if we could host it on our mirror? <lfam>We'd need to set up Cgit, or write something to make the tarball after deleting .git <davexunit>lfam: your subject line should have mentioned savannah <davexunit>that way it would catch someone's eye quickly <lfam>You're right. Should I reply to it with an updated subject? <lfam>I wrote it very quickly... ***adium_ is now known as adium
<avoine>daviid: would it be too soon to add guile-gnome and guile-clutter as packages into guix? <bavier>the shotwell update was uneventful <bavier>I'd like to mention the security issue it addresses, but it was never assigned a CVE <bavier>it did get a "DWF" id though, can that be listed instead? <civodul>bavier: the security fix is worth mentioning in the commit log <civodul>istr LWN had an article about DWF recently <bavier>it only took a month for a integration proposal <civodul>it seems all the folks listed in this message work for some US company/institute <bavier>civodul: do any of hydra's build slaves run GuixSD? <lumidragon>hey all, I keep getting this error when running guix pull. <lumidragon>guix pull: error: file 'guix/build/pull.scm' could not be found in these directories: /gnu/store/d15mb7hk9wg6lrby508pcs2cs0ls9r1c-guix-source/build-aux/.. <bavier>lumidragon: there's been an issue with the tarballs downloaded by 'guix pull' lately <lumidragon>guess we'll have to wait for an update in the mailing list then. <lfam>lumidragon, bavier: The GNU sysadmins replied to me and I am providing more information to help diagnose the problem <lfam>What package provides traceroute? <lfam>It's different from the traceroute provided by Debian <lumidragon>I noticed the -P option was missing on grep. So was gonna guix pull to see if any updates. Otherwise see if I could write patch to enable it. <lfam>I noticed that the command line syntax is different. Maybe a different version, or a different implementation. Not a big deal, just pointing it out. <lfam>Would adding -P to grep mean that perl would become a run-time dependency?