<davexunit>we'll just have to keep waiting for people to give us a chance.
<civodul>there's a convergence between those who want to get rid of the distro/upstream split (which i can understand), and those who want to push for an "app bundle" approach, which will turn out to work very well for proprietary "apps"
<davexunit>sneek: later tell kyamashita when the sources are inputs to the build, you can access them via the "inputs" keyboard argument to a custom build phase. there are many existing package recipes that refer to their inputs like this for you to read.
<sneek>Welcome back kyamashita, you have 2 messages.
<sneek>kyamashita, davexunit says: you cannot download things in a build phase. you need to make those origin records inputs to the package.
<sneek>kyamashita, davexunit says: when the sources are inputs to the build, you can access them via the "inputs" keyboard argument to a custom build phase. there are many existing package recipes that refer to their inputs like this for you to read.
<phant0mas>davexunit: I was thinking that maybe we can create an empty stubs file
<htgoebel>‘native-inputs’ is typically used to list tools needed at: build time, but not at run time
<civodul>htgoebel: guix-daemon determines the set of run-time dependencies by scanning the result and looking for /gnu/store references
<civodul>where run-time deps are a subset of build-time deps
<davexunit>civodul: this seems to be a frequent source of confusion. people are used to having to be explicit about what the runtime dependencies are
<phant0mas>davexunit: I was thinking, we could move the parts of limits.h used in avr-libc to the avr-libc itself
<phant0mas>and then kill the glibc dependency with fire :-)
<htgoebel>davexunit: ACK. I already had understood that built-time dependencies are inputs plus native-inputs (so I do not need to specify things twice). But the wording in the manual is a bit confusing.
<davexunit>phant0mas: civodul followed up on the mailing list and said it does seem odd that the build is using the host libc