<aggelos_>thomasd: hmm, but then I would not be capturing which deps I'm building against, right?
<thomasd>it would still use the dependencies defined in the version of guix you're currently running
<thomasd>so you could specify the guix version number together with your custom module definitions to precisely define your dependencies, but until we have `guix channel' or a similar features, it's not trivial for others to reproduce the exact setup, AFAIK
<thomasd>(not trivial, but probably not too hard either :) )
<aggelos_>thomasd: so using my own branch of the guix repo is not an option?
<cbaines>I'm having trouble getting a specific version of ruby within an environment, guix package --firstname.lastname@example.org seems to work, but guix environment --ad-hoc email@example.com just gives the newest version of ruby?
<rekado>roelj: they say they are a "conference for developers, architects and decision-makers to explore technologies beyond the mainstream in software development, and to find the best tools available to software developers today"
<rekado>since they had a talk on Nix before they asked me to also discuss differences.
<rekado>I'll do that by showing off how one can interact with packages on the REPL and how Guix can be used as a library for tools like "guix web" or "guix graph"
<civodul>rekado: re tone of the audience, i really agree with you; sadly, i've noticed that people often want to be spoonfed with an executive comparison
<ng0>I assume tlsdate-service is functional. there's this old problem again where I would have to setup an network brige and start qemu with the right parameters to make the lookup of dns succedd in the machine.
<ng0>i'm very open to suggestions on how to test this. so far I just know I pass the right commands to tlsdate
<ng0>networkmanager can add bridges.. and iputils. but is there something guix specific for the config of the host? or is it still manual?
<thomasd>I'm packaging kdevplatform. Most test will only work *after* you have run 'make install'. Does it make sense to move the 'check phase after the 'install phase for this package, or do I just skip the tests?
<rekado>thomasd: we move the check phase in some python packages. Moving the phase (if there's no other way to run the tests) is fine.
<thomasd>rekado: thanks, I'll look at those packages.
<rekado>does it have a network connection to a system that is online?
<rekado>if so you might be able to configure offloading
<ng0>i will post the first version of tlsdate-service to the list when I'm back in one or two hours, I definitely need to get input on vlan0 and connection to the outside of host from qemu. the service works, but it would make it easier to test.
<quiliro>rekado: were you suggesting installing guix on a running system and not guixsd?
<sankey>my personal rationalization about flatpak popularity is that its somehow easier to explain without using math or computer jargon, and it closely resembles the process that most people in the world package software (proprietary software bundling dependencies)
<rekado>some users don't like to wait for me to package R stuff, so they have a shared Guix profile with gcc-toolchain and a couple of common libraries. Then they can use their usual workflow to build software.
<rekado>without any of the guarantees Guix provides, of course.
<davexunit>"Something like the Windows API or OS X API would seem to provide a reasonable approximation of what functionality ought to belong in the base system. These platforms have withstood the test of time and you don't hear about many problems resulting from third party developers bundling libraries."
<davexunit>but I haven't yet seen any Flatpak evangelist admit that.
<lfam>davexunit: I remember getting a patch for some bioinfo software where all the inputs where custom Git URI origin fields, because the packager wanted to use particular Git commits of each direct dependency. They are worried about the same thing as the flatpak advocates in that thread.
<[df]>and even then they're no good if your end user happens to be using a different hardware architecture
<lfam>You know I'm on our side, but they have valid concerns IMO
<lfam>If their application is in the GNU Guix packages, and they ask their users to install it with Guix, then they do have to ride the wave of updated packages to make sure everything keeps working. Of course, with their model, they still have to ride the wave of all the unbundled dependencies, but that's a smaller set of packages to watch
<davexunit>lfam: the concerns are valid, but if only they would give Nix and/or Guix a chance
<davexunit>I think it's good for applications to depend on the latest stuff, but promote particular builds as "blessed" or whatever, meaning that the maintainer built the software with *exactly* this and it works well.
<bavier>yeah, that information is available for most perl packages too, just a matter of deciding how to make use of it I think
<lfam>We need to have a clear demonstration of how so-called "ISVs" can offer an equally stable experience for their users as with bundling, and also be something that requires equal or less work for the vendor
<davexunit>with guix, you *could* bundle if you really wanted to, but we give you the tools to avoid that.
<lfam>Heck, it's dead simple to build Syncthing with all the bundled stuff.
<lfam>Just use the default invocation of the Go build tool
<lfam>I do this in my 3rd party repo (all the dependencies are free software)
<lfam>*HINT* Any Go programmers are invited to help me package Syncthing properly :) :) :)
<davexunit>it's nice to be able to decide your own level of "fuck it"
<lfam>I did that, but I'd really like Syncthing in GNU Guix. It's an awesome tool with some a large community
<bavier>we often note input version dependencies in comments, but I suppose we could declare the constraints in code somehow too
<lfam>BTW, I hope that anyone who is interested in Syncthing, and wants to build it from source, will try my package. I've been using Syncthing for a long time and I am sure this package works properly. It includes documentation and all the server-side tools for anyone who is interested in using those too.
<lfam>I have not been able to figure out a good solution for a Go build system, so I've kept it in my own repo all this time, but I'm sure that with some more attention, we could figure something out
<lfam>I *still* see people who are in the world of FOSS software talk about using Dropbox. Syncthing could totally eat their lunch
<davexunit>I agree with jmd on this one, though I wish people wouldn't assume that no one uses guix because clearly many people do.
<lfam>Petter: The big stumbling block for me is setting up the GOPATH before building
<lfam>Petter: From what I can tell, most Go packages require this to be set properly, with the directory structure to match, in order to build. But, I can't figure out if this path can be determined programatically, or if a human needs to figure it out, and set it manually
<Petter>lfam: The directories must match the imports in the code, which is of the form: "github.com/boltdb/bolt".
<lfam>Petter: Right, I know that much. But is there a way to learn that path string without using human intuition? :)
<Petter>It matches the git location usually. Are you getting the dependencies with git?
<davexunit>efraim: does that work? the package list isn't an alist
<lfam>Petter: We could do that, although it can be very inefficient to fetch the Git repo compared to a release tarball (Git repo's may be huge). Although Go libraries seem to not have tagged releases, so fetching from Git may be the only option in that case.
<davexunit>each element is a list, (cons a (cons b '()), not a pair, (cons a b)
<lfam>So, do we want to graft zlib? :) That might be the entire distribution
<lfam>I request some expert C programmer advice on this subject. bavier, mark_weaver? Who else?
<Petter>lfam: There's another issue. A Go package with two dependencies, where each of those refers to the same third dependency, but of different versions.
<lfam>Well, we'd have to create versions of the 3rd dependencies with differente upstream Git commits
<Petter>If such a situation is detected I think it would be necessary to prepare GOPATH for one dependency, build it, then switch some symlink in GOPATH and build the other.
<lfam>How do Go programmers deal with this? My understanding is that they just use "whatever is in my ~/src tree", which means there would only be one Git commit checked out while building. Is that right?
<lfam>That "use whatever is there" practice is why upstream repos all refer to seeminly arbitrary dependency commits, in my totally naive understanding.
<Petter>Yes. So, some people have different workspaces pr. project and updates GOPATH when they'll be working on another project.
<lfam>I mean... do Go programmers actually notice with dependency commits they are using? It seems abitrary from my perspective
<Petter>It also makes it difficult to collaborate, when the next person sets up their workspace, they'll get different versions of the dependencies.
<lfam>And that's why Syncthing bundles all the Git repos
<lfam>Using whatever Git tool enables such a crazy idea ;)
<Petter>Because there's no one good way of doing it, different projects provides different solutions.
<lfam>Ideally, we delete them in an "origin snippet" and rely on the upstream build system to find and use the copy we provide. Most build systems do this on their own, but sometimes we have to apply some patches
<lfam>These patches usually just change a path somewhere
<lfam>Sometimes, it's not feasible to unbundle, so we document it and just accept it, or leave it for later
<Petter>This doesn't account for a specific version though, does it?
<lfam>Well, if the package needs a particular version of some software that is different from the version we have packaged, we can make a package variant that selects a different version
<lfam>In that case, the packager needs to know the version ID (tag or commit) and the hash of that source code
<Petter>Ah yes, you would specify the version in the recipe. Doh.
<lfam>These variants can even be constructed in the inputs list of the package
<lfam>For Go, that might be the thing to do, since these variants typically won't refer to a tagged release version of the dependency, so there won't be much point in defining and exporting the variant
<lfam>I'm trying to think of an example in our packages...
<lfam>The icedtea packages in (gnu packages java) do something interested with the source code "drops". See icedtea-7
<bavier>I've only tried this once before with a minimal os configuration
<bavier>the idea is to create an os configuration that inherits from the one defined in the (gnu system install) module, then have 'guix system disk-image' build it
<bavier>you can then boot that and install as usual. if the configuration you declare is a subset of the one you created the disk image with, you shouldn't need to access the network, since packages will be in the installer store already
***Dezponia_ is now known as Dezponia
<quiliro>how can i download all the binaries and point the guixsd usb installer to them?
<quiliro>or how can i help in order to achieve offline installation
<bavier>quiliro: check out the gc-root-service-type that civodul just mentioned, you should be able to use that to inject package source tarballs into an installation image
<cbaines>So, I'm having some fun trying to get the postgresql service working with the en_GB.utf8 locale. There was a thread on help-guix about this recently, and looking at that suggests that the postgresql binaries might need wrapping such that they have GUIX_LOCPATH set? I'm unsure though, as there doesn't seem to be any examples of this being done?
<lfam>cbaines: Shouldn't it be enough to set GUIX_LOCPATH in the environment, without wrapping the package? This is what we suggest in the installation docs, under Application Setup
<cbaines>lfam, I did consider that, but then you couldn't ensure that GUIX_LOCPATH that was set in the service matches the right version of glibc that postgresql was built with?
<cbaines>I also can't see any examples of other services setting the GUIX_LOCPATH
<cbaines>lfam, I've tried setting GUIX_LOCPATH to /run/current-system/locale within the postgresql service activation script, but initdb still complains, and when running locale -a it still gives just C and POSIX