IRC channel logs


back to list of logs

<buenouanq>I've been unable to boot the current install image.
<ruki1>Hello! I recently tried to install Guix 14.0 and ran into a problem when running #guix system init /mnt/etc/my_os_config.scm /mnt. Apparently it has to do with a possible bug described here:
<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
<buenouanq>removed config.d/ and it worked
<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>(nevermind about the search :p)
<shiranaihito> the "icedtea" package could mention what JDK version it is, like 1.8, 1.9 etc
<shiranaihito>i'm guessing (and hoping) it's 1.8
<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>from the icedtea package definition: - "There are many test failures. Some are known to fail upstream", which sounds kind of worrisome
<shiranaihito>i wonder if "tests" refers to the TCK:
<shiranaihito>why the crickets btw? :p
<shiranaihito>but it kind of looks like no one should be using the system package for any serious java application
<efraim>Sundays are normally very quiet
<shiranaihito>i see :p
<shiranaihito>efraim so any comment on anything?
<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
<shiranaihito>i wonder what this "bootstrap" stuff means:
<shiranaihito>it seems quite complicated
<OriansJ>shiranaihito: I can tell you exactly what that means
<shiranaihito>OriansJ go ahead then :p
<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?
<shiranaihito>java programs are compiled with javac, right? :)
<shiranaihito>.. which would be included in the openjdk?
<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: no
<shiranaihito>that's weird
<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?
<shiranaihito>i'll take your word for it
<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
<shiranaihito>OriansJ no need to be snide
<OriansJ>shiranaihito: no intention to be rude. Sorry
<shiranaihito>np :p
<shiranaihito>all in all, java looks problematic for guix
<shiranaihito>but it's also problematic for any "serious" users if the icedtea package is just casually left in a broken state
<shiranaihito>"lots of tests are failing. oh well."
<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
<shiranaihito>atw "the state of java"?
<shiranaihito>i'm not sure what you mean :)
<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: yes
<shiranaihito>atw alrighty :) but how can i help you now? :)
<shiranaihito>ok, cool
<shiranaihito>OriansJ any example you could point me to?
<OriansJ>shiranaihito: ghc and the bootstrap binaries are excellent examples
<shiranaihito>OriansJ ok, i'll take a look
<shiranaihito>oh.. well, i guess looking at the package definition for ghc won't do me much good
<shiranaihito>OriansJ that's better, thanks :)
<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
<atw>shiranaihito: if you happen to know the answer to my guix pull issues, I'd appreciate some help there. I think I need to reconfigure
<shiranaihito>atw i have no clue about any of that, sorry
<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
<shiranaihito>OriansJ "have it moved"?
<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>yeah :)
<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? :)
<shiranaihito>even java apps?
<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
<shiranaihito>ok, apparently flatpak is meant for desktop stuff
<shiranaihito>i have a SaaS app, i.e. not desktop stuff :p
<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.
<shiranaihito>something like that :p
<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.
<dustyweb>hello #guix friendos!
***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