<fps>just the money quote: "Further, Java libraries aren’t like other libraries we’ve seen these types of vulnerability in. For example OpenSSL is usually run as a shared library, so you can update all your RedHat boxes and magically you’re not vulnerable to HeartBleed anymore. Java libraries are a mess in comparison. Every application server comes with its own bundle of libraries, even worse, every application
<rekado>lfam: one could write a maven importer for Guix by parsing the appropriate section in the pom.xml.
<lfam>fps: Referentially transparent? You mentioned memoization and rekado mentioned how versioning and APIs don't matter because you have information about exactly which artifact to use. The question is can you rebuild the artifacts easily enough that it's the same as having them but slower?
<fps>lfam: good question about transparency. it depends on how the artifacts are built. when i mentioned the functional aspect it was wishful thinking. reality is different i think. if you reference a jar from a maven build i don't think maven knows how to build the jar itself..
<lfam>swedebugia: It wants to write a log to the gnu store but everything in gnu store is read only. You will have to configure squid (preferably while compiling) to tell it where to write its logs and put other stuff
<efraim>maybe check out how other services take care of that? dovecot might have something
<iyzsong>swedebugia: usually, those packages require use "--sysconfdir=/etc --localstatedir=/var" when configure, but don't install the files into /var. see 'tinc' for example. or if possible you can use a custom configuration file when write the system services for GuixSD.
<fps>lfam: i don't think maven checks hashes either, so immutability isn't guaranteed either. someone could just replace the artifact on the server your build pulls it from
<fps>but i only used maven briefly a few years ago, so i might be talking out of my smelly parts
<lfam>Oh, are they referenced by a version string then?
<rekado>efraim: fwiw my thinkpad still has no wlan because the stock lenovo BIOS does not permit me changing the network card (and I haven't yet got a programmer to overwrite the BIOS with libreboot) --- but it's still very portable ;)
<efraim>rekado: I have a modified bios so I switched out my wireless chip
<efraim>how did you phrase the package? (define-public linux-libre (package (inherit linux-libre) ... ?
<NiAsterisk>./configure --localstatedir=/var is no longer needed with current git checkouts?
<NiAsterisk>hm. I wonder if the last message came through or if this was bad syntax in erc
<efraim>we got the question about --localstatedir, I don't think anyone here is too sure
<NiAsterisk>ah, good :) then I'll just continue using it for now
<NiAsterisk>so i am maybe away for a birthday party soon, but I'd like to fix gnunet-gtk too. so what I get now, using the glade version we have now, defining it in gnunet-gtk as ("glade3" ,glade3) is https://ptpb.pw/JgKP
<rekado>NiAsterisk: what does the package expression look like?
<rekado>I've built a couple of java packages using the new ant-build-system, but I still don't know if I'm actually doing this right... It's hard to actually get usable source tarballs. Downloading the "*-sources.jar" from maven feels wrong.
<rekado>and it bothers me that the build files for ant are so ad-hoc. Spaghetti targets.
<davexunit>rekado: yeah it's really the mess of ruby packaging that holds me back right now
<davexunit>I simply don't have a Guix-based solution to bring forward right now because we need Rails and hundreds of other Ruby packages.
<rekado>I'm happy that we don't need Java stuff too badly. (And if we did we could still just do like any other Java user and fetch prebuilt jars.) This would really spoil my year. I'm only working on this whenever I feel like it.
<davexunit>I feel duty-bound to help dismantle the current state of software management and deployment
<davexunit>my career sanity depends on Guix, or something like it, being successful and mainstream.
<davexunit>the notion of reproducible builds is slowly starting to catch on, but currently on distro maintainers and cryptographers care about it.
<mog>i prefer the dsl to guile, but i am pretty much against lisp in general
<davexunit>jlicht: yeah, so that's a big philosophical difference
<jlicht>mog: Although I'm not the biggest fan of lisps either, for me the ability to use One Language to rule them all across the board for package definitions, deployments and even service management outweighs that dislike of lisp ;-)
<cehteh>rekado: when one copies over the desktop.scm as template
<cehteh>well for a newbie such templates are the default
<davexunit>we could have example configs for all major DEs
<lfam>I'm reading the log comparing nix expressions to the guix dsl earlier. I remember a couple months ago somebody compared `guix graph` to the nix solution which required scraping / parsing. Does anyone have a link to that? It's a great example of the power of our DSL to show people
<lfam>cehteh: It's a really valuable perspective. Please take some time and write a message to the ML with some patches, or at least, some concrete suggestions. It's too easy to forget the initial hurdles.
<cehteh>some menu based installer .. if only ncurses would be a big step too i may look into that
<cehteh>doesnt need to do as much as debian installer, still experts only but a bit guiding step by step, lets one partition drives and select some defaut configs ..
<lfam>The nice thing about making early users look at a config.scm is that the the default config.scm is actually really simple, just like the hello.scm package definition. And the point is to empower users to hack the system.
<rekado>I thought of something more restrictive; only valid operating-system values can be used. Anyone with higher requirements would probably use their favourite editor anyway.
<lfam>Paredit (at least for Vim) is still raw enough that you do have to understand the "scoping" but it's much easier than not having it
<cehteh>but there is some boilerplate stuff to do which could be scripted and guided, like formatting the drives, select from some default configs with some friendly explanation, fill in some templates (first user name, the partitions one already created, maybe dmcrypt)
<lfam>I imagine this is all in guix.el... still not using Emacs
<NiAsterisk>what about touchscreen-only devices, or touchscreen enabled ones, wouldn't it be good to have option 1, text as usual, and option 2, "something modern" ?
<cehteh>finally i am all about presenting the generated config to the user in a editor and let him view/edit it
<lfam>cehteh: I made some edits to the Guix manual on that topic recently. Please document your "hiccups" so we can improve the manual
<davexunit>NiAsterisk: we really aren't at the point where we should be worrying about that stuff
<lfam>sneek later ask civodul: I remember you sharing a link that describes Nix's analogue of `guix graph`. I seem to remember it involved scraping the recipes. I just can't find the message now. Do you remember the link?
<cehteh>i thought one could just drop something into the store and it becomes available .. of course the .scm definitions should be there somewhere too, but you dont need to do bulk transfers from a single source then
<cehteh>thats why i asked some days ago if the store has some 'api' for adding/removing/garbagge-colection
<cehteh>downloading at 72k/sec .. installing icecat will take a bit
<davexunit>certain things can't be done without 100% reproducibility, like downloading a store item from many peers.
<rekado>the scm definitions don't matter much to the store.
<lfam>cehteh: Probably faster to add fps.io and restart