<buenouanq>I've been unable to boot the current install image. <ruki1>It seems I need to update the daemon, but how can I upgrade the daemon on the installer image? <buenouanq>weird thing and it's running away now so I'm not going to confirm it right now, but <buenouanq>I had /mnt/etc/config.d/ and /mnt/etc/config.scm <buenouanq>and guix system init said it couldn't find the config <shiranaihito>does the idea of making a guix package out of a SaaS application make sense? :p <shiranaihito>then i could presumably set it up in a system config, which would be nice, i guess <shiranaihito>how do i search for a package? (in this case, the icedtea JDK) <shiranaihito>arguably, major JDK versions should have their own packages - some apps require a specific one <shiranaihito>oh, and i believe upgrading from 1.8 to 1.9 will require changes to Java applications because of the new module system - so if applying a system config results in 1.9 being used instead of 1.8, that might break some software <shiranaihito>but it kind of looks like no one should be using the system package for any serious java application <efraim>I don't know much about the Java packaging <shiranaihito>well, unless i'm missing something, it seems there's plenty of room for improvement <OriansJ>shiranaihito: I can tell you exactly what that means <OriansJ>in guix we demand that all binaries are built from source but how do you build from source when you have no binaries? Well you first have to build the binaries required to build the binaries required to build the source we have. <OriansJ>So, what that is about is using gcc, how to build out the java infrastructure required to compile java programs <shiranaihito>so openjdk can't be built as its own, "stand-alone" project? <OriansJ>shiranaihito: well openjdk is the java compiler but it is written in java <OriansJ>so, we needed to find a way to build openjdk without having a java compiler <shiranaihito>hmm.. ok, but wouldn't openjdk itself contain all you need regardless? <OriansJ>shiranaihito: create a virtual machine with nothing on it and try to compile openjdk, go ahead, I'll wait <shiranaihito>any idea why that is? are they just making life more difficult? <OriansJ>shiranaihito: no, it is just the nature of programming. You need binaries capable of converting human readable code into binaries that computers can run <OriansJ>shiranaihito: no intention to be rude. Sorry <shiranaihito>but it's also problematic for any "serious" users if the icedtea package is just casually left in a broken state <atw>Hello! guix pull tells me that I need to upgrade to intermediate version first. I ran the recommended command ("guix pull --url.../v0.13.0.tar.gz") but afterwards, running guix pull still gives the "installation is too old" message. What should I do about this? <shiranaihito>so now it seems i have to install Azul's Zulu JDK separately, but .. do i then lose the benefit of Guix in general, since it won't be installed by Guix? <OriansJ>shiranaihito: well, that is one of the problems with limited programmer resources we have. Bootstrapping projects are the sort that tend to consume vast amounts of human effort <shiranaihito>OriansJ sure, resources are limited :) but if "you" want Guix(SD) to get adopted by businesses, Guix needs a reliable JDK (with separate major versions) <atw>shiranaihito: are you familiar with the state of Java? I'd like to help out, once I start using Guix more seriously <OriansJ>shiranaihito: if you wanted, it is rather trivial to just package up a binary and use it. Like we did with ghc (since that is a long term bootstrap project) <atw>shiranaihito: I recall there was work being done on incorporating maven. I'm interested in that side of things, as we could eventually get things like leiningen and sbt packaged <shiranaihito>OriansJ so i could use a "binary blob" in a system config and guix would still work its magic much like normal? :P <OriansJ>shiranaihito: ghc and the bootstrap binaries are excellent examples <shiranaihito>oh.. well, i guess looking at the package definition for ghc won't do me much good <OriansJ>shiranaihito: we are constantly working to reduce the number and size of our bootstrap binaries. My project stage0 is aiming to reduce the size of the bootstrap binaries down to 200bytes <shiranaihito>OriansJ sounds good, but .. how would i use a binary blob in a system config? <OriansJ>shiranaihito: you simply download and have it moved to where you want it <atw>So I think I need to reconfigure...but I'm also having a problem reconfiguring. I can evaluate my config.scm in the REPL, but when I do guix system reconfigure config.scm, I get "Unbound variable: connman-service". Why would I see these two different behaviors? <shiranaihito>so anyway, how much of a problem is it, if i set up the Zulu JDK separately, just place it in a folder and use it from there? <shiranaihito>i mean, i'm wondering about the overall implications for my GuixSD use, if any <OriansJ>shiranaihito: provided your package definitions are done correctly, minor <shiranaihito>OriansJ what package definitions? i mean, if i'm not using it through a system config? <shiranaihito>i guess i'd need to scrape up some kind of binary blob package definition for it, if i want to use it in a system config? <shiranaihito>but at the moment i'm not sure i have the energy to do that.. even just adopting Guix(SD) in general is basically a waste of time at this point, when i should be trying to get my SaaS product running and in front of customers as soon as possible <shiranaihito>.. but i want to use it anyway because i'm silly like that <shiranaihito>also because i find the common linux distributions vaguely distasteful/unpleasant <OriansJ>shiranaihito: then just do a flatpack and call it done <shiranaihito>.. and also because i think there's lots of potential in GuixSD <OriansJ>shiranaihito: solve the customer problems first, packaging can be changed later <shiranaihito>i had never heard of flatpack either though.. any idea how/why i'd want to use it? :) <OriansJ>shiranaihito: basically it allows you to build your application and the resulting binary will run on any linux system <shiranaihito>"Flatpak is the next-generation technology for building and installing desktop applications" <-- what about server applications, like mine? :) <OriansJ>shiranaihito: all applications are just binary files, even java apps <OriansJ>Flatpak doesn't solve the configuration problem but if all you wanted to do was deliver a product your customers could just run and be done, it will work <OriansJ>shiranaihito: since it is hosted on your own servers, you could always migrate slowly to guix <shiranaihito>OriansJ so what did you mean with this: "provided your package definitions are done correctly, minor" <shiranaihito>what happens, "in terms of guix", if i just place binary stuff somewhere and use it? <OriansJ>shiranaihito: I'm assuming you also want your application to be built with guix to allow full system update via guix. Which requires your package definition to have a proper dependency on the binary package you were to need. Which would result in you having to update those package definitions whenever you updated the binary blob <shiranaihito>OriansJ yeah, i suppose that would be nice in the future <shiranaihito>then i could use GuixSD a bit like a virtual machine image etc <OriansJ>shiranaihito: well it certainly would simplify the problem of spinning up a bunch of machines for new customers. <ngz>Hmm. I have a package that gets installed in DESTDIR/usr/{bin,share} instead of DESTDIR/{bin,share}. The build system is gnu, as a wrapper around cmake (i.e., "make" calls "cmake"). Is there some well known variable to tweak in this case? <ngz>Of course, DESTDIR is (assoc-ref %outputs "out") so it doesn't mention "usr/" <ngz>I ended up boasting my own installation phase. ***propumpkin is now known as contrapumpkin
<jlicht>hey #guix! Can I use `properties' on packages for any reason, or is there some sort of standard definition for using this? (E.g. `upstream-name' used by `r-s4vectors' in bioinformatics.scm) <efraim>you can add just about anything you want <jlicht>efraim: nice, I had hoped so already, but it's good to know for sure