<mog>does guix have the same problem as nixos with running 3rd party binaries? <mog>nixos cant run them out of the box without running patchelf on the binary as it cant find glibc and what not <davexunit>"third party binaries" are likely binaries developed for specific operating systems <davexunit>mog: then yes, those binaries will not work. <davexunit>luckily, you can just compile from source instead. <mog>thats what i thought i was just curious if guix had done something different <mog>its just gcc toolchain for embedded work <mog>but pain to recompile them all the time <davexunit>perhaps those binaries would work if A) glibc was ABI/API compatible and B) the correct LD_LIBRARY_PATH, etc. was set <mog>davexunit, thats what nixos does, just patches elfs and everything works <mog>but its a lot of patching <mog>ill probably just end up packaging it by hand <lfam>Guix doesn't like to package upstream binaries. We like to build it from source since we are focused on software freedom. <mog> right i understand the aversion to it <davexunit>mog: what I was talking about was merely setting environment variables, not patching the binaries themselves. <mog>and its just gcc cross compilers <davexunit>internally, we have found the patchelf tool extremely unreliable and have removed its usage for our own package builds <swedebugia> how do I get (version-major+minor version) working? it complains with "unbound variable" <lfam>swedebugia: Post your package definition on a paste site <fps>swedebugia: version-major+minor is a function in a module you need to use. and version needs to be a version string iirc <rekado>I've been trying to fix our build of tuxguitar but haven't been successful so far. <rekado>I'm passing -fsource=1.4 (to avoid warnings) and -fPIC to fix the build and that works but tuxguitar fails on start :-/ <rekado>The error is is SWT: Exception in thread "main" java.lang.UnsatisfiedLinkError: memmove <iyzsong>ug, I once looked, but have no idea how gcj, swt, etc. works <fps>i wonder if the android dev tools work with icedtea <swedebugia>I finally think I learned how to use the arguments correctly. Now squid is building :D <rekado>iyzsong: I'll first fix the tuxguitar problem (because these GCJFLAGS really need to be passed) and then try to fix swt later. <fps>rekado: no idea :) will try later, cause i need things on my laptop [which runs guixsd] for my current job, too <rekado>fps: the icedtea packages work for the most part. One big problem in the Java world is build tools, though. <rekado>we have no maven, only a very rudimentary ant. <fps>my current project build is gradle based <fps>as that was what androidstudio created before crashing repeatidly <fps>but with the gradle setup which is decent (in that it makes no fuzz and seems to work) <rekado>if you just use prebuilt jars it should work fine. <rekado>but building all this from source is a nightmare. <rekado>it seems that few people in the history of Java ever thought of building their projects from source. <swedebugia>i'm a little curious how the building of all the packages on my other x86-machine is going <fps>it's a common pattern just to throw jars into the build <lfam>Yeah, what's up with that? How do they ship their software? <rekado>the use of maven seems to encourage downloading jars from their site. <fps>lfam: there was a nice article a month ago or so how that gives you security implications, too <fps>let's see if i can find it <lfam>Do they just keep build artifacts around forever and never break ABI? <rekado>the pom.xml describes binary artifacts as dependencies and maven downloads them at build time. <swedebugia>about to try packaging php7 now. it has weird mirrors-urls <rekado>iyzsong: I think the author of this email has misunderstood Guix. It is not supposed to be a meta package manager. <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 <fps> you deploy on the server often comes with its own set as well. To fix this completely, you need to find and update every single library individually." <iyzsong>rekado: yes, guix is not an interface to other package managers (meta?), but hopefully a complete solution :-) <lfam>fps: Just earlier today rekado pointed that out to me in jitsi, which I was thinking of packaging. <rekado>fps: and it really doesn't have to be like this! <rekado>there's a classpath and you can add jars from system locations. <fps>if you think functional, then a .jar is just a memoization of a previous build, so that really isn't the issue imho. <fps>the packaging that people do, keeping outdated versions around is the problem.. <rekado>and maven makes it really easy to link to a particular binary artifact. Version numbers and API stability doesn't mean much in a world like that. <lfam>Is it transparent like Guix? <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? <swedebugia>IÃ'm aware that we have a special "mirror://" for sourceforge. <efraim>maybe a new mirror:// type that gets fed "mirror://php-" version ".tar.bz2" and translates it for downloads <swedebugia>I would like to focus on compiling for now as my scheme knowledge is no good yet <lfam>fps: That story is out of this world <swedebugia>when run it complains: WARNING: Cannot write log file: /gnu/store/2f6hbam4cgixys1448apyycl59gjx680-squid-3.5.12/var/logs/cache.log <swedebugia>/gnu/store/2f6hbam4cgixys1448apyycl59gjx680-squid-3.5.12/var/logs/cache.log: Permission denie <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 <fps>lfam: and then there are the timestamps in jars, manifest, etc.. which redako battles with :) <lfam>fps: So, you have an immutable tree of libraries and such but you can't recreate it? Part-way there ;) <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>"The question is can you rebuild the artifacts easily enough that it's the same as having them but slower?" --- usually no. <rekado>"building from source" means little in the Java world. <rekado>because the thing you want to build has dependencies that will be either bundled or downloaded from maven. <rekado>to actually rebuild the whole graph of artifacts .... you'd need Guix. <rekado>there is no support for recursively building dependencies. <rekado>I don't even know if you can convince maven to use a locally available "jar" file and prefer that over an artifact on the maven binary repository. <lfam>It doesn't even tell users to run `make`, which is fine for some people but not for people who just want to try writing a package definition. <lfam>And I don't think that `./bootstrap` downloads the daemon source code <lfam>Oh, the version on the website is quite old <rekado>erm, I think this should not happen: "result of ‘/gnu/store/273x2mhs27frkv1li5pjfnv4mb1i33gv-module-import-compiled.drv’ differs from previous round; rejecting as non-deterministic" <rekado>I did this: ./pre-inst-env guix build --rounds=2 junit <cehteh>sooo --- got an old netbook, now lets see, installing guix on real hardware <fps>rekado: you think it's wrong about the differing? <rekado>I don't know why it builds "module-import-compiled" when I ask it to build "junit". <rekado>it doesn't even start building "junit" (which is deterministic now). <efraim>cehteh: fun! what specs on the netbook? <efraim>my netbook has an intel wlan nic <efraim>another option would be to use an old cellphone connected to wifi, tethered to the netbook <efraim>although it would severely limit its portibility <cehteh>i want a vanilla linux kernel damnit <rekado>cehteh: you can create a variant of the linux-libre package and use that as a kernel. <fps>someone else has done that already, but i won't post the link here <rekado>I made a variant that applies the realtime patch set. <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>efraim: (define-public my-linux (package (inherit linux-libre) ...)) <rekado>efraim: in your package variant you can then use a different patch set or config files etc. <rekado>NiAsterisk: it complains about gladeui, not glade. <rekado>sorry, ignore the previous sentence. <rekado>NiAsterisk: looking at configure.ac I see this: <efraim>so you have to specify to use my-linux, it doesn't automatically replace linux-libre <rekado>otherwise it only looks for gladeui-2.0 <rekado>but our glade package only provides gladeui-1.0 <NiAsterisk>rekado: there's an older version of glade package in the sources? <rekado>so I'd suggest replacing "gtk+" with "gtk+-2" <rekado>efraim: you don't want to redefine linux-libre; just use the new kernel in the operating-system expression. <NiAsterisk>i have a question though.. is it ("public-name" ,packagename-optionalversion) ? I try to make sense of what I write. so far it just worked because I felt it was right <rekado>efraim: see the documentation for operating-system; it has a "kernel" field. <rekado>NiAsterisk: the string is just a label. <rekado>the second thing is an unquoted variable name. <rekado>the string can be arbitrary, but usually we give it the same name as the variable or package name. <rekado>the second thing must be a valid variable. <rekado>i.e. it must have been defined somewhere, e.g. with (define-public foo ...) <rekado>the version is not optional; it can be part of the variable name. <rekado>when you go to gcc.scm you can see a couple of values that contain numbers, such as "gfortran-4.9" <NiAsterisk>niceee :-) now it complains about a different thing I can work with. thanks for the tip with gtk+-2 <NiAsterisk>I'm tempted to stay and fix this. but otoh going to the party would be nice too. conflicting interests <rekado>this is independent from the package expression's (version ...) field. <rekado>I often find it helpful to look at configure.ac; these files are pretty easy to read (not the "configure" script itself). <rekado>it's a birthday party --- AFAIU people have birthdays every year. <rekado>you could pass "--without-libunique" as part of the #:configure-flags <NiAsterisk>i'll see what I can do tonight. I'll go to the party <rgrau>hi guixers, I'd like to try guixsd (in a virtualbox). after uncompressing the image, the file has no extension. which format does it have? <efraim>its raw, made to be dd'ed to a usb stick <efraim>so you should be able to "stick it in the cd drive" of virtualbox <cehteh>rekado: i check on building my own kernel, just hoping i can do that on the netbook without any network connection <rekado>cehteh: building a kernel on a netbook usually results in the smell of molten plastics. <rekado>if you have another machine you could build the kernel there (just make sure it's built for the right architecture) <rekado>cehteh: does the netbook not have an ethernet port? <rekado>to build the kernel you'll have to download the sources and obviously the inputs of the package. ***MatthewAllan93_ is now known as MatthewAllan93
<cehteh>rekado: realtek not supported by libre <cehteh>that *is* the problem about installing guix .. w/o network its no fun <cehteh>well i want to build there, i am patient and i want a self-sustaining system <rekado>if you can build elsewhere you could then export the closure and import it into the store. <cehteh>but i have to learn how i get this working now <rekado>not sure if that's possible when you cannot easily fetch the inputs (sources, build tools, etc) <davexunit>rekado: part of what I want to accomplish with 'guix deploy' is to easily transfer closures from client machines to remote hosts. <cehteh>davexunit: hopefully for sneakernet too :D <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. <cehteh>davexunit: manually moving things <davexunit>rekado: Java is so much worse than I previously thought it was <cehteh>on another channel a friend just discovered the ruby peoples mindset: <cehteh>[15:08] <cytrinox> install step 2: <cehteh>-- YES PLEASE PIPE MOAR FROM THE NET INTO A ROOTSHELL <cehteh>mhm so back to the netbook .. installing guix without network is impossiboro, installer has not enough packages to rebuild kernel either <efraim>you could use a second usb stick and put the files you need on it, and then run `for i in `ls /media/usb2`; do guix download /media/usb2/$i; done` <efraim>*guix download file:///media/usb2/$i <efraim>because everything can be solved with more usb sticks/sd cards apparently <cehteh>biggiest problem is the entry barrier i dont know enough about guix yet how to do it <cehteh>how do i configure and build a kernel package on another non-guix system? <davexunit>cehteh: you can make your own disk image that has *all* of the software you need to install the system available locally. <davexunit>cehteh: modify our linux-libre package and ask guix to build it <davexunit>use 'guix archive' to export it and import it into another machine <efraim>guix download --sources=transitive usbstick <cehteh>i have no guix system running here, except for a remote kvm <cehteh>but i dont want to install guix on my productive debian system yet <davexunit>but if you want to build guix packages on it you need guix <cehteh>my laptop hasnt much space either <davexunit>Omnibus is a tool that enables developers to make packages that are a massive blob of every single dependency that someone needs to run your software <efraim>what about go? you don't even need a go binary installed to run a go program <efraim>undeclared depends can be declared and fetched during build-time <davexunit>efraim: go is absolutely horrible for a different reason! <davexunit>*everything* is statically linked, all the time, always. <davexunit>because it must have been written for proprietary software developers only <cehteh>iirc they added dynamic linking recently <cehteh>from a programming language view go isnt that bad, but linking everything static sux <efraim>with guix I'm not sure it matters that much <efraim>dependency gets updated and we're off to rebuilding <cehteh>well the web folks want deployable binaries .. who cares about security <efraim>"stick it in a docker container" <cehteh>haha how much easier could guix be if everything would be static linked <davexunit>and any potential for grafting for security updates <cehteh>but there is this ksm stuff merging same pages in memory again <davexunit>cehteh: guix wouldn't be that much easier if everything were statically linked. <davexunit>people always bring up how the kernel will dedupe and all that <davexunit>but it's the wrong layer to be solving this problem <cehteh>ksm only works for pages tagged for that <davexunit>the same thing happens with disk duplication <davexunit>the file system layer is the wrong place to be solving your rampant file duplication issue! <cehteh>dunno .. some people may disagree <davexunit>Snappy/Project Atomic developers and advocates, for example <cehteh>anyway aboout the gub error .. i just installed (tried to install) guixsd exactly as described inthe docs in a kvm and it didnt properly install grub <cehteh>i thought i made a /boot partition and forgot to mount/configure it, but thats not the case <cehteh>how do i chroot into a mounted guix installation? i mean so that some useable environment becomse visible <rekado>cehteh: "but i dont want to install guix on my productive debian system yet" --- guix doesn't break a production system. It only does things with /gnu and in /var/guix (aka localstatedir). <rekado>davexunit: OmniBus sounds great. <cehteh>rekado: i know but i dont have much space on the laptop left and i dont want guix there yet, this shall stay debian for now, eventually i may use guixsd when everyhing works well <davexunit>rekado: I rely on omnibus packages to get stuff done at work. bleh. <davexunit>because we use Chef, and the company that made Chef also made Omnibus <rekado>what's it like to work with technology of the future? <davexunit>we have a consultant doing packaging work for us, and to build the packages we basically have setup an ad-hoc, informally specified version of half of Guix <davexunit>then we install Ruby and Bundler in the container <davexunit>and bundle the application source code + all of the dependencies downloaded from rubygems.org with bundler into a package with fpm <davexunit>and this is the best way we found to do it because Guix isn't an option right now. <rekado>when I started here Guix wasn't really an option either (no bioinfo packages! no java! no R!). I'm glad that we're past this now :) <rekado>too bad that ruby packaging is such a mess. <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. <davexunit>" Make sure that everybody can build everything from scratch, without having to rely on Maven or Ivy or SBT downloading something automagically in the background." <rekado>quote from the article above: "There is no guarantee that .jar ever was what people think it is." <rekado>ha, now I remember why I started packaging Java: boss asked for Hadoop. <rekado>long time ago. I'm sure he forgot already. <cehteh>\\o/ netbook installs .. it ethernet wasnt broken only dhcp had a hickup! <rekado>cehteh: there was a recent bug report about this. <rekado>something with nscd caching failures for too long. <cehteh>so lets wait, that will take some time <cehteh>Samsung NC110-HZ1 btw .. 2GB maxed out, dual core atom 1.66 ghz <rekado>(I have GuixSD on a Samsung N148, no dual core, 32 bit.) <cehteh>once installed its likely quite ok .. but i guess the installation will need some patience <cehteh>i have some older atom here as server/gateway .. its so lala, okish as long one doesnt push it too hard <cehteh>but its extremely reliable, runs 24/7 and i think i have it rebooted only 3 times in 4 years or so <efraim>sounds like your netbook is actually lower than mine in terms of underpoweredness <cehteh>well the worst is the laptop i have in my workshop :D <efraim>I'm running on an e-350, from amd's first generation of APUs <cehteh>some friend gave it to me 2002 pentium III 600Mhz with 256MB ram or so <cehteh>but i had an PATA SSD leftover some utra expensive thing <cehteh>with that it performs quite well <efraim>i had a machine like that with a great screen, but most of the ram and the hdd went bad, so I was using it with a usb stick and 78 MB of ram until more pieces fell off <efraim>I was also missing the ~ key which really drove me crazy <cehteh>excellent for workshop no internet in the cellar .. some music on it, complete english wikipedia for offline use (w/o media only texts) <cehteh>a lot datasheets, electronics books, <cehteh>and avr toolchain to flash µC there <rekado>"complete english wikipedia" --- I'd like to have a Guix package for this :) <cehteh>its not *that* big .. 15GB or so compressed <cehteh>Due to lack of time, the generation of Wikipedia archives a <cehteh>and see link to kiwix .. i dont know that, maybe i'll try that <efraim>doesn't wikipedia have dumps also available for downloads? <rekado>efraim: or else hydra would be unhappy. <davexunit>good advice about software toolchains from that article I linked earlier <cehteh>when i get guix running i really look into guixtorrent .. torrenting the store <cehteh>cant promise much but that would be really some cool thing imo <rekado>it's sad that we need a bullet point for "Buildable". <davexunit>I'm in a position at work that I can't build the very thing that manages all of our servers <davexunit>I wanted to migrate our Chef server from Ubuntu to Debian, but I failed. <davexunit>I tried and had to move on and just use Ubuntu to unblock the consultants we work with. <davexunit>to continue the theme of unreproducible software, I've discovered that Transmission's source distribution includes minified JavaScript files! <jlicht>davexunit: sounds like fun times at work. Any chance of being able to introduce guix/nix in the long run at work? <davexunit>jlicht: I hope so, but it's a hard sell until Guix can be easily relied upon without needing me. <davexunit>Nix is an easier sell because it's more popular, but I would hate for Nix to get the green light and not Guix because I know how much better Guix is. <davexunit>which I intend to build, but it's nothing that anyway will pay me to create. <mog>davexunit, im a nixos users, i thought only large difference between the two was using guile over the dsl of nix? <davexunit>and that choice cascades throughout the entire software <davexunit>and makes Guix much better from my perspective <davexunit>the UI is better, it's easier to extend, it's more consistent <mog>can you give me an example? <davexunit>our packaging policies are better because we take more care to not rely upon pre-built binaries and we document the license for every package. <mog>i agree that nixos people are less concerned with free software ideals <mog>every package file i have touched does have license properly documented thoguh? <davexunit>there was no policy in place to make sure a license was specified <mog>ill take your word for it, and celarly that is a large problem <davexunit>I don't want to make it seem like I'm relentlessly bashing Nix, because I think it's a great project, but I really do think that Guix has significantly improved upon the implementation. <mog>davexunit, i don't feel that you are doing that <jlicht>from what I gather, one of the creator(s?) of Nix has mentioned to be in favor of internal DSL's compared to external DS: <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 ;-) <davexunit>I absolutely love lisp, so guix is a great fit for me. <rekado>I don't like [common] lisp much, but I do like Scheme a lot. <davexunit>yeah, I like Common Lisp much less when compared with Scheme. <davexunit>but I'd take common lisp over any non-lisp any day <davexunit>it's interesting how CLOS is so much better than every mainstream OOP implementation <paroneayea>or, mutation to happen to something at the toplevel <davexunit>CL isn't about functional programming so that's just as well <paroneayea>my favorite thing about CLOS is the common theme of "common lisp has the best OOP system in the world but ugh don't use it why would you use OOP" <davexunit>if you're going to use OOP, CLOS is where it's at. <davexunit>I see what dto does with CLOS in his games written in CL and it's really cool if you're into OOP <davexunit>I wish it was the kind of OOP system I used at work <paroneayea>I allllmost have things so that I could try to use my guix partition regularly on the x200 <paroneayea>the main problem is it keeps resetting the hardware clock to 1970 whenever I reobot <paroneayea>davexunit: the way I first noticed was suddenly all the ssl certs on all the sites I was looking at were expired <paroneayea>okay if it were 1970, yes that'd trigger expiration I guess?? <paroneayea>I guess in a sense it's so pre expiration I'm confused as to why it would but it did <davexunit>maybe it also checks the date the cert was issued <davexunit>and since you are back in time, it's invalid <rekado>ACTION started building icedtea-3.0.0pre07 <paroneayea> command1 = as_sudo(["cat,"/etc/passwd"]) + " | grep user" <davexunit>I have no idea how to build Chef server to use on Debian because their omnibus build script doesn't work and I can't figure out why. <davexunit>so here I am relying on their binaries made for ubuntu 14.04 <davexunit>"it will download and install an outdated precompiled JDK, because it considers you too stupid to install Java." <paroneayea>"it considers the situation too complex, so it makes things more complex in attempting to make your life better" <davexunit>I can't recall the root circular dependency issue <rekado>maven needs some plugins that need maven to build. <rekado>but afaics I can do without maven if I write custom ant build files and package up all dependencies recursively <rekado>(that's what I'm doing now for log4j and dependencies) <davexunit>if Chef was tangible I'd be hitting it right now <rekado>I received three axoloti boards today: yay! <rekado>audio dev boards running free software and with free hardware designs. <rekado>I'm going to try to build a couple of audio effects for my Chapman Stick. <rekado>I like the idea behind the Moogefooger MIDImurf; shouldn't be too hard to implement this digitally. <rekado>beast is difficult to package because it depends on rapicorn, which bundles a forked version of librsvg :( <rekado>have been trying to clean this up, but it's not at all easy. The tarball also seems to miss certain m4 macros, so I cannot easily reconfigure this. <rekado>lfam: kiwix was mentioned above ;) <rekado>it looks like it wouldn't be too hard to package. <lfam>I wonder how it stores and updates the wiki files. It might not expect immutable storage <rekado>why update? Shouldn't that be done by a new release. <lfam>I'm not sure, I'm just thinking out loud. I've never used it <lfam>Next time I travel I'll bring it with me <cehteh>ratpison is a bit unintuitive as default <lfam>cehteh: We are just getting GNOME ready <cehteh>and typing with one hand on the IRC client on the computer aside sux too <lfam>Okay, but it's easy for new users, right? <lfam>I don't use any DE but I can find my way around GNONE <efraim>pages-articles.xml.bz2 – Current revisions only, no talk or user pages; this is probably what you want, and is approximately 12 GB compressed (expands to over 49 GB when uncompressed) <lfam>My ideal intuitive new system is a console with tmux <cehteh>yes i only meant as 'intuitive' xfce is ok <cehteh>aka when logging in with defaults someone should be able to use it at least <efraim>could be a propagated input for one of the readers <lfam>cehteh: I use i3 too, but a fresh user would be totally lost if the system booted to it <cehteh>e would work too .. just something not as strange as ratpoison thats a total entry barrier <lfam>cehteh: Patches are welcome :) <cehteh>i have nothing against ratpoison but it shouldnt be default <efraim>not too use about e for new users, it boots up and the screen is totally baren <efraim>my first time I thought something went wrong <lfam>Create a nice default system image declaration and send it to the ML <rekado>(to me the DE is not very important as I'm in full-screen Emacs most of the time; but I did like Gnome Shell.) <cehteh>xfce or lxde might be good default <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 <davexunit>a lot of us want GNOME, but there's no reason why we couldn't have templates for any DE someone wanted to put together <cehteh>and i am just acting as newbie .. i know that from other software where i am used to and dont understand the trouble new users have <cehteh>i liked gnome but meanwhile ist a pile of collateral damage unfortunally <rekado>lfam: I remember that civodul sent a link to a nix mailing list post about the scraping approach. <rekado>there was no real comparison made. <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. <lfam>rekado: Okay, I will search the nix ML. I could make an example of it. <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. <lfam>I don't know... I'm ambivalent <cehteh>waah .. i have the ratpoison manual open and dont find out how to exit it <davexunit>the challenge for us is to develop friendly interfaces that do not hide the power of the Scheme configuration interface <lfam>Indeed, the greatest challenge <rekado>I'd like to have a graphical config editor with input constraints. <rekado>this could be used on some other system to prepare the configuration file <rekado>(and be certain that it doesn't contain any annoying syntax errors) <rekado>(we cannot assume that people use Emacs+paredit) <davexunit>our goal is to purposely blur the line between user and developer <cehteh>not that much .. of course such a install could/should start 'nano /mnt/etc/config.scm' eventually <lfam>An editor with optional vi and emacs bindings that integrates paredit <davexunit>so we don't want to train people to rely on limited GUI <lfam>Without paredit people are screwed <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 <rekado>cehteh: having template expressions users can complete for various common tasks sounds good. <cehteh>oh ... with network disconnected i couldnt login .. the ratpoison stuff hangs somehow <rekado>the number of fields in an (operating-system ...) expression is limited, so this is totally feasible. <cehteh>and in the defaults using cons* not cons .. more generic for someone like me who doesnt know guile well <lfam>cehteh: Now you know it ;) <cehteh>yes i am just talking about the gotchas a new user has and people who learn that once dont notice anymore <cehteh>eventually guix should be as simple to install as any other distro or? <lfam>There's a balance between making it super easy (Ubuntu ISO) and empowering the user to be able to change the system at will <cehteh>damn cant control screen brightness on this netbook, where are my sunglasses? <cehteh>well see the cons* vs cons thing, sometimes making defaults more generic without compomises would be just a bit nicer <lfam>Yeah, I'm not arguing on that particular issue. I'm also pretty new to Scheme <lfam>Just saying that one Guix slogan is "the Emacs of distros" <cehteh>i hope in 'as hackabe, as universal' as emacs .. but not necessarsy 'as complicated and as strange' <rekado>"cons*" itself is not even an intuitive name ;) <rekado>not when you have a list that you want to append/prepend stuff to. <cehteh>bash completion doesnt work either .. just a note <rekado>quoting and splicing would work, but then you're already knee-deep in Scheme. <lfam>cehteh: I hope you are making notes of this stuff for you message to the ML :) <rekado>like this: `(something ,@a-list-of-stuff) <rekado>or rather: `(,something ,@a-list-of-stuff) <rekado>but that looks uglier than cons. <rekado>there's also append: (append (list "some" "thing") (list "and" "more")) <cehteh>if there is cons* in the template and one can just copy paste entries of a list it would help already <cehteh>how do i select german keyboard/locale? <lfam>cehteh: I think you can declare that in the operating-system configuraiton <NiAsterisk>de_DE.uft-8 in locale or something? I need to figure out a completely custom locale myself some time, mixture of DE,en_US and en_DK. <lfam>DK? Cool! I love it there <lfam>Interesting, I'm surprised that ISO-8601 isn't standard across all locales since it is obviously superior ;) <cehteh>de_DE.UTF-8 was not available at install time <NiAsterisk>I don't like german localization on my devices, but for some things it makes sense to use things which are standard in the country you are in <cehteh>err i cant really not figure out how to change the keyboard <cehteh>i added german in system settings from xfce ... but that doesnt change it <rekado>cehteh: change it in the config.scm and then reconfigure. <rekado>if you want the change to be permanent. <cehteh>sudo doesnt drop me into root either <cehteh>i am not used to guix or its a bug <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? <lfam>cehteh: What do you mean? <cehteh>i changed the locale setting in my system.scm <cehteh>says 'system locale lacls a definition' <rekado>have you installed the glibc-locales package? (not sure if needed) <lfam>Is that the right name for the locale? <cehteh>i wont mind to have a en_US system locale but change the user locale .. and more specifically locale can stay english, but i want to change the keyboard <rekado>what doesn't work about changing the keyboard layout? <rekado>to change the layout to dvorak I have cons'd this to my services: (console-keymap-service "dvorak") <cehteh>how do i know what my keyboard layout name would be <lfam>There must be an i18n irc channel <rekado>I believe that must be a file name in /gnu/store/...-kbd-2.0.2/share/keymaps/i386/ <rekado>cehteh: if you want a "qwertz" layout replace "dvorak" in the above expression with "qwertz" <lfam>davexunit: I just finished reading those vitavonni.de articles. Wow! What a nightmare. <rekado>cehteh: I agree that setting the keyboard layout via a service is weird. <rekado>it's less frustrating once you're all set up :) <lfam>But, it should be easier or better documented. That's why I want you to send mail to the list about your experience. <cehteh>but i will send all this issues in one mail, not one mail per issue, if anyone want that it could be forked out later <lfam>cehteh: That's fine. I just don't want these issues to get "lost" <cehteh>hydra is way too slow is another issue :D <lfam>Yeah, we are working on that :) <lfam>If you are on x86_64, there is a substitutes server at fps.io:9999. You have to decided for yourself if you trust it. The key was posted on the ML <lfam>That server is much faster than hydra <lfam>Okay, let's be fair. Most of it <lfam>It's maintained by IRC user fps <rgrau>wow, ollydbg! long time no see :) <cehteh>why do one need to trust the server anyway .. packages should be signed :D <lfam>the Intel ME is signed but that doesn't mean I trust it <cehteh>doesnt matter, someone i have a trust chain too <cehteh>but this can be established over time <lfam>I think distributed content addressing of reproducible builds is valuable. You can use `guix challenge` on the server <cehteh>just having the facility to sign packages in some most generic way would be good already <lfam>They are content addressed and (ideally) reproducible. They can't be tampered with in that case <lfam>Unless I am misunderstanding <cehteh>"herby i sign that *I* have build this package" ... good luck have fun <cehteh>yes content addressed means one need only to sign the address .. and of curse verify that the content really matches the address and the content addressing is cryptographically securew <lfam>I don't see what it gains over reproducible builds and content addressing. You'd have to break sha256 <lfam>I'm not an expert at all though. I am open to correction <cehteh>well then fps.io should be completely trustabled by your definition or? <cehteh>why is there a discussion about? <lfam>No, you'd have to `guix challenge` every package you download from there <lfam>But that's the exact same as with hydra.gnu.org <lfam>I just point it out since GuixSD comes with hydra's signature and not fps.io's <davexunit>so you must trust that someone hasn't tainted the binaries <lfam>guix challenge builds locally and compares it to the substitute server's build <rgrau>is anyone working on a docker package for guix? I think it'd ease the migration as ppl would not be so concerned about "There's no XYZ package for GuixSD". <lfam>So, if everything was deterministic, it would be a security tool. For now, it is partially a tool for finding non-reproducible build <cehteh>if there is a signature one could blame someone at least when something is wrong <cehteh>maybe accidentally maybe on purpose .. <rgrau>I'm trying to install the standalone binary version of docker. Will keep #guix informed whether I have any success <lfam>cehteh: True. I've said my part and now I defer to those with more experience on this topic <davexunit>rgrau: building docker will hopefully be quite easy once the Go toolchain is available <efraim>i have gccgo-4.9 locally, I'm working out the kinks to get that to build go-1.4 so I can use that to build go-1.5 <cehteh>and builders could do some voting if 10 people build package from source X and result in content Y and i trust 5 from them then it should be ok for example <efraim>gccgo-5 would be better, but it implements go-1.4 and needs a much more complex formula <lfam>cehteh: The goal is to have decentralized package sources. So, that network could "chat" about non-reproducible builds and isolate "bad" sources as bugs <rgrau>aha, thx davexunit. will see if the standalone works fine at least <lfam>Then, we'd analyze whether it was innocent or not. If innocent, it's a bug in the build process <davexunit>rgrau: it probably will because Go statically links everything, but of course that's not a general solution <lfam>rgrau: It should work since Go packages are self-contained. I found that the Syncthing binaroes works on GuixSD <lfam>cehteh: Care to share your operating system configuration? <cehteh>just used the template ''desktop.scm" <lfam>Presumably you made some changes for the keyboard. It's hard to help without the code <cehteh>changed timezone .. worked .. added console-keymap-service like rekado shown <cehteh>i am just a bit clueless how to copy the system config to somewhere else <rekado>openjdk8 (built with icedtea 3.0.0) can no longer be bootstrapped with GCJ :( So it needs to depend on openjdk7 (still called "icedtea7" in Guix). <cehteh>so a) how do i install some browser <lfam>`guix package -i icecat` <cehteh>i mean i am not that much n00b even if i pretend that here :D .. for the sake of simplicity .. only guix noob <rekado>I'm looking forward to the hydra upgrade. <cehteh>would be better not to rely on a central entity <cehteh>every ones /gnu/store could be served as torrent <davexunit>it's not clear that torrents are the best way to do this <cehteh>maybe not, but it would be a low hanging fruit <cehteh>no one says that torrent should be the one and only way <davexunit>substitution isn't just like grabbing a file from an FTP server, there's a protocol. <davexunit>this isn't a trivial thing that can just throw a torrent at <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 <davexunit>I'm going to run my own publish server on my VPS soon <rekado>cehteh: the store is more than just /gnu/store; there's also some additional state kept in a database. <lfam>Ah, just the ones you actually use <davexunit>yeah, I can't do much else unless I pay linode for a ton of disk or something <lfam>I suggested to fps that he build i686 too but I think he didn't have the space <lfam>davexunit: Save the extra $ for hydra ;) <davexunit>I still need to do all of my holiday donating <cehteh>rekado: yes but you can fill the store in advance, update the database, or purge things from the database and then delete from the store <lfam>Only 2 more days if you care about the tax issues <cehteh>how do i add fps.io permanently to the substitutes list? <cehteh>we may rent a new server too, which then can dontate some space and build resources <rekado>cehteh: "guix import" and "guix gc" do these things. Better not mess with the db and store contents without fully understanding how this works. <cehteh>our current machine isnt capable ... <rekado>(repeating it won't make it better) <cehteh>rekado: thats why i wanted a api which can hook into that in a safe and well documented way <lfam>cehteh: Authorize the fps.io key (see the manual) and add the option "--substitute-urls" to the command-line invocation that starts the guix-daemon <lfam>cehteh: The API is the `guix` command. You shouldn't interact with the store in any other way <davexunit>more concretely, to interact with the store, you must use a client to talk to the guix daemon <lfam>Sure, there could be more clients in the future <cehteh>well i am gotta run to bbl or tomorrow <rekado>(the guix library has lots of nice procedures to interact with the store) <lfam>Seems to violate to the spirit of the system <paroneayea>so what's the relationship between maak and guix? <lfam>Both from the brain of Eelco Dolstra 