<sneek>civodul, bavier1 says: yes, I've done quite a bit of work trying to get 'refresh -l' to be more reliable in the face of implicit inputs. Handling dynamically created packages (e.g. with package-with-python2) then became a critical issue. I haven't yet gotten a solution that's fast or accurate enough for my taste.
<civodul>bavier1: using bags instead of packages would be an improvement already
<mark_weaver>civodul: the release of linux-libre-4.1.2 is considerably delayed, and I wanted to create a new 'source' package for it that creates linux-libre-4.1.2-gnu.tar.xz from linux-libre-4.1.1.tar.xz and patch-4.1.1-2.xz from kernel.org. however, it looks to me like there's no straightforward way to do that. the only way I could find is to create a new origin method. am I missing something?
<mark_weaver>it seems that I cannot create a normal package whose output ends with .tar.xz
<paroneayea>but I think foruth, I spent some time searching for how to supply config files through the system definitions, only to find out that I wasn't missing something, there's no official way currently? :)
<paroneayea>mark_weaver pointed this out, said there was a thread on how to do so but it hasn't gone places yet
<paroneayea>I got excited about the functional system definition approach to this though when I read this:
<mark_weaver>well, I don't remember off-hand what an up-to-date config.guess returns on Novena, but it depends on what kind of arm device you're running on, and also on whether config.guess is new enough to support the machine.
<mark_weaver>okay, I just ran config.guess from guix on the novena, and it returns: armv7l-unknown-linux-gnueabihf
<civodul>and the problem is that it might strip the "v7l" part on other machines?
<mark_weaver>as I recall, I experimented with various triplets and settled on arm-unknown-linux-gnueabihf because some build systems (generated from ancient autotools) didn't cope well with the v7l or similar.
<mark_weaver>our gcc is configured to generate code for arm7 anyway, so in the overwhelming majority of cases, it shouldn't matter.
<mark_weaver>it's possible that there are some packages where we'll want to override the triplet passed via --build, but I expect that to be rare.
<mark_weaver>so maybe it should be a build system argument, with a defaulting to (nix-system->gnu-triplet (%current-system))
<mark_weaver>civodul: sorry, to answer your question: the problem with config.guess is that it decides what triplet to report based on the details of the build machine, e.g. the specific CPU in the machine, and maybe also the kernel that's running.
<mark_weaver>which is a source of non-determinism in the builds that are not factored into the nix hash.
<mark_weaver>and also means that if we use an armv8 build machine, the builds done on that machine will not run on armv7.
<mark_weaver>so the whole idea here is to avoid config.guess, since it doesn't do what we want.
<mark_weaver>it happens to work well enough on intel machines in practice (perhaps because we don't have an i586 port), but on other architectures it looks at things like /proc/cpuinfo and uname output.
<mark_weaver>so, on arm, that 'armv7l' comes directly from the output of 'uname -m'
<mark_weaver>and that is ultimately coming from the kernel's probe of the arm processor it's running on.
<civodul>mark_weaver: it's a good idea to make #:build a build-system argument, just in case
<mark_weaver>so, on my novena, /proc/cpuinfo reports: "model name: ARMv7 Processor rev 10 (v7l)"
<mark_weaver>civodul: okay, sounds good. I think I know what to do now. thanks!