<dmarinoj>davexunit: I'm with you, I just need to refamiliarize myself more with how quicklisp works and how to get the source conveniently <mordocai>davexunit: Aren't those what substitutes are? <davexunit>mordocai: yes, but that is a different story. <xd1le>mark_weaver: re 'patch-shebang', nice, thanks! <Jookia>mark_weaver: Unless I'm misunderstanding things, but packaging implies it takes source code and builds it, then installs it. This would take way too long for developing things <mark_weaver>Jookia: so run 'patch-source-shebangs' from guix/build/gnu-build-system.scm once in the source tree <dmarinoj>mordocai: we want to be able to build the binaries on hyrdra or wherever from source <davexunit>mordocai: whatever the equivalent of 'make install' is for asdf, that's what the output directory in the store should have for qCL packages. <Jookia>mark_weaver: Oh wow, I can do that? <mordocai>davexunit: I'm not sure if there is an equivalent... <Jookia>Wow that solves my problems then <xd1le>mark_weaver: would there be way to plug into this at the OS level? <xd1le>so when the OS looks for the #! path... <mordocai>davexunit: I mean there definitely is for programs like stumpwm, just not sure about libs <xd1le>we could give it the correct one if it doesn't find one <Jookia>xd1le: binfmt_misc *could* do something like that but it's hacky <mark_weaver>xd1le: if we wanted to do that, we might as well just add /usr/bin/env <mark_weaver>but doing anything like that automatically will lead us down a slippery slope to losing the advantages of Guix. <Jookia>mark_weaver: Thanks soo much for that, sincerely <xd1le>also, that behind the seems behaviour is probably not really that cool <davexunit>mordocai: surely there is a load path that CL implementations use to load compiled stuff <davexunit>guile has GUILE_LOAD_COMPILED_PATH, for example <mordocai>davexunit: Yeah, I'd have to research how "pure asdf" does it. For quicklisp stuff it is typically just put in .cache <Jookia>mark_weaver: It might be an interesting weekend project when I have time to integrate an 'unpatcher' as a git hook for seamless patched development. :) <davexunit>mordocai: ah, well usually there's some 'make install' equivalent. ruby has 'gem install', for example. <davexunit>Jookia: if you are doing development, you should use your build system to do this for you. <davexunit>any build system worth anything should have this capability. <Jookia>davexunit: I should, so it might make sense for me to make some scripts that help migrate projects to autoconf <dmarinoj>mordocai: asdf has an asdf install but my understanding is that quicklisp provides dependancy resolution on top of asdf <mordocai>dmarinoj: Yeah. Guix would want to do dependency resolution instead. <davexunit>we can use it as a source to import from, but we will be replacing quicklisp. <dmarinoj>davexunit: Okay, also apparently asdf-install is obsolete and now people use clbuild <mordocai>dmarinoj: Yeah, we wouldn't want to use that either <mordocai>dmarinoj: It uses quicklisp, and i'm not sure exactly what its end goal is <davexunit>surely there's some common build process for common lisp programs <dmarinoj>mordocai: Yeah, I just looked at it, same problem, it uses quicklisp for dependancy resolution <mordocai>davexunit: Yes, but the concept of "installing" a lib is foreign I think to the lisp philosophy. <mordocai>Not sure though. I'll definitely need to research it <mordocai>I know how I use lisp in my daily use wouldn't really work for guix, but that doesn't mean there doesn't exist a standard mechnism that would <dmarinoj>mordocai: Yeah, stumpwm is really nice and I would like to see it in Guix <davexunit>I don't know what lisp philosophy you are talking about <mordocai>davexunit: They aren't concerned with reproducible builds though. I'd imagine they just ship the code and let the implementation compile it on each user's machine and cache the fasls. <mordocai>Usually if I say lisp I mean Common Lisp. <davexunit>that "cache the fasls" part will be installing to some consistent load path <mordocai>I'm just not sure since I typically don't think about it at all <achilles`>okay about to try installation again on my system, but I do not want to get rid of my Trisquel partition. How do I install without getting rid of my current os? Do I resize my home folder? <mordocai>It might just also put it in ~/.cache actually. <Jookia>achilles`: You want to resize your home partition and make room for a Guix partition <paroneayea>does anyone here have a nice "git send-email" workflow that works with mu4e or gnus? <achilles`>Jookia: and then would I skip the GRUB step? <dmarinoj>mordocai: I just looked into ql-to-deb again, the csvs it pulls from contain links to source tarballs and their dependencies <mordocai>dmarinoj: To figure out deps and where to get sources <Jookia>achilles`: Hmm, I'm not sure if GuixSD has the tools to dual boot GRUB like that. <dmarinoj>mordocai: I'm just not quite sure how to build these things but I'm sure that I can figure it out by looking at the ql-to-deb source. It doesn't look that bad <mordocai>dmarinoj: davexunit: So I confirmed on my system, debian packages install the source to /usr/share/common-lisp/source/ but do nothing involving compiling. When I load a common lisp library then the standard asdf/implementation stuff kicks in and the fasls get saved in ~/.cache/common-lisp/ <Jookia>achilles`: You could certainly chainload it I think, but it'd need some tweaking and exploration since I don't know if anyone's done it before <achilles`>Jookia: it should be a feature eventually, dual booting is sort of important for lots of people <mordocai>So I -think- if we want to provide the fasls for the purpose of reproducible builds we may be in uncharted territory. Should be possible though. <davexunit>mordocai: if that is the way it works, then I suppose that's just way things will be. <davexunit>thing is, we'd like to compile and run test suites. <davexunit>if we are just copying source code, we'll never know if the software actually works. <dmarinoj>davexunit: I'm sure there must be a way to build these things into FASL's, I will look into it <mordocai>davexunit: That part should be relatively easy. Provide a chosen lisp implementation(that's another thing that probably needs discussion though it'll probably be sbcl) as input to the package along with any libs required then run the tests (which how to do so will probably vary). You'd be able to configure ASDF's source directories to be a guix store. <davexunit>CL seems really disorganized in this manner. <mordocai>It pretty much is designed for maximum dynamicism rather than reproducibility. <davexunit>Guile is also designed for this, but has a sane load path mechanism. <mordocai>davexunit: Right, but guile seems to actually care about compiled code. In common lisp world it is just an annoying side effect and having somewhere to put it allows you to save time when loading again later. <calher>I would rather things be written in any Lisp, but I try to find Guile whenever I can, because I really don't want to get another interpreter. <paroneayea>davexunit: what's guile's sane load path mechanism? <mordocai>davexunit: In any case, I think you can provide the compiled code in a package it just isn't done so I don't have anything to base off of. <davexunit>paroneayea: GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH <calher>For example, I wish Reddit would have continued to be written in Common Lisp. <calher>How do I use @code{snippet} to add lines to a Makefile? <mordocai>The primary issue is that the documentation is written for the benefit of a user wanting to configure it not a distro. I think the capabilities needed exist we'd just have to figure them out. <Jookia>paroneayea: "8 read, 0 sent, 0 receipts, 18 inbox, 6 removed, 36 fetched" <calher>mordocai: The draft I used is to be part of the manual, and it helpedme get a system. The services section was helpful in helping me block Facebook. <calher>Jookia: I can't rephrase any clearer than that. <mordocai>dmarinoj: I think we might be able to use CL_SOURCE_REGISTRY and ASDF_OUTPUT_TRANSLATIONS to configure source locations and fasl locations respectively. <mordocai>dmarinoj: The problem being it seems they want one directory and in guix we'd really want one directory per a library/program I think. <Jookia>calher: Isn't @code{snippet} Texi documentation? <calher>UTF-8 doesn't have tags for code. <mark_weaver>calher: snippet is the wrong tool for that. what do you feel the need to add to a makefile? <davexunit>"In diff-so-fancy's case, we've supported Linux and Windows from the get-go, the only hard part is getting it installed. NPM solves that problem really well, and I can't imagine any other installation technique being our recommendation for Windows/Linux going forward." <mordocai>dmarinoj: Maybe. I think the path forward may be starting a common_lisp git branch and getting something relatively simple like stumpwm to "work" then review how nice/nasty. Probably starting with only worrying about sources since that seems easier. <mordocai>dmarinoj: I feel like it isn't really keeping with the guix philosophy if we don't ensure reproducibility of fasls but that seems the harder problem <calher>Whew! gnunet_bot didn't care about ⎇! <mordocai>dmarinoj: For instance, CL_SOURCE_REGISTRY accepts multiple directories but i'm not sure how that would work for ASDF_OUTPUT_TRANSLATIONS <Jookia>calher: It only cares about your emotions <calher>Aww, how sweet! :stuck-out-tongue: <mark_weaver>calher: better add a phase before the install phase that creates those directories from guile code. <dmarinoj>mordocai: wait so how does that have to do with reproducibility? <mark_weaver>calher: but if you were going to take that approach, you'd use a patch for that. <dmarinoj>mordocai: what I was saying was that we can have it in multiple directories and then just have a dirictory with symlinks to all the binaries for common-lisp just for common lisp to use <mark_weaver>the purpose of snippets is to remove nonfree code, or large amounts of code (e.g. bundled copies of libraries), which we can't do with patches <calher>mark_weaver: How do I use @code{snippet} as well as @command{patch}? <mark_weaver>calher: you can put both 'snippet' and 'patches' in an origin. what are you using the snippet for? <mordocai>dmarinoj: Yeah, the problem from a guix point of view I think is where do you put the directory with the sym links? <mark_weaver>calher: we generally put things like that in a custom build phase <dmarinoj>mordocai: Does that matter from a functional point of view? We could just put it wherever debian puts it <mark_weaver>calher: if you search for 'substitute*' in gnu/packages/*.scm, you'll find that almost all of them are within custom phases <calher>WTF is a @acronym{CBP, custom build phase}? <dmarinoj>mordocai: I do not understand all the internals of guix <mordocai>dmarinoj: I don't think we can(for one thing on debian that place is the users home directory and debian doesn't put anything there). Generally each guix package takes in one or more immutable inputs and produces one or more immutable outputs. But if I understand correctly with some shared directory of sym links one of those inputs would have to be mutable and to change based on what packages you have installed, which is very non-guix. <paroneayea>"diff-so-fancy started as a commit in paulirish's dotfiles, which grew into a standalone script. Later, @stevemao brought it into its own repo (here), and gave it the room to mature. It's quickly grown into a widely collaborative project." <mordocai>dmarinoj: Not sure though. I really think our next step is to start just playing with different ways of doing it and seeing how it works. <mark_weaver>calher: search for 'modify-phases' and 'substitute*' in gnu/packages/*.scm to find plentiful examples <calher>Where... is... @file{gnu/packages}? <mordocai>dmarinoj: In any case, I use an IRC bouncer so i'll still be connected but i'm changing locations so will be AFK for a while. <mordocai>dmarinoj: Feel free to send me messages and I'll get them later <calher>I only have the source as root... <Jookia>calher: Download Guix using Git then use 'git grep' <xd1le>davexunit: paroneayea: re diff-so-fancy, this is what happens when people only know javascript <xd1le>it's almost as if they've discovered or invented the concept of a package manager, independently <Jookia>"git clone git://git.savannah.gnu.org/guix.git" <xd1le>for browsing online, has the git clone urls at the bottom <dmarinoj>mordocai: Now I see the issue. Sounds like a long term solution might be to hack the way sbcl does things but maybe in the short term we can work on just making it work <xd1le>calher: no, that's the cgit url <dmarinoj>mordocai: If you set up the git repository I can put the code that I had from the summer <xd1le>(which is at the bottom of the cgit page i linked) <calher>I can't just assume what the proper URI is based on the URI to the web viewer. <xd1le>calher: remember you can clone with `--depth 1` option if you are okay with just cloning the latest to do a quick search or something <calher>I don't use Git; I'm fine with cloning all of it. <calher>xd1le: I use the GNU version control system. <achilles`>okay currently in the process of installing. how come there is no /mnt/etc to start with? I am trying to make the .scm file but there is no etc folder. Is this a problem? <calher>IDK, I just did @kbd{zile /mnt/etc/config.scm} and it Just Worked. <mark_weaver>calher: I sincerely appreciate your dedication to GNU, but Bazaar was always primarily a project by Canonical, and it's been more or less abandoned, and even GNU Emacs doesn't use it anymore. <mark_weaver>I don't know off hand of any GNU project that's still using Bazaar. <calher>Yeah, because Eric S. Raymond expressed public support for it, and you know how he always is: "do what everyone else is doing! Everything will all work out if you let the market do its work! Hur-dur Libertarianism." <mark_weaver>I'm not a fan of Eric, and I don't think popularity is a reason to switch. <xd1le>mark_weaver: wait i think calher might be referring to git..? <calher>Well that was probably the reason. "OMG! Linux is huge and successful, let's use whatever they use!" <mark_weaver>xd1le: yes, he is, and I'm saying that Eric's reasons quoted above are not good ones. I have other reasons for preferring git. <xd1le>understood, just clarifying in case <mark_weaver>notably that git promotes actual decentralization, whereas Bazaar does not. <NiAsterisk>wow. the tv adaption of a song of ice and fire gets even more violent later on.. i should just read it. <Jookia>There's other projects like Mercurial if you're not happy with Git's hashes. But in Guix, we speak in hashes too ;) <xd1le>NiAsterisk: the books are much more detailed <xd1le>as in, about the characters/story <NiAsterisk>xd1le: but not as graphic, only as graphic as my imagination :) <calher>mark_weaver: 'Actual decentralization'? <xd1le>calher: git is decentralized vcs <Jookia>As in, everyone can theoretically take the repo and become the new main <calher>GNU Arch was the first decentralized VCS, xd1le. <achilles`>okay currently in the process of installing. how come there is no /mnt/etc to start with? I am trying to make the .scm file but there is no etc folder. Is this a problem? <xd1le>i thought you didn't because of your question, my bad <xd1le>(thought you didn't know what decentralization was referring to) <Jookia>achilles`: What other directories are there? <calher>xd1le: Git, SVN, Bazaar, Arch are all distributed VCSs <achilles`>Jookia: I mkdir'ed' etc and put desktop.scm there <calher>Hold on, one of those old farts were listed as distributed in the VC manual. <Jookia>achilles`: That's cool. Run it and see if it works. :) <achilles`>Jookia: I do not have high hopes, as this did not work the other day, but here we go. <NiAsterisk>on source control.. there was this thing with integrated wiki and everything which is a bit difficult to get into. <calher>Hold on, there was something in there that was friggin old that was distributed. <Jookia>achilles`: Well, I'm around for a bit longer and I'm around tomorrow and probably a few more years so I'll be happy to help you get set up. :) <achilles`>Jookia: okay thank you, I wll let you know what is going on. <Jookia>achilles`: Are you okay with being locked out of Trisquel for a bit until we figure out how to add a 'Trisquel' menu entry? If not, use --no-grub for now <achilles`>I just wiped the drive and am going full install. I backed up my home folder with all my stuff into a USB drive so worst comes to worst I can reinstall Trisquel <calher>OK, I misspoke. The decentralized VCSs include Arch, Git, Mercurial and Bazaar. <xd1le>"usb drive", i'm guessing you already know, but you probably want to back up on a harddrive, just in case <Jookia>achilles`: Oh nice to see you're prepared. Full install shouldn't be an issue then. Probably, there's a few things that might make things hard: GRUB doesn't like Mac EFI right now. <xd1le>achilles`: (if you can that is) <achilles`>Jookia: well that is why I am not using a Crapple computer for this. <achilles`>Jookia: Though I will admit I am currently using Debian on an iMac... <Jookia>Mac support needs to be fixed up a bit more <Jookia>I have some ideas but I'm not a mac user so eh <achilles`>Well yes since Mac computers are becoming so popular now, getting people to use GNU/Linux these days is getting to be more difficult <xd1le>Jookia: wait do you mean mac os? or apple hardware? <Jookia>xd1le: Apple hardware, I've heard one person having trouble with EFI support. One person too many. <achilles`>there is refind which is pretty good for me. <NiAsterisk>yay! it only took less than 30 minutes for the base system in gentoo this time, but 2 days (well in compiling time) to figure out why plasma 5 wouldn't start :D <Jookia>achilles`: I've heard it'd be better to set up EFI + blessing it somehow so we get boot menus <achilles`>Jookia: remind me...blessing? Also, on this iMac, I installed Debian without refind. So at startup, I get *white screen* then *Day-in-the-Life chime* then grub <Jookia>achilles`: Interesting, basically what Debian does then <achilles`>Jookia: strangely enough, my iMac didn't recognize Live USBs of GuixSD or Trisquel or even Xubuntu, and I couldn't even boot them. <dmarinoj>Can GuixSD be installed on an iMac? Last time I checked it didn't didn't allow booting a usb <NiAsterisk>okay, satisfied with gentoo working. now I can sleep and do some update on the CV tomorrow, as I got reply today that I could apply for the job :) hope it works out <Jookia>achilles`: Probably because they're using GRUB that doesn't support Mac EFI ;) <Jookia>I have a patch in progress for GRUB that might ease the pain with adding EFI support <achilles`>dmarinoj: yeah Debian rocks. But it has weird problems with my iMac. Sometimes using Gnome 3 will freeze the whole computer. <Jookia>achilles`: Did you run 'guix pull'? <dmarinoj>achilles`: I have had that happen to me to with Debian with GNOME, I used to run ratpoison on it just fine though <dmarinoj>achilles`: Also, Dragora with ratpoison on it ran fine <achilles`>so if guix system reconfigure creates a whole new os, doesn't this take up a ton of space? <achilles`>dmarinoj: I have never heard of ratpoison until now. <davexunit>achilles`: everything piece that is the same as a previous system will be shared. <achilles`>oh. ratpoison is like i3wm, which is what I use. <davexunit>a directed acyclic is formed, and every node is only on disk once. <xd1le>and stumpwm was created by the same person ;) <xd1le>davexunit: what's "directed acyclic"? <dmarinoj>achilles`: It's ill but stumpwm is cooler, its just like ratpoison but is written in common lisp. It's like a combination of emacs and ratpoison. That is why I am so interested in packaging it for Guix, it seems like a good fit <davexunit>often abbreviated to DAG, it's a graph that has no cycles. <achilles`>I keep getting problems with guix system: error: build failed: some substitutes for.. etc etc etc <kristofer>achilles`: it's only really been a problem for me on a guix system init <achilles`>kristofer: and this is temporary I heard, until we get new servers. <lfam>Did anyone read the pioneers patch yet? The synopsis is "A clone of The Settlers of Catan board game". Is Settlers of Catan okay with people using their trademark like that? Does it matter to us? I could change it to "inspired by Settlers of Catan". <lfam>I guess a lot of the synopses in games.scm are using trademarks <lfam>Wow I never really looked in there. There are lots of games I want to try! <Jookia>Is there a way to re-build an SVN checkout of netpbm? <achilles`>lfam: hmm I am not well versed in intellectual law... rms could help you with that perhaps <Jookia>"guix build --source netpbm --check" just uses the checkout saved from /gnu/store <lfam>Since games.scm already includes terms like "The Matrix", "Nintendo 64", and "Lemmings", I'm going to go with "...inspired by..." <lfam>Jookia: And you can't garbage collect the file because it's alive? <lfam>You could try adding --no-substitutes <Jookia>I was able to rebuild Git sources quite easily <lfam>I didn't know we could fetch SVN sources! <Jookia>--no-substitutes gives the same result <lfam>Hm, what are you trying to do? Just test the URL? In that case I think you could use `guix lint` <Jookia>I want to test some modifications I've made to svn-fetch <lfam>I would look at how `guix lint` tests address resolution and see if it will test your changes for you. <lfam>And we should also make --check handle this use case, I think. <Jookia>Unless I use a REPL, maybe that'll work <lfam>If we can redownload http and git sources, but not svn sources, I think that's a report for bug-guix. <achilles`>okay, ran into a problem. warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible <achilles`>guix system: error: failed to insall GRUB on deviece '/dev/sda <Jookia>achilles`: This is what I was afraid of. Are you on an EFI machine? <achilles`>I partitioned two partitions. /dev/sda1 and /dev/sda2 <achilles`>Jookia: I think I did something wrong. How would I do that? It also says error: will not proceed with blocklists <Jookia>achilles`: Hmm. Don't get too upset <achilles`>I am retrying to see what happens. How do I post a log? <calher>I really need tor and i can't get it to work <Jookia>achilles`: I don't know off the top of my head the command how, sorry. What's the GRUB error, or is there only a warning? <calher>I do @samp{i tor torsocks && torify @var{foo}}, and @command{@var{foo}} won't start. <Jookia>'i tor torsocks' isn't a valid command <Jookia>achilles`: I'd love to help more but I'm leaving soon. WIll you be around tomorrow? <achilles`>Jookia: okay here we go /gnu/store/bunchof numbers/sbin/grub-bios-setup: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible. /gnu/store/bunch of numbers/sbin/grub-bio-setup: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged <Jookia>achilles`: What you could do is reformat and add a BIOS Boot Partition to your GPT partition table, or use a BIOS partition table <achilles`>Jookia: okay I will try that. Would the two partitions I made not suffice? <Jookia>achilles`: It's not just the partitions, it's the partition table itself. It doesn't have room for the GRUB loader at the starting sector <achilles`>Jookia: I should do some research on this and do a better job with partitioning with fdisk... <achilles`>Jookia: could you give me a quick idea of how I could do it? <Jookia>achilles`: Sure, let me look it up <calher>Jookia: I can't start Tor. I'm not root. <calher>Jookia: To get Tor, I have to change system definition, and that's a pain. <Jookia>calher: Not anymore if it adds a new service <Jookia>calher: Can't you just load the configuration then start tor using shepherd? <Jookia>calher: Try it: The worst that'll happen is you'll have no Tor still, which is no change. You can always run Tor as root for now with a torrc like that. <calher>Jookia: @code{guix system reinitialize @var{foo}.scm}? ***nckx is now known as nckx|offline
<calher>Jookia: Oops. @option{reconfigure}. <calher>ACTION executes @samp{guix system reconfigure config.scm}. <calher>ACTION hits @kbd{C-a n} like mad before he sees any error. <calher>ACTION does @kbd{C-a n} and sees a successful SFTP download. <calher>Ah, I didn't give the origin of i3-wm. <calher>/home/cal/VC/calher-configs/trunk/config.scm:55:12: In procedure #<procedure a00c0f0 ()>: <Jookia>calher: I'm not sure, is there a backtrace <Jookia>lfam: You changed gpl2+ to gpl3+? <lfam>Jookia: Are you asking about Pioneers? The license explicitly states that I can redistribute it under any later version of the GPL. We do it often. <Jookia>lfam: Sure, but it seems... dishonest to present it as gpl3+ when it's actually gpl2+ <lfam>Jookia: The license explicitly states that I can redistribute it under any later version of the GPL. <Jookia>Guix distribution of it is GPL3+? <lfam>And we only do it when the author has taken the trouble to put such a license header in every source file. <Jookia>I was under the impression 'license' was the license of the project, not the Guix distribution <lfam>This is what is described in the license when it talks about "distribution" <Jookia>This doesn't sit well with me and I don't know why exactly <lfam>If you look at the ML archives you will see that it's a common edit to patches <Jookia>It means we can no longer combine a gpl2-only package with a gpl2+ package <lfam>The author took the time to paste this clause on the top of all the sources files: "This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version." <Jookia>lfam: Yes, but changing the license means users aren't informed of what license they can actually use the source under <Jookia>calher: screen might not be a package <lfam>Please bring it up on the mailing list <lfam>Me neither, I'm just trying to focus on something else right now, but I wanted to make my reasoning clear. <calher>It doesn't matter if people know that there's a GPLv2 version available. It's being distributed under GPLv3+ and if you're accepting it from that source that's what license you gotta abide by. Simple. <calher>If you want a GPLv2+ version, you gotta get a copy from someone who distributes it under that license. <calher>Basically: "Don't know it's under GPLv2? Forget you!" <Jookia>I think we need to rename the license field <calher>Ha! I search 'github' on DDG and get this: "GitHub is an Anti-White web-based Git repository hosting service." <lfam>There was never a GPL2 version available from our source. AFAIK it was always GPL2+ <lfam>By our source, I mean where we get the source code from. <mark_weaver>Jookia, lfam: what is the license issue that you were just discussing here? <Jookia>mark_weaver: I'm writing a reply in the mailing list <lfam>About the practice of putting "gpl3+" in the license field when upstream says "any later version." <Jookia>mark_weaver: Basically I'm shocked to learn 'license' doesn't mean upstream license <Jookia>mark_weaver: There's a practice of changing gpl2+ license fields to gpl3+, and I'm not sure. It's a common practice <Jookia>mark_weaver: pioneer, in the mailing list for now. Not sure about others <mark_weaver>lfam: what is your justification for using gpl3+ when afaict the upstream pioneers code is gpl2+ ? <mark_weaver>lfam: is there some code in there that is only available under gpl3+? <mark_weaver>if upstream allows use of the gpl2 or later, then the license field should be gpl2+ <lfam>mark_weaver: I reread the emails in my archives on this subject (regarding ifstatus and eyed3), and I did misremember our practice. I'll change it. <mark_weaver>lfam: it is up to the end users which license to choose. if upstream allows GPLv2 as an option, we do not exclude that option in our distribution. <mark_weaver>lfam: if upstream allows GPLv2 or any later version, then the license field should be gpl2+ <lfam>Yes, my memory of the discussion of this subject was wrong. <mark_weaver>lfam: please correct any changes you've made along these lines, or caused to be made by your comments on the ML. <lfam>I'm going to back in my history and see what is there <mark_weaver>and if you've taught other people to use gpl3+ when upstream says "GPLv2 or later", please make some effort to correct that misunderstanding. <mark_weaver>sneek: late tell Jookia: you were right about the meaning of our license field. if upstream allows distribution under GPLv2 or later, then our license field should be gpl2+. lfam was mistaken about our policy. <sneek>Jookia:, mark_weaver says: you were right about the meaning of our license field. if upstream allows distribution under GPLv2 or later, then our license field should be gpl2+. lfam was mistaken about our policy. <mark_weaver>sneek: later tell Jookia: you were right about the meaning of our license field. if upstream allows distribution under GPLv2 or later, then our license field should be gpl2+. lfam was mistaken about our policy. ***nckx|offline is now known as nckx
<xd1le>calher: that's just because ddg is using a cached version of the wikipedia page, where someone made that edit <xd1le>(it's been edited out now, but ddg is still using that ddg version rn) <xd1le>well it says "more at wikipedia" but yeah <xd1le>sneek: later tell Jookia: also idris has a primitive "Ptr" pointer type, so i was wrong again! don't know how i missed that. :/ <achilles`>I have installed my system, but when I select GNU with Linux-Libre 4.4.1 (alpha) on the menu, I get an error: you need to load the kernel first <achilles`>I have installed my system, but when I select GNU with Linux-Libre 4.4.1 (alpha) on the menu, I get an error: you need to load the kernel first <mark_weaver>achilles`: I don't know, I've never heard a report of that happening before. <achilles`>it says error: file '/gnu/store/qdpqjfsg2 etc -linux-libre-4.4.1/bzImage' not found. error: you need to load the kernel first. Press any key to continue... <achilles`>so annoying, I have not been able to boot to this system yet :( <mark_weaver>ah, the first error is always the one to pay attention to. <mark_weaver>achilles`: looks like it can't find the filesystem that you installed to. <achilles`>mark_weaver: I made sda1 boot sda2 root sda3 swap and sda4 home <mark_weaver>achilles`: what filesystem type? is it encrypted? LVM? <mark_weaver>MBR is a partitioning type. filesystem types are things like ext3, ext4, btrfs, etc <xd1le>achilles`: the live image doesn't boot on that system, right? <achilles`>mark_weaver: I must have screwed up partitioning <xd1le>ah, well i thought then if that works, installation should probably work too <mark_weaver>achilles`: "mount /dev/sda2 /mnt; ls -l /mnt/gnu/store/*-linux-libre-4.4.1" <achilles`>mark_weaver: I just went through the whole installation and it told me to reboot into system... <mark_weaver>maybe you didn't have the filesystem mounted when you ran "guix system init", or maybe you passed the wrong directory name to "guix system init" <mark_weaver>although if /mnt/boot/grub/grub.cfg doesn't exist, then I'm not sure how you even see a grub menu when booting from the HDD <achilles`>i mounted devsda1 to /mnt/boot when I installed <nckx>achilles`: but then there would be an empty /boot directory next to /lost+found, at least. <achilles`>I just mounted that to /mnt/boot in the live usb and that gave me grub <nckx>ACTION agrees with mark_weaver and ignores the shouty person <mark_weaver>achilles`: I guess you forgot a step somewhere, anyway. <achilles`>well... where did everything go then? this is preposterous <nckx>achilles`: ‘no because /boot is in dev sda 1’ -> but you need an empty directory to mount it to which should have been on sda1 but isn't. <mark_weaver>if /dev/sda2 wasn't mounted at the directory that you passed to "guix system init", then it probably installed to the ramdisk that the USB installer runs in. <xd1le>`mkdir -p /mnt/boot` before mount? <achilles`>mark_weaver: can you at least give me an example partitioned hard drive to do this in, as this is the fourth time I try installing guix <nckx>achilles`: maybe you forgot to start cow-store. I'm sorry, but the most likely explanation is you missed a step or typo or... Happens to everyone... <mark_weaver>achilles`: I don't know what you mean by "give [you] an example partitioned hard drive to do this in". I don't understand what you're asking for. <achilles`>nckx: ... I am pretty sure I started the cow store. But you must be right, I forgot a stem <nckx>achilles`: is dropping a seperate /boot an option (if just to try)? That would simplify things a bit (and is what I use, so that at least should work). <xd1le>ACTION emphasizes with achilles`, OS installations can be a such a pita. <mark_weaver>first-time installation of Guix is a very unforgiving process, I'm afraid. the good news is that once you get one working system installed, then later mistakes are easily dealt with by booting into an earlier system from the GRUB menu. <mark_weaver>achilles`: before running "guix system init", make sure that all of the filesystems of your system are properly mounted at the target directory. <mark_weaver>and make sure to mount the root filesystem before mounting any others. <nckx>achilles`: GRUB boots fine off ext4, so a separate /boot shouldn't be necessary. I don't have one. <achilles`>Well when I did this with sda1 as root and sda2 as swap, I got an error that there wasn't enough space to install gru <mark_weaver>achilles`: that doesn't sound right. you shouldn't need a separate /boot. <nckx>achilles`: hm. That must be a misleading error message because it can't be right. <nckx>Or at least not solved by creating a /boot partition. <root1>Hello. I'm having problems with guixsd at grub. Installation goes fine, but GRUB complains of not finding bzImage in /gnu/store/qdp...-linux-libre-4.4.1/ <nckx>achilles`: do you have the exact wording? <root1>I trying a configuration with a GPT for the disk with /dev/sda1 for BIOS boot, /dev/sda2 and /dev/sda3 for encrypted root <xd1le>mark_weaver: ^^ interesting, same error <nckx>ACTION only expects such shenanigans with GPT or unpartitioned drives, not 1MiB-aligned msdos+ext4!? <root1>I'm guessing it's because GRUB is unable to mount the partition, since it didn't ask for passphrase <root1>/dev/sda1 for me is 3M, which I think is enough <nckx>mark_weaver: [thanks, I'm losing lines.] Meh. Fine. <root1>Maybe GRUB is not having cryptomount module enabled by default. <mark_weaver>root1: indeed, our GRUB configuration doesn't do any cryptomount steps. <root1>mark_weaver: How can I instruct GRUB to do that? <root1>I thought (mapped-devices ...) would do it. ***nckx is now known as nckx|offline
***nckx|offline is now known as nckx
<root1>mark_weaver: I followed the steps in that page. <root1>But setting mapped-devices didn't helped <mark_weaver>root1: okay. that draft guide has been mostly tested by people running Libreboot, which has GRUB and its own grub.cfg burned into the boot flash. <root1>mark_weaver: Yes. Since I don't have a libreboot machine, then I wanted to try something different <root1>But I don't know why it didn't work. <mark_weaver>root1: 'mapped-devices' is handled by the code that mounts filesystems from our initramfs, but our grub.cfg creation code does not yet handle the case of an encrypted root partition. <root1>mark_weaver: What would be required to do that? <mark_weaver>for now, you'll need to type those commands manually in GRUB to mount the encrypted root partition. <root1>Already. But cryptomount hd0,gpt3 does nothing for me <mark_weaver>root1: I don't have personal experience with this, but I'm not sure it would produce any output. <root1>mark_weaver: I got an idea, will come back soon <mark_weaver>petter here on #guix is our resident expert on this. ***nckx is now known as nckx|offline
<rekado>sneek: later tell NiAsterisk Actually, the mailing list is help-guix@gnu.org, not guix-help@gnu.org <rekado>sneek: later tell achilles` Actually, the mailing list is help-guix@gnu.org, not guix-help@gnu.org <sneek>Its been said that hydra is a problem currently, but will be replaced soon <petter>sneek: later tell mark_weaver if 'cryptomount' in GRUB does nothing i think a good way forward is to insert the crypto modules with: "insmod cryptodisk" and "insmod luks". I'll work this into some documentation later. <Jookia>Time to clean up my proxy support scripts and submit them to the mailing list to get discussed/one-upped <Jookia>It's odd that Nix is dealing with documentation problems <phant0mas>on the latest master cross-gcc will fail to build for any target I tried <phant0mas>libitm, libvtv, libsanitizer configure fails to produce working binaries <phant0mas>I am testing to see if everything else works and I will send a patch <hyperreal>I'm trying to install GuixSD. The command "guix system init /mnt/etc/config.scm /mnt" fails when downloading packages. <Jookia>hyperreal: did you run 'guix pull'? <hyperreal>It says "guix substitute: error: download from ... failed 410, "Gone"" <Jookia>Yeah, it's likely that it's trying to download old packages <Jookia>mark_weaver: Would it be better to submit a patch that sets guix_localstatedir to / instead of /usr/local by default and argue it on the mailing list, or submit a patch in documentation saying 'you should ALWAYS run with this flag to configure' <Jookia>Hmm. Would it be worth bringing up the issue on the mailing list anyway? <phant0mas>it's your patch with a slight modification to apply on master <mark_weaver>phant0mas: I was confused that you changed the wrapper for the 'syscall' C library call. does 'syscall' not exist on the Hurd ? <mark_weaver>'syscall' is not actually a system call itself. it is a C library function that makes an arbitrary syscall. <phant0mas>mark_weaver: are you refering to my change in (syscall-id (match (utsname:machine (uname))? <phant0mas>there is no clone syscall in hurd so I had to a case for that <mark_weaver>also, I'd prefer to avoid the catch-all (_ #f) case for the 'syscall-id', and instead somehow detect the Hurd. I'd like a better error message when a new case needs to be added to that 'match'. <mark_weaver>phant0mas: no, I was referring to the change from 'dynamic-func'/'pointer->procedure' to 'syscall->procedure' in the 'clone' code. <mark_weaver>I understand why you need to add a case to the 'syscall-id' <mark_weaver>and what is the result of (utsname:machine (uname)) on the Hurd ? <mark_weaver>(also, if you were to change to using 'syscall->procedure', then the first argument to 'syscall->procedure' should match the first argument previously passed to 'pointer->procedure', but in the change you made they don't match) <phant0mas>1) didn't change anything, I just rebased on what was already on master <mark_weaver>phant0mas: okay, two things: the rebase doesn't take into account changes in the 'syscall' wrapper from when I originally made the patch. <mark_weaver>the arguments that I passed to 'syscall->procedure' matched the arguments passed to 'pointer->procedure' in the code at the time that I made the patch. <mark_weaver>but since then, the arguments passed to 'pointer->procedure' changed, and the call to 'syscall->procedure' in the rebased patch needs to be updated accordingly. <mark_weaver>and the other thing is that I'd prefer to avoid the catch-all (_ #f) and to handle that differently. <mark_weaver>when someone tries running this code on a new architecture, I want them to get an error message that alerts them to the fact that this 'match' statement needs a new case added to it. <mark_weaver>putting in that catch-all (_ #f) case will prevent that from happening. <mark_weaver>with a comment mentioning that this case corresponds to the Hurd where there is no 'clone' system call. <mark_weaver>phant0mas: also, you should put this in the commit log: <mark_weaver>Modified-By: Manolis Ragkousis <manolis837@gmail.com> <mark_weaver>and Co-Authored-By: Manolis Ragkousis <manolis837@gmail.com> <mark_weaver>well, I guess just the Co-Authored-By is fine. that will obviate the need for the other one. <mark_weaver>hyperreal: in any case, I would try repeating the command <hyperreal>mark_weaver: yes, Jookia suggested I run 'guix pull' before repeating the command, and it seems to be working now as far as I can tell. <rekado>I'm not typing fast enough, it seems. Other people reply to emails with mostly the same comments as I do, but they always beat me to the punch :) <cbaines>Any tips on using the gdm and gnome-shell (rather than slim and window maker)? When I run gnome-shell --replace, I get an error message (BadAccess (attempt to access private resource denied)). <davexunit>just add gnome-shell to your system package list <davexunit>and you'll be able to choose a gnome session at the slim login screen <rekado>latest news from Guix vs Conda: Guix has won. <Steap>rekado: isn't Conda a Python thing ? <rekado>we still need to use it for the Galaxy platform, but the experience of having to deal with Conda compared to the experience of using Guix has convinced my colleague of learning Scheme. <rekado>Steap: it's written in Python, but it's used as a general purpose package manager. <Steap>rekado: I think it was mentionned as a possible backend for tox <rekado>packages are yaml files + bash(+bat) scripts <rekado>the bash scripts could run whatever they want. <rekado>conda doesn't give any guarantees. <rekado>it silently uses system libraries or tools when they are not declared. <Jookia>Why use something that gives no guarantees <rekado>my colleague fought with the pandoc package for a while because it used his outdated GHC on Ubuntu and was thus linked with an incompatible version of libgmp... <rekado>and the package quality is very ... mixed. <rekado>one package just wrapped a precompiled binary, which of course didn't run on any other system but where it was built. <rekado>there seem to be a lot of these conda packages out there. <rekado>many packages also abuse the bash scripts to download dependencies because writing packages is tedious. <rekado>so you cannot mix and match packages from different sources. <rekado>latest problem: you cannot really package stuff that uses different versions of python. <davexunit>rekado: that Spack dev on HN has shown me that we need to put out more material about making custom packages. <rekado>our pipeline uses a tool that needs python2, but it also uses snakemake, which needs python3 <davexunit>he seemed unable to separate the concept of a file and a value in a programming language. <rekado>conda refuses to install our tool's dependencies because of this conflict. It's terrible. <rekado>davexunit: re Spack: yes, I agree. <rekado>I got a little tired of talking to them, to be honest. <davexunit>Jookia: a developer of a "competing product", so to speak, said that making package variants in Nix/Guix is tedious because you have to copy the entire package file. <davexunit>what he does not yet understand is that there is no "package file" <rekado>spack offers a convenient command line syntax for swapping out parts of the toolchain. <rekado>e.g. replacing GCC with some other compiler. <Jookia>davexunit: I'd have thought that of all package managers Nix/Guix is one where you don't have to do this <rekado>but it seems that only toolchains are treated specially. <davexunit>rekado: yeah, we should have convenient CLI syntax for it, too, and we're getting there. <davexunit>the *real* power, of course, lies in writing procedures that take packages as input and produce packages as output. <rekado>I don't know why compilers should get special treatment. <davexunit>I used such a procedure recently on my game engine project, to convert dev package tree using guile 2.0 into one using guile-next. <rekado>with the package transformation framework we can change *any* input on the command line. <davexunit>glibc CVE: are we affected / have we patched / rebuild the world again? :( <rekado>(besides: I was never a fan of a terse command line syntax that reminds me of regular expression commands) <davexunit>rekado: that spack command line syntax is ugly. <rekado>last thing I know is that they were slow <Jookia>I heard they only work with direct dependencies, not indirect ones <Jookia>Haha, I have a feeling that's too low level for me if smarter people haven't fixed it <davexunit>we really do need to rebuild the world for this glibc patch <rekado>are grafts disabled somewhere? I see in guix/derivations.scm that "%graft?" is #t by default. <davexunit>if anyone is available to apply that patch and post to the mailing list about the critical need to push this to security-updates and rebuild, that would be great. <davexunit>mark_weaver: yeah, I haven't looked at it closely enough to know exactly what work we need to do. <davexunit>all I know is that it's making a pretty big impact in tech news today, and it certainly seems bad from the little bit I have read. <davexunit>and of course there are the usual "rewrite glibc in Rust" comments <davexunit>well, we could get 0.9.1 out the door and prioritize working grafts for the next release. <davexunit>are the issues with our broken grafting system documented? <SylvieLorxu>I'm just reading up on Guix, does it use Linux-libre as kernel? <rekado>SylvieLorxu: GuixSD uses Linux-libre. <SylvieLorxu>rekado: Ugh, I keep switching them up. The names make sense but they're so similar. Linux-libre makes sense, because hardware support, cool too to have more fully Free systems, thanks for the quick reply <Jookia>NixOS is a lot less polished than GuixSD <Jookia>GuixSD also reflects the goals of the free software movement much better <SylvieLorxu>Well, yes, that's obvious. Being a GNU project I can be sure than GuixSD won't have non-Free packages. Still, aside from that, I can't find many differences <Jookia>SylvieLorxu: It has good documentation, easy to remember command line arguments <SylvieLorxu>Although GuixSD seems slightly more consistent because it seems to consistently uses Guile <rekado>I could not find where the grafting mechanism is globally disabled. It seems to be enabled, but I don't see it in action when updating. <Jookia>Have you read the manual? It may answer a lot of the questions <SylvieLorxu>I skipped through it, but it seems rather huge and I don't really know where to start <Jookia>Start at the beginning, then when at the end, stop. ;) <Jookia>In all seriousness, read what's interesting to you <Jookia>GuixSD and Guix are two different but very interesting projects <Jookia>davexunit: One's an operating system, one's a package manager <Steap>yeah, they kind of are the same code <Steap>though you can use the package manager without the whole distro <Jookia>Same code, same repo, but different purposes and different goals? Or perhaps I'm seeing lines where there aren't any <davexunit>but you can still use it to instantiate GuixSD systems, even if you are on a different distro. <davexunit>Jookia: it's a different use-case for the same software. <Jookia>SylvieLorxu: Use the GPG signature <Jookia>davexunit: Interesting, I wonder why they have two different names then? <SylvieLorxu>Also, blah, this may be the only system I've ever downloaded that doesn't come with vi <davexunit>Jookia: well, we still want to distinguish using the package manager from using the full distro. <SylvieLorxu>davexunit: Yes, but with GNU/Linux systems I sometimes end up without network after an install and need to edit config files, so that'll be difficult in that case :P <Jookia>davexunit: Does this mean Guix isn't intended for use on other distributions? <davexunit>using Guix on the distro you are comfortable with eases the transition to GuixSD. <davexunit>because naturally if you really like using Guix, you'll want to manage your entire system with it eventually. <rekado>SylvieLorxu: with the guix installer USB image you'll also end up without networking. You'll have to enable networking manually (using ifconfig and dhclient ...). It's explained in the manual, but it isn't trivial if you haven't done this before. <SylvieLorxu>rekado: I vaguely remember doing that, but with WiFi it may be messy <rekado>davexunit: I wish I could use GuixSD on my servers here at work. Alas this won't be possible soon. <rekado>SylvieLorxu: yeah, WiFi requires wpa supplicant <Jookia>SylvieLorxu: There's instructions for WiFi in the manual (or a draft that's been floating around) <SylvieLorxu>$ gpg --verify Downloads/guixsd-usb-install-0.9.0.x86_64-linux.xz.sig guixsd-usb-install-0.9.0.x86_64-linux.xz <davexunit>I think eventually GuixSD will be a viable option. <SylvieLorxu>gpg: Signature made Wed 04 Nov 2015 09:54:26 PM CET using RSA key ID 3D9AEBB5 <SylvieLorxu>Some instructions on the download page would be useful :P <davexunit>once we have a good number of useful services and shepherd is capable of handling some trickier service upgrade use-cases. <Jookia>SylvieLorxu: You need to --recv-keys <rekado>davexunit: I think I'll use GuixSD on the server that runs guix-daemon. Seems simple enough as a first system to remove from puppet. <Jookia>SylvieLorxu: gpg --recv-keys 3D9AEBB5 <davexunit>when our build farm is beefier and faster, I'd like to attempt to work Guix into the deployment system at work. <davexunit>SylvieLorxu: gpg --keyserver pgp.mit.edu --recv-keys 3D9AEBB5 <Jookia>SylvieLorxu: You should set up GPG <SylvieLorxu>This requires trusting another third party as well, it seems <Jookia>You could meet Ludovic in real life and verify keys if you want <SylvieLorxu>I don't see why a sha1sum on the Guix site wouldn't work, right now it's apparently a good signature, but it still gives me warnings and... it is so much harder to figure out if a download went right <Jookia>shasums don't have a chain of trust <davexunit>because the evil GPL says that he can't use GNU Readline in his BSD licensed project that offers *more freedom* to users <SylvieLorxu>Ah, so that's why most permissively licensed software I use doesn't have a vi mode in the text input <Jookia>Doesn't the evil GPL just say you have to make the combination GPL, not your BSD sourcec ode <Jookia>Or do people not undersatnd this <Jookia>It's amazing that it's okay to use BSD code in a proprietary program but not copyleft <taylan>Jookia: in the BSD mindset, limiting some developers' freedom to create proprietary software that exploits the free software in question is unethical. <Jookia>Oh well, I can't live without vi-keys readline so it goes in all my code <pizzaiolo>I always use an RMS haiku to respond to that <taylan>(of course they would argue whether the usage of the word "exploit" is justified there) <pizzaiolo>"Using GPL / is encroaching on our right / to encroach on yours" <Jookia>Me too, even if I'm not a haiku fan <taylan>I think you swapped the our/your there :P <taylan>oh, or not. works both ways I suppose. <pizzaiolo>aggressively fighting for code that can be proprietarized <pizzaiolo>rewriting crap just to avoid user freedom protections <Jookia>Let's not generalize here- a lot of them just believe in a different brand of freedom or don't want to enforce licenses. It's a big faultline in the free software community to argue these things so it's probably best we look on the positive side <cbaines>Where does slim (what I think I'm using, as I am just using the default display manager in GuixSD) have the option to select window managers? ***wgreenhouse is now known as grinhaus
<davexunit>feel free to hack on using GDM instead, we would all appreciate it. ;) ***grinhaus is now known as wgreenhouse
<cbaines>F1 did not seem to do anything (I tried before and after entering my username) <cbaines>Tried that, and some more key mashing... nothing seemed to give me any options... <cbaines>(yes, I am using IRC from my Guix system also, so I keep logging out and back in again) <Jookia>Oh I see. Hmm. I'd have to log out of my system to see how to switch sessions in slim. Have you tried clicking places or presing ctrl or alt + f1,f2,f3... or 1,2,3..., or reading the documentation <cbaines>I have some of that, do you know where the configiuration files will be? (I don't have /etc/slim.conf) <Jookia>They should be in your /gnu/store-* somewhere <cbaines>So slim is in my store twice, how do I work out which one is in use? <cbaines>I have ran guix system list-generations <taylan>cbaines: you can see the destination of the symlinks in your profile <Jookia>Perhaps it's in /run/booted-system/etc <taylan>cbaines: like say via: ls -l ~/.profile/bin/slim <cbaines>and the config files in the two store locations are the same <cbaines>Should there be something about the gnome-shell in the slim configuration? <davexunit>cbaines: the slim binary will be referred to directly in the service configuration for shepherd <davexunit>so you wouldn't find it in the system profile <davexunit>cbaines: and re: gnome-shell: no. slim scans the system profile for .session files and uses what it finds. <davexunit>installing gnome-shell to the system profile is all thats needed for slim to be aware of it. <davexunit>I tried out gnome-shell recently and this is all that I had to do. <cbaines>When you say scans the system profile, which directory (or tree) is it looking in? <davexunit>cbaines: the list of packages in the 'packages' field of your OS config <cbaines>Ok, so I have gnome-shell in there, and I think reconfiguring afterwards worked (apart from still no gnome-shell. <davexunit>something isn't quite right, but I know this process works. <davexunit>do you have multiple DEs available? F1 in slim cycles through the list <cbaines>I'm really struggling with finding things, I have found shepherd in the store, that must know about slim, but there is no mention of slim in that package... <davexunit>cbaines: because that just includes the shepherd software itself <davexunit>looking through the store manually isn't a good workflow <cbaines>I'm not sure what the best next step is, but finding the slim configuration that is in use would probably be good <cbaines>How do I get that without looking through the store manually? <bavier``>cbaines: I think slim just looks in /run/current-system/share/xsessions <bavier``>and lists sessions for any .desktop in that directory <cbaines>Ah, I don't have a /run/current-system/share directory/file/symlink <davexunit>perhaps gnome.desktop lives in another package output <mark_weaver>bavier``, davexunit: I'm working on the glibc security update <rekado>davexunit: are your wip patches for "guix environment --save" available somewhere? I want to write "guix environment --load /path/to/profile", which should spawn a subshell where "guix package --search-paths=prefix" is eval'd. <davexunit>rekado: I haven't written anything for that, yet. <davexunit>only to build/use a profile that's now in master. <davexunit>the number 1 thing I want to fix in 'guix environment' is how I can't C-c in the sub-shell <rekado>I experienced the same! I thought it was something I broke in my Emacs configuration <cbaines>So I do have a gnome-shell.desktop file, but its in /run/current-system/profile/share/applications/ <cbaines>davexunit, No problem, I'll try rebooting now <paroneayea>I'm unsure as to when I want to include propagated-inputs in my python libraries vs inputs <mark_weaver>I'm going to do the unthinkable and mutate my store to fix this glibc bug. <mark_weaver>not good, but I don't want to wait a week for this fix, and without working grafts I see no other good option. <Jookia>mark_weaver: Oh no! Manual grafting?! <Jookia>How much work needs to be done on grafts <davexunit>mark_weaver: I hope civodul comes around again soon so we can discuss this situation. <Jookia>I was about to ask: Is Ludovic okay? <davexunit>he announced that he was taking some time off awhile ago. <davexunit>daviid: it's a technique by which we can apply security updates to software without completely rebuilding everything that depends on that software. <cbaines>davexunit, So I think adding gnome-settings-daemon to packages was also needed <Jookia>A tradeoff functional packaging makes is that when you update something low in the stack everything about has to be rebuilt. Grafts are a way to get around this <Jookia>I'm sitting here on my machine running an un-upgradeable NixOS wondering what to do <davexunit>cbaines: there's a 'gnome' package that will be added to master soon that will make this easier. <cbaines>As starting gnome failed otherwise (but I did get the option :) ) <cbaines>I now have a even more ominous error screen (the previous gave the option to logout, this one does not) <davexunit>cbaines: instead of adding all of these individual components, you'll just add 'gnome' to the list and be done with it. <cbaines>The message in /var/log/messages says something about assertion G_IS_SETTINGS (settings) failed <paroneayea>mark_weaver: do you think I should add "improving grafts" to the gsoc list? <NiAsterisk>is there only svn support to git in guix when I install magit-svn ? currently git svn is not available.. <sneek>NiAsterisk, you have 1 message. <sneek>NiAsterisk, rekado says: Actually, the mailing list is help-guix@gnu.org, not guix-help@gnu.org <davexunit>paroneayea: I don't think it can wait that long. <davexunit>mark_weaver is proposing to delay the next release until we have something acceptable. <paroneayea>the number of world rebuilds that have been necessary lately have been... pretty high <Jookia>I wonder if it'd be best to work under the assumption that there'll always be this many world rebuilds <paroneayea>Jookia: I think that's the goal of getting grafts by next release, then <paroneayea>and yeah, all evidence seems to point to "yes, you should assume that" <NiAsterisk>you are packaging gnome? without systemd? wow :O that's even a trouble on gentoo, gnome just forces you to use systemd there <davexunit>NiAsterisk: I have used gnome shell on guixsd <davexunit>there's a blocker bug there, for me at least, but it does work. <davexunit>many daemons that gnome wants to talk to were not running <NiAsterisk>hm. so, coming back to the question, I need magit-svn for git svn in guix because nothing else shows up in a searc hfor svn. ? <efraim>do we have it as subversion in version-control.scm? <cbaines>I am using GuixSD, and ntpd respawns about every 3 seconds (I noticed this as my window manager is broken so this is just scrolling down the screen), is anyone else experiencing this? <Jookia>I picked the wrong day to rebase against master <NiAsterisk>but installing subversion does not enable git svn clone , so I guess git in guix is build without svn support. <Jookia>NiAsterisk: Hmm, maybe fix that? :) <NiAsterisk>later.. i only want to take a look at the OS code of the company I apply for :) it seems to be in svn <mordocai>NiAsterisk: I thought svn was an output of the git package but not sure <mordocai>No problem. Only knew cause I had to figure out the same thing for send-email :P <Jookia>I wonder why it is that --no-substitutes on the daemon stops substitutes when running 'guix build', but '--cores' on the daemon is overriden by 'guix build's defaults. Is this a bug I should file? <mordocai>NiAsterisk: did you guix package -i git:svn? <mordocai>Do we have a notify/memo bot for this channel? <davexunit>sneek: later tell mordocai sneek is a good bot. <sneek>Welcome back mordocai, you have 1 message. <sneek>mordocai, davexunit says: sneek is a good bot. <NiAsterisk>but I meant I can't get the svn repo this way.. not shure if it's just down, the last master.tar.gz is still avaliable <roptat>how do I specify the keymap I want to use on the tty? <mordocai>sneek: later tell dmarinoj I have a gitlab mirror at https://gitlab.com/mordocai/guix. If you make/have a gitlab account i'll add you to my mirror and you can push up a branch with your work from this summer. <paroneayea>I guess I'm going to switch back to debian during this week while that cve gets fixed. <mark_weaver>I'm thinking of mutating my store to fix it, but it will have to be done carefully <mark_weaver>hmm, actually, it occurs to me that doing this will be difficult. <paroneayea>I guess there probably aren't a lot of people in guix who can work on the grafts feature themselves <mark_weaver>it's tricky. civodul tried to do it and managed to get it wrong. <roptat>mark_weaver, thanks, but I don't understand how to use it <mark_weaver>roptat: add (console-keymap-service "foo") to the 'services' section of your OS config, where "foo" is an argument that can be passed to 'loadkeys' <mark_weaver>maybe I need to pull an all-nighter and figure out what civodul did and how to fix it <mark_weaver>I outlined a correct algorithm here on channel before he started his work on it, but I guess he did something different. <cbaines>I can't get xfce to work either, I get the option in slim to login to xfce, but I get "Unable to load a failsafe session" <cbaines>At least the error message is a bit clearer than the Gnome (something does not work...) <cbaines>I'll try adding dbus and reconfiguring (although I though that would not be necessary, as xfce should depend/propagate what it needs?) <Jookia>mark_weaver: If there's anything I can do to help I'm up for it since I'm being a night owl myself <mark_weaver>Jookia: thanks, but I don't know how to split the job up into multiple pieces, nor even really how to delegate it. <Jookia>mark_weaver: Maybe it's not possible that way. Though if you have a good design in yoru head you should probably just get that written down ASAP <Jookia>On another note somebody on the Nix development list showed how they used 'system.replaceRuntimeDependencies' to replace their glibc. It took 25 minutes on their desktop machine <mark_weaver>I wrote it here on channel long ago, I could probably find it again. <Jookia>On another note once I get GuixSD on my T400 working I'll probably be packaging ColorHug <paroneayea>thank you, disturbingly accurate google search results! <NiAsterisk>never thought redoing my CV would take an entire day :/ <cbaines>davexunit, So interestingly, after adding dbus, pulseaudio and gnome-terminal to the packages list and reconfiguring, I did have something that looked like gnome-shell (although a bit broken) for a few seconds before it crashed. <cbaines>but xfce still gives me the same error message <SylvieLorxu>So, played with GuixSD a bit and I must say, I'm quite impressed. Maybe I'll switch from Debian to it, it seems a very well thought-out system, both flexible and simple, something I can't say anymore of modern GNU/Linux distros. Definitely need to play with this a lot more <Jookia>SylvieLorxu: It's great isn't it? :) <davexunit>yeah, I enjoy it a lot. still plenty of rough edges and missing packages, but it's pretty solid and fun to use. <Jookia>davexunit: I enjoy that I can contribute to it using free software :) <mordocai>Yeah, the only things keeping me from switching from debian to guixsd is the current rough edges and my addiction to non-free video games <SylvieLorxu>I've already had various cases where I had issues like shutting down taking ages because systemd got stuck trying to figure out how to properly stop NTP, things like that. Seeing how GNU/Linux is all going to be systemd going forward, together with the fact that systemd is a constant source of issues for me, GuixSD may very well be what will at very least get me through the years until systemd finally <SylvieLorxu>By then, I may not even care about standard GNU/Linux anymore :P <SylvieLorxu>And seeing how I recently switched from KDE Plasma to i3, my most important packages already seem to be on Guix <SylvieLorxu>I kinda regret not checking out any Guix talks at FOSDEM now :P <davexunit>SylvieLorxu: full disclosure: we use the GNU Shepherd init system that is less mature than systemd. <SylvieLorxu>davexunit: I've tried my fair share of init systems, I have my doubts it can cause me more issues than systemd :P <SylvieLorxu>No system is perfect, but I've never ran into so many issues in such a short timespan as I have with systemd <davexunit>it's lacking some features that I would need to use GuixSD in "production" <Jookia>Can't we just manually reload at the moment or am I mistaken? <davexunit>the particular test of this feature for me will be this: reloading nginx config or replacing the nginx binary entirely without downtime <davexunit>nginx supports both of these things, now it's a matter of making shepherd smart enough to handle it. <Jookia>It's very nice to see dogfooding happening <SylvieLorxu>NiAsterisk: Using the software you're trying to "sell" <SylvieLorxu>Basically, you write software you'd want to use yourself as well, so you actually care about the quality of it <davexunit>we mail some Purina Dog Chow to everyone that donates to us. <SylvieLorxu>( Could you imagine if Microsoft would dogfood IE? ;) ) <SylvieLorxu>(Maybe webdesigners wouldn't be in constant agony then) <SylvieLorxu>On a more serious note, dogfooding is great, I notice this myself all the time <SylvieLorxu>But the ones I actually (want to) use myself are the ones that are most usable and stable <Jookia>SylvieLorxu: Get ready to convert your scripts to autotools to fix your shebangs <Jookia>SylvieLorxu: It's dramatic but in short: /usr/bin/env is broken, don't use, Guix doesn't have it. So if you have shell scripts, add some autotools or some kind of script to fix shebangs <SylvieLorxu>Hmm, I just realized that Guix may finally help me figure out what the dependencies are of my GUI password manager <SylvieLorxu>Jookia: I currently user #!/bin/sh, guess that's wrong too? <Jookia>SylvieLorxu: That's the only shebang that's correct! <Jookia>SylvieLorxu: After dding the ISO does LIbreboot pick it up using the menu item? <SylvieLorxu>Jookia: I actually forgot to try, went for the set root option <NiAsterisk>I added 3 years to my CV and it kinda looks better than 2013 me <SylvieLorxu>Jookia: GuixSD's GRUB prints a few errors so you need to hit enter once, but it works perfectly after that ***francis7 is now known as fchmmr
***fchmmr is now known as sanctuary
<efraim>so I know it's not new, but `guix environment guix -- make` is great for running make and dropping me back into my shell afterward <roptat>mh... I'm trying to put configuration for booting my archlinux in my configuration.scm file, but it doesn't compile : source expression failed to match any pattern, which is not very explicit I think <dannym>efraim: does "my shell" mean that it stays inside the guix environment or that it leaves it again? <a_e>roptat: This looks like a syntax error, bad parentheses, this kind of thing. <efraim>dannym: it leaves the guix environment shell <roptat>I don't really know what I'm doing... ***sanctuary is now known as francis
<mark_weaver>roptat: if you post the failing OS config somewhere, I can take a look ***francis is now known as sanctuary
<dannym>errr oops. Is that bugtracker submit@debbugs.gnu.org not only for guix stuff? I think I just annoyed lots of upstream people accidentally.... <roptat>I'm completely lost with the syntax <dannym>mark_weaver: thanks! What do I do with the ones I just submitted? Resubmit or wait for it to be reassigned somehow? <roptat>mark_weaver, I think the javascript is free <roptat>"ZeroBin is a minimalist, opensource online pastebin" <mark_weaver>roptat: I don't want to run javascript just to read some text <mark_weaver>if you want me to look at it, please post it somewhere that doesn't require me running code. <mark_weaver>roptat: well, for starters, you need to put (use-modules (gnu)) at the top, to get the definitions of the 'use-package-modules' and 'use-service-modules' macros. <roptat>oh, yes, I didn't copy the first line, sorry <dannym>lfam: I accidentally used submit@debbugs.gnu.org to submit guix bugs (Package field for the guix package)... oops. Could you fix those up? <dannym>Also, when I properly use bug-guix@gnu.org in the future, do I add a "Package" field which is not saying "guix"? <lfam>When I send mail to bug-guix, I don't use any of the special debbugs formatting. <dannym>lfam: yeah, but how does one know which package (in the sense of gnu/packages/*.scm define-public) is meant? Just infer from the text blurb? <lfam>Yeah, and sometimes the bug isn't about a package. There isn't any harm in using the special format, though. <roptat>so mark_weaver, can you find anything? <dannym>aha, sending mail to control@debbugs.gnu.org , with a body like "reassign 22704 guix", worked. <dannym>doesn't send notifications out, though <mark_weaver>roptat: replace '((menu-entry ...)) with (list (menu-entry ...)) <mark_weaver>roptat: and if you had given us the entire error message, it would have made it easier. <mark_weaver>the error message I got was: Throw to key `match-error' with args `("match" "no matching pattern" (menu-entry (label "Archlinux") (linux "/boot/vmlinuz-linux") (initrd (gexp "/boot/initramfs-linux.img"))))'. <roptat>sorry, I tried other things after that, so the message changed <roptat>but what's the difference between (list) and '()? <mark_weaver>roptat: 'list' is a procedure, so its arguments are evaluated. '(...), which is a shorthand for (quote (...)), does not evaluate anything in there. it's literal syntax. <mark_weaver>so (list (menu-entry ...)) returns a list containing one record <mark_weaver>'((menu-entry ...)) is a literal list containing another list whose first element is the symbol 'menu-entry', etc. <mark_weaver>the 'menu-entries' field expects a list of records, not a list of raw s-expressions <roptat>ok, I'm quite new to scheme, so I got confused... anyway it works now, thanks for your help :) <roptat>what would you use '(...) for then? something like eval? <davexunit>roptat: in Guix, sometimes we create lists of strings to represent a set of make or configure script flags, and the quoted list is nice: '("--prefix=/foo" "--with-libfoo") <mark_weaver>roptat: it can be used when nothing in there needs to be evaluated <mark_weaver>quasiquote allows selected portions within to be evaluated <roptat>ah, so it's still a list then, except that nothing in it is evaluated, right? <mark_weaver>`(foo bar ,(+ 1 1)) which is shorthand for (quasiquote (foo bar (unquote (+ 1 1)))) evaluates to (foo bar 2) <mark_weaver>so another option would have been this: `(,(menu-entry ...)) <roptat>I think I understand this better now, thank you <fhmgufs>mark_weaver: I'm also new to scheme and would like to understand that. Am I right with: <fhmgufs>and `(abc xyz) allows to choose sth to evaluate with ,(abc) ? <fhmgufs>I mean for example `(abc def ,(abc def)) ? <roptat>how is a build environment constructed by guix? in my understanding, it creates symlinks to executables and libraries somewhere, and points PATH and other environment variables to it. Is that correct? <fhmgufs>taylan: I think I know the most things as I already used LISP in Emacs for example. I just sometimes didn't really know what the syntax I'm copying from somewhere means. <mark_weaver>roptat: the build logs print out the environment variable settings near the beginning of each build. <NiAsterisk>hrm. can I exclude libreboot and vigra somehow from package -u ? or should I just remove it from profile as long as it vigra fails? <mark_weaver>NiAsterisk: guix package -u . --do-not-upgrade libreoffice vigra <mark_weaver>it is a regular expression that matches any non-empty string <mark_weaver>you can get away with leaving it out if -u is the last option, but otherwise it's needed <roptat>so, how "secure" is it? couldn't a package reference another one that is not set as a dependency? <mark_weaver>roptat: no, because the builds are done within an isolated container, with a private filesystem namespace (i.e. chroots), no access to the network, etc. <roptat>so you specifically put only declared dependencies in the container? <mark_weaver>symlink trees are not using during the builds. variables like PATH just reference all of the relevant /gnu/store/... directories <mark_weaver>(and the runtime dependencies of those declared dependencies) <mark_weaver>build systems also include "implicit" inputs, e.g. gnu-build-system includes things like gcc, binutils, coreutils, etc. <mark_weaver>when package objects are converted to bags, which is a lower-level representation, all of those implicit inputs become explicit. <mark_weaver>and from bags they are converted to derivations, which are serialized as *.drv files, and what the daemon works with. <NiAsterisk>does guix base rely on glibc? did someone try musl, uclibc before? I'd like to try at some point - where I understand hardening and guix better - to give something similar to project:hardened in gentoo, for guix a try. <davexunit>NiAsterisk: yes, guix absolutely uses glibc. <mark_weaver>NiAsterisk: supporting other C libraries is not a goal for us. We are building the GNU system. <mark_weaver>of course you can do whatever you want in your own branch <pizzaiolo1>mark_weaver: is there a list of missing GNU packages to be ported to guixSD? <mark_weaver>but using a different C library would surely result in a *lot* of broken packages further up. <mark_weaver>and fyi, last I checked, bdwgc, a.k.a. libgc, the garbage collector used by Guile, didn't work with musl. <wingo>i just got hit very nicely with the guix refresh version sledgehammer :) <wingo>ACTION trying to update x packages <mark_weaver>wingo: the 'wip-xorg-server-1.17' might be of some assistance, dunno. <NiAsterisk>mark_weaver: and it shouldn't, right now, because that's not the focus of a growing system, and it's not even my main focus right now, but when I start getting busy with trying to apply some features, maybe this could succeed. future purposes are weird. let's talk about it when there's something to talk about. just mapping out things I'm interested in :D <mark_weaver>every time I try to update Xorg, we lose some drivers, and others needs to be patched to update them to the latest APIs. <wingo>i think i will try to use the updater i wrote, there are lots of updates and hopefully that brings the drivers along too <wingo>when i have had driver compilation problems, updating the driver fixed it <wingo>i got a full build but then i had no mouse or keyboard at the login prompt, thought it was probably some libinput thing so i proceeded on the big update <mark_weaver>if things have improved, that's great. a year ago, many of the drivers were mostly unmaintained. <mark_weaver>wingo: if you want to update our X packages, that would be much appreciated :) <wingo>for intel drivers, the strange thing is that all distros package intel from git <wingo>will try to get it working, with the updater it's much easier :) <wingo>it bungles the versions because it does a global s/old-version/new-version/ on the file but at least it gets the hashes right :) <mark_weaver>last time I did this, I remember it was well over 100 commits, and I did it all manually. <pizzaiolo1>yeah, I suppose mailing lists fill that function <mark_weaver>nice things about mailing lists: people can choose their email clients from a very wide variety. <NiAsterisk>mark_weaver: iirc there are also forum softwares which enable mail to forum communication.. but i have little clue about todays forums <Jookia>doesn't gnu mailman 3 look just like a forum <mark_weaver>many other solved problems like allowing you to find the messages you haven't yet seen, etc. <pizzaiolo1>NiAsterisk: true, Trisquel's forum enable mail to forum <NiAsterisk>some people break threads with their mailclients.. even when my client captures Re: and Aw: replies, some still manage to break <NiAsterisk>not in defense for forums, because you need moderation for those <mark_weaver>with web forums, there is no choice of what software to use. you're stuck with whatever code is running on that site. <mark_weaver>and barring hacks, it's a pain to type in the text with anything other than whatever editor is implemented in javascript. <NiAsterisk>and I guess mail clients already solve the accessibility, where you need to check this for forums <NiAsterisk>as long as the lists are not several thousand messages per day it's okay imo ***sanctuary is now known as francis7
<Jookia>Some people like using web browsers, surely it's worth seeing if there's an easy mail bridge to set up for them. I know mailing lists were hard for me to understand when joining my first one <mark_weaver>Jookia: having multiple fora for discussions forces anyone who wants to keep on eye on things to use *all* of the fora. <Jookia>mark_weaver: But it'd be to the same mailing list, just a web GUI for those that don't like mailing lists. Unless I'm missing something <mark_weaver>Jookia: there's gmane.org for people who want to use web browsers to read our mailing lists. <Jookia>Yep, but I'm talking about posting to it. Unless mailing lists aren't as big a barrier as I thought? I'm not good at email anyway <mark_weaver>to be honest, what we need right now are people who can contribute, and I'd prefer to weed out people who can't be bothered to write an email. <NiAsterisk>well, as long as people keep netiquette in mind (social media doesn't for example), there's not a huge barrier from my perspective. <mark_weaver>there are no shortage of ways to write email using web browsers. <NiAsterisk>also, patches are via email if you have no access, that's when people need to use email anyhow <wingo>i too look forward to mailman3 somehow <Jookia>Speaking of contributions, I spammed a few patches today and started a few threads. :) Feels good not being a zombie <davexunit>mailman is a strange project. it's a gnu project, right? <davexunit>and I wonder why it's never been more of an issue. <wingo>ACTION rebuild the world, catch you on the flip side <wingo>it is a great spacetime to be a nationstate <wingo>racing all the dns replies... yay udp i guess <wingo>pretty disgusting stuff yeah. <mark_weaver>increasingly, I realize how hard it is to write secure code in C. <Jookia>"Hey look how much garbage I can stack in between my CPU and my secure web application! I have Docker, Linux, Debian, Puppet, PHP, Apache, it's all there." <mark_weaver>almost every arithmetic operation, every cast from one data type to another that might be a different size, could lead to overflow and badness. <Jookia>mark_weaver: C had a good run but we probably shouldn't be writing full applications in it <lfam>Indeed, we should write them in other languages that are implemented in C ;) <mark_weaver>yeah, I think it should used for almost nothing anymore, except perhaps some hot spots. <Jookia>Having Guix written in a high level language is probably good for security <lfam>All joking aside, even if your language is written in C, it's easier to reduce the "surface area". <lfam>You only have *one* function foo(), rather than every program reimplementing foo() <mark_weaver>and you can provide arithmetic primitives that check for overflows, and do that checking only in a few functions. <Jookia>It's kind of sad that most exploits are basically null dereferences or buffer overflows <Jookia>No matter how hard we try it still happens <wingo>guix needs better tooling to alert you when there are vulnerabilities in non-primary profiles, i think. a hack for another day <wingo>otherwise you end up with root still having old programs <NiAsterisk>i like how gentoo-hardened addresses this, but it's still a topic nobody without special interest will get into <lfam>wingo: I had a draft email on that subject. <wingo>building software makes me nervous and spend time inappropriately. i always think it's going to finish and i don't context-switch away from the scroll <lfam>wingo: I usually add '; espeak done' to those command lines <dannym>hmm, how go I get the version string inside the arguments form of a define-public? <davexunit>dannym: define-public defines a variable. so to reference the object you simply refer to that name. <dannym>ERROR: Unbound variable: package-version <Jookia>dannym: Could you share your code? <mark_weaver>dannym: package-version is exported by the (guix packages) module. you need to import it. <Jookia>dannym: This might be because you're inside the package <mark_weaver>dannym: ah yes, that code is evaluated on the build side. <Jookia>dannym: you'll want to replace ' with an ` then replace (package-version kicad) with ,version <mark_weaver>dannym: change the "'" after 'arguments' to "`", and then change "(package-version kicad)" to ",version" <mark_weaver>and might as well change (string-concatenate (list ...)) to (string-append ...) <dannym>mark_weaver: yep, that worked. Thanks <mark_weaver>Jookia: hah, I didn't even notice until now that I echoed you :) <Jookia>mark_weaver: I posted a refactor of the VM GRUB code on the mailing list (I forgot to include a copyright header.) Thoughts when you have time would be much appreciated since this leads to my next patch I'm working on to pass GRUB options easier <Jookia>No hurry though, at all. More important stuff happening :) <Jookia>mark_weaver: "vm: Have qemu-image generate derivations instead." <Jookia>dannym: Your package might need to be put in the Guix source tree 