<jamesaxl>I really want a Gnu system that has UNIX kernel, hurd for example but stable version <jamesaxl>I would like to know why Gnu project choose Linux kernel instead of Unix Free like Freebsd for example? <NiAsterisk>there moght be something on gnu.org in history about this <mark_weaver>jamesaxl: I don't claim to know for sure, but I would guess that the copyleft licensing on Linux is an important factor. without it, it is unlikely that so many companies would have contributed their fixes and drivers back to the community as free software. <mark_weaver>jamesaxl: however, the other thing is that I'm not sure in what sense the GNU project "chose" Linux (the kernel). <mark_weaver>GNU has its own kernel project, the Hurd, as you know, and as for the software projects that are part of GNU, almost all of them are quite portable. <NiAsterisk>okay, so there was no reply on what's okay to delete for emacs builds. "I'm using the emacs-build-system without any changes so far. is this something okay for guix, or should I removed README.md, Cask, .gitignore, .git/, Makefile and travis.yml before installing? https://ptpb.pw/4rG3.txt" delete everything which is not .el, .elc, and image? <NiAsterisk>I'm not familiar with emacs system builds, I did use emacs package manager or git checkouts for this so far. <iyzsong>NiAsterisk: I think it's ok since current emacs packages did this way. But I don't like those useless files :-) Maybe talk to maillist? <calher>Why is @command{pandoc} called @samp{ghc-pandoc} in Guix? <calher_emacs>How does Guix deal with @code{$PREFIX} in @file{Makefile}? <calher_emacs>I couldn't build @command{ghc-doc}. I hope it's just because of network issues. <calher_emacs>I think MCWM's author said to correct @code{$PREFIX} since my system's filesystem doesn't work. <efraim>part of the 'configure phase sets PREFIX=$out so it knows its getting installed to the store <efraim>I haven't done any haskell packaging yet, but hopefully there should be some examples in haskell.scm <efraim>who knew there are programs that use ed? <efraim>145 that would be affected by the update <fhmgufs>efraim: I can imagine that there are a lot of shell scripts using ed. <efraim>quilt, mcron, yeah looks like you're right <fhmgufs>efraim: And by the way: Theoretically these packages doesn't need to be rebuilt. <fhmgufs>Maybe there could be a field like propagated-inputs in the package definitions to allow inputs, that need to be in the profile at runtime, but don't affect the build process. <fhmgufs>On the other hand it would be difficult which packages match this conditions. <efraim>"oh, you installed foo, maybe you also want bar" <efraim>abcde basically needs eyed3 installed if you want to write mp3 files <fhmgufs>Is a dbus expert here? I would like to run a new session bus for guix on a foreign system. My problem is that all the Guix applications want to connect to the other session bus. <calher>When I try to install stuff, it fails. <calher>Jookia: I'll do it again if guix pull didn't solve it. <calher>Jookia: Where does Guix put man pages and binaries? <Jookia>calher: Depends on what you mean by 'put' <calher>/gnu/store/sdjfdlskjflksjfiejifjliefj-package-version/bin/package <Jookia>calher: They get installed to /gnu/store and then symlinked in /run/current-system ... and your profile <calher>idk how to wrangle this makefile to fit that scheme <calher>patch the makefile to generate the guix hash and make it as part of the dirname for the install path? ugly. <Jookia>That's generally not what you do <Jookia>Guix will automagically set the output directory for things using Autotools or other stuff to the /gnu/store/sdjfdlskjflksjfiejifjliefj-package-version/ directory <Jookia>So the makefiles just have to be okay with using prefixes to install <Jookia>Oh yeah, we discussed this yesterday. It should work since you're setting PREFIX, you just need to add a line or two to the makefile to make the output directories <rekado>fhmgufs: maybe you can override this with environment variables such as DBUS_SESSION_BUS_ADDRESS or similar. <Jookia>calher: Is that a subtitles file? <Jookia>That's no really useful in fixing your package :| <rekado>calher: I don't understand what you write. <rekado>(I thought these were obscure acronyms) <Jookia>calher: You probably want to change "mkdir $(PREFIX)/" to "mkdir -p $(PREFIX)/bin" then under it "mkdir -p $(PREFIX)/man/man1" <calher>I was editing this as a joke, but OK. <rekado>why is PREFIX set to cabba9e...-profile? <Jookia>Also you dont' need RM or PREFIX set up there, Guix sets it for you <Jookia>It's probably a really bad idea to install things to a profile but I haven't tried it <calher>Jookia: How does Guix set it for you? <Jookia>calher: change "mkdir $(PREFIX)/" to "mkdir -p $(PREFIX)/bin" then under it "mkdir -p $(PREFIX)/man/man1" <Jookia>calher: In the package file it sets PREFIX <rekado>calher: it does so when "guix build" spawns a build chroot. It's done in gnu-build-system. <calher>Jookia: Didn't you see my update? I did change it to --parents. <Jookia>I didn't say to change it to --parents <Jookia>Maybe you need to re-read what I wrote <calher>@samp{mkdir --parents $(PREFIX)/bin}! <rekado>calher: are you trying to package something or just build it somewhere in your home directory? <rekado>maybe there's some context I have missed. <Jookia>rekado: He's been packaging mcwm <Jookia>calher: Looks good, though you need to remove RM= and PREFIX= from the makefile <calher>Thought it'd be simple to learn how to package since MCWM only has one dep. <rekado>calher: what error convinced you that you need to edit the Makefile? <calher>How does all this relate to upstream? <calher>rekado: IDK. It just don't install. <Jookia>calher: Oh sorry, you need to revert RM= and PREFIX= and set RM in the guix package inputs <calher>rekado: Because /bin/ doesn't exist. <rekado>calher: how do you try to install it? Is the Makefile all you have? <rekado>or do you have a package expression as well? <Jookia>The first error was that the Makefile doesn't make the directories when it installs things to PREFIX <calher>rekado: @code{guix build --file=mcwm.scm}. <Jookia>The second (which doesn't matter) is that RM is broken <Jookia>I have absolutely no idea why someone would write "RM=/bin/rm" in their makefile <rekado>in the package expression you can add a make-flag for RM <calher>Jookia: Email him and tell him his makefile sucks. <rekado>Jookia: some people create a "safe" alias for "rm" (e.g. forcing confirmation), so the Makefile author decided to explicitly use the plain binary. <calher>Jookia: You've said many times that his makefile is bad, but the only place it hasn't worked is here. On Ubuntu, I just put /usr/share for the man pages and /usr/bin for the binaries. <rekado>I'd add something like (string-append "RM=" (which "rm")) to the make-flags. <Jookia>calher: It breaks when you try to install it to any directory that doesn't exist, like /opt or /home/jookia/test-mcwm <rekado>calher: that's because /usr/bin and /usr/share and the expected subdirs already exist on Ubuntu. <rekado>it is indeed a flaw in the Makefile. <rekado>you can add a build phase that first creates the expected directories. <calher>(By Ubuntu, I mean Trisquel; I haven't used Ubuntu to compile stuff.) <Jookia>calher: I don't want to email someone without a patch and I also don't want to tell them their code sucks because they might feel bad <calher>rekado: How on Earth does the package definition lug around a patch for the Makefile? <Jookia>calher: Usually you put add a patch file reference to it <calher>So there is no way to make a Makefile that will work across systems? It has to be Guix-specific? <rekado>check the "pre-install" phases of "mp3info", for example. <Jookia>calher: There is- you just have to create the directory before you write to it <rekado>well-behaved Makefiles create the directories before copying files to them. <calher>So don't define RM and PREFIX in the Makefile <calher>If you define those, it breaks across systems. <rekado>personally, I use autoconf and automake, which writes portable Makefiles and allows users to configure the installation. <rekado>also the hardcoded "/usr/local" paths in CFLAGS and LDFLAGS in that Makefile are a bit ugly. <rekado>we can easily work around this with make-flags or (substitute* "Makefile" ...) <calher>(mkdir-p (string-append out "/bin")) (mkdir-p (string-append out "/share/man/man1")))) <rekado>yes (assuming "out" is bind to (assoc-ref outputs "out") or similar) <calher>( check the "pre-install" phases of "mp3info") <Jookia>It seems the Makefile doesn't install to /share/man/man1, just /man/man1 <rekado>in that case we'd do as "mp3info" does and replace the "/man/man1" string with "/share/man/man1". <calher>So I don't have to edit the makefile or submit a patch. <rekado>either in a snippet or in a build phase. <Jookia>calher: It'd be better to since it'd fix it upstream, but no you don't <rekado>calher: no. But using (substitute* "Makefile" ...) is editing the Makefile at build time. <calher>rekado: OK, so it's ugly and sinful. Got it. <rekado>there are different ways to solve a problem like this. <calher>But I would be very happy to avoid changing it at build time like a kludge. <rekado>ideally we would have upstream makefiles that don't make invalid assumptions. <rekado>but in reality Makefiles (and code) are of differing quality. <rekado>it is not ugly to patch away an invalid assumption. <rekado>bonus points if you submit a fix upstream, but it's not needed. <Jookia>calher: It's pretty cool you're putting effort in to such a weird task for one of your first packages :) <calher>I've been around this tedium for too long. If it's going to get done, it's going to get done with decency. <rekado>your package recipe already passes a make-flag. <Jookia>calher: You don't need to change either of those- they're variables and so we edit them (indeed, they're meant to be edited) when calling 'make' <calher>Or would RM=rm run into the problem of the 'safe rm' mentioned earlier? <rekado>that's how people usually override variables defined in Makefiles. <Jookia>calher: So we pass 'PREFIX' as a make-flag and it works already. Don't worry about the RM since we're not using it <Jookia>calher: The only broken part of the makefile as we need it is that it writes to /man/man1 instead of /share/man/man1 and doesn't create that directory or /bin <rekado>calher: the only thing the Makefile objectively does wrong is copying files to directories that might not yet exist. <rekado>ACTION tunes out as Jookia types faster ;) <Jookia>calher: Looks, good though you also want to change the /man/man1 to /share/man/man1 in the mkdir as well as when it runs the 'isntall' command <calher>Jookia: rekado> calher: the only thing the Makefile objectively does wrong is copying files to directories that might not yet exist. <calher>Jookia: Who says the place where Guix puts man pages is any more special than where FreeBSD puts it? I'm doing this for upstream. <fhmgufs>Where should libunique go? glib.scm or gnome.scm? <calher>Unique sounds like a GNOME thing; IDK why. <Jookia>calher: Hmm, I'm not sure but I think Guix wants it in /share/man/man1 - maybe try it without changing it then we can figure out how to fix it upstream <rekado>calher: the /share/man/man1 thing is a convention that Guix enforces. The Makefile is not really "wrong" about this, but it lacks a way for users to override the doc dir. <calher>rekado: But every distro has to modify this part, right? There's no unified way of writing it. <rekado>calher: many probably would modify it. Nicer Makefiles would define a variable for the man file target location. This variable could then be overridden on demand. <Jookia>Back from updating itunes- I haven't seen /man outside /share :o <Jookia>So what you should do now is try installing it, and add a phase to Guix for Guix-specific stuff which moves out/man to out/share/man <calher>Jookia: How do you get access to a computer capable of running iDunes? <rekado>e.g. by doing this in a build phase / snippet: (substitute* "Makefile" (("man/man1") "share/man/man1")) <efraim>I think mpv has unique as an optional input <rekado>the line for "/bin/rm" isn't needed as we don't run the deinstall target. <calher>How's this? Do I need ("/usr/bin/install") "install")? I don't understand what install is. <calher>So theoretically, that change should be made. <Jookia>calher: These changes are only needed for binaries that specify their full path, like /bin/rm <rekado>I don't see "/usr/bin/install" in the Makefile, so it's okay <Jookia>Just things like 'install', it'll find it <Jookia>A bit like if you run 'install' in your terminal it'll check your $PATH <rekado>ACTION should have looked at the Makefile before saying "I'm not sure" <calher>What does (string-append "PREFIX=" %output) mean? <Jookia>calher: %output is the directory for the install, so it's a bit like "PREFIX=" + "/gnu/store/....-mcwm-version/" <calher>Is it OK that this distribution comes with a program called hidden? <calher>Is it safe to do ‘guix build --file=mcwm.scm’ while I'm doing ‘guix package --install=ghc-pandoc’? <calher>(The program, hidden, hides windows in MCWM.) <efraim>fhmgufs: in general, in terms of gnome vs gtk for unique <efraim>i'd guess gtk, but I haven't really looked at whats in the two files <efraim>I just meant it in terms of having more info if you were undecided <calher>Wait, why did gnunet_bot enter? Did he crash? <calher>Nevermind, I was looking at the wrong timestamp. <calher>jamesaxl: It doesn't have Mumble and you have to update some of it directly from version control because of the DMD-Shepherd transition. <calher>It also doesn't have Meld, surf, and qBittorrent. <calher>I would type a frowny face right now, but it'll crash gnunet_bot. <efraim>ghc-memory has some build issues I think <Jookia>calher: You can't install memory-0.10 because it fails a test <calher>I guess GuixSD is just as buggy as the other libre distros, except GuixSD actually has the excuse of being immature. <efraim>like any distro run by volunteers, we do our best to not break packages and to fix ones that need attention <calher>Having installed texinfo, and having seen that its texindex program is literate, I am pleased. <Jookia>calher: You could certainly fix it <Jookia>calher: memory-0.10 failing. Perhaps there's a newer version that fixes this, or a bug report? <calher>Jookia: Where do I send reports? <Jookia>calher: Well, go to the homepage of the ghc-memory package and see if it's already filed <Jookia>calher: memory is the package that failed <Jookia>calher: not good- is there an issue for the bug? <calher>Alas, I'm tempted to run non-free JS to report a bug. <Jookia>You could always just email the person <calher>Jookia: No, there's no issue for that bug. <calher>Preparing to email Vincent Hanquez <mailto:tab@snarc.org>... <calher>Jookia: Version 11 was released 12 January. <calher>gnunet_bot: Which version are you?!?! <Jookia>gnunet_bot cares not for your games <Jookia>calher: Sounds cool, remove the mkdir -p lines and add -d to 'install', so it's something like 'install -md' <Jookia>calher: Just replace 'mkdir -p' with 'install -d' <calher>Jookia: There are multiple instances of mkdir. <Jookia>Hmm, you can replace it with just one mkdri I think <Jookia>install -d $(PREFIX)/bin $(PREFIX)/man/man1 <calher>> install -m 755 mcwm $(PREFIX)/bin <calher>> install -m 644 mcwm.man $(PREFIX)/man/man1/mcwm.1 <calher>> install -m 755 hidden $(PREFIX)/bin <calher>Just keep them there? That makes no sense. <Jookia>from what i know install -d is equivalent to mkdir -p <eiro>this there a way to install a previous version of a soft with guix ? <eiro>(i'm trying to see what are the perl versions available) <Jookia>eiro: You can always use another Guix install <efraim>you can make your own package definition that inherits from the one in guix <efraim>I have a copy of vim I'm trying to customize to my use <eiro>ohh ... one cannot just install derivation@version into the guix ? <eiro>so i'll try to write a derivation <Jookia>eiro: You can find an older version of Guix and use that alongside your new one <rekado>eiro: a package variant is easily defined thanks to "inherit" (which we probably should explain in the manual). <rekado>for a different version we change both version string and source hash. <rekado>so a command line syntax "package@version" would only work if we did without hash checking. <eiro>i'm a complete newbie in guix/guile/scheme word so this is complicated to me right now. i'll read more doc <fhmgufs>To install a previous version just inherit from the newer package definition and change the version and hash field. <rekado>calher: I wonder why you are building a couple of ghc-* packages from source. Did you modify their definitions? <NiAsterisk>is a Cask file unnecessary, or is it needed, when only tests in the Makefile of the emacs package use Cask? <eiro>fhmgufs, i would like to replace perlbrew by guix to build multiple perl env in my machine so i can test the retrocompatibility of some packages i wrote <fhmgufs>eiro: So you want to get an older perl version? <calher>rekado: Unless they're modified because I updated profile from version control in the root account. <rekado>NiAsterisk: AFAIK cask is used for Emacs package management. <eiro>fhmgufs, i want to install all the evens of perl since 5.10 <NiAsterisk>rekado: so it's rather useless if you let guix do emacs package management <eiro>it seems that i need 1 profile per version <eiro>but i'm stepping back to perlbrew right now and will try later with more guix skills <rekado>eiro: yes, 1 profile per perl version would be in order in this case. <rekado>calher: we have a package for it, but I haven't tried it. <rekado>the gnunet-gtk binary provided by the package is defective, though. <rekado>(sent an email to the gnunet ML to diagnose) <NiAsterisk>calher: sort of. you'll have more luck with a working gnunet-gtk to set it up <rekado>gnunet-setup segfaults (when using the URL dropdown) and gnunet-gtk doesn't show much content. <rekado>but it doesn't seem to be related to how we build it. <NiAsterisk>I'd also like to package gnunet-dev at some point if it's possible, to enable testing of secushare and other developing software, with the remark that it's testing software and not stable. <rekado>maybe it just wasn't tested with the versions we use. <NiAsterisk>you mean 0.10.1 gnunet and the same gnunet-gtk? it works on debian <NiAsterisk>so maybe guix package gnunet and/or gnunet-gtk just lacks some input <rekado>are they linked with the same libs that we use? <NiAsterisk>but it's the starting point I had, because I packaged this before. <NiAsterisk>I can#t do updates in guix currently because some packages fail to build on hydra and here, otherwise I would try. <NiAsterisk>ultimately, I see guix as a nice platform for gnunet software to come.. it can cover a nice range of platforms. I can imagine when the first public release of secushare is out, to get it to guix. <calher>Why would Guix have -dev packages? <Jookia>Right now it just bundles dev stuff <Jookia>Splitting out -dev stuff in future is a plan IIRC <calher>calher: But source and binary are one and the same, because it's all declared. There's no reason to separate them if the sources for everything is already pointed to in the recipe for making the binary. <NiAsterisk>calher: i am waiting for either one of the bitmessage branches to get a setup.py. it's no tested (audited) software, but it works and gets improved. so gnunet 0.10.1 is not the state gnunet latest svn checkout has. if you want to try secushare current work state, you can't do with the gnunet-0.10.1 .. I can imagine -dev to be a nice thing to look into <Jookia>Splitting out -dev packages will lighten space requirements if you're not a developer <calher>I think the whole -dev business on Debian/Ubuntu is complex garbage. <NiAsterisk>so -dev in that sense declares that it might break <rekado>Jookia: is there a mailing list discussion on this? <NiAsterisk>for example -9999 of gnunet has other requirements than -0.10.1 <Jookia>rekado: This is just what I've heard in IRC, so I'm not sure <Jookia>NiAsterisk: Oh, -devel packages? guix already has a -devel package <rekado>what NiAsterisk means is a package for unstable software / pre-releases, I assume. <NiAsterisk>gnunet-9999 introduces features which are not yet in a release verrsion <calher>Jookia: If there's a binary, it'll grab it. If there's no binary, it'll use the recipe. It's simple and beautiful. Splitting is disgusting! <Jookia>calher: Disgusting? It's a computer <rekado>Jookia: if you have an elegant proposal for splitting I'd like to encourage you to write to the mailing list. <calher>On FreeBSD, I loved this: if it was installed, other programs could be built against parts of its source. If it was installed, I had every part of it, not just a binary. <Jookia>rekado: I really don't care either way, I didn't know it was a big issue- I just remember someone saying it was planned to split it down the track <rekado>maybe separate outputs rather than separate packages. <calher>"Do you have <program>?" -- "Yes, but it's not building." -- "Oh, that's because you don't *really* have it. You see, we separated that program into two parts, because source code is useless." <Jookia>Splitting things in to dbg/dev/etc outputs would be great <Jookia>It'd be GREAT to have a command that fetches me all the debug symbols for a package and its dependencies <rekado>not sure how to do combine this with functional package management, though. <NiAsterisk>I am used to the simple way in ebuilds, maybe I can give that a try in guix later this year. <Jookia>There's actually an email I got just now about this same issue in Nix <NiAsterisk>so like, get the default to be what's current release, and the :dev output to be what's the latest non-failing checkout from master <rekado>NiAsterisk: that usecase would better be served by "guix build --with-source" or a separate package variant. <rekado>separate outputs are for installing files to different locations in the store, so that users (including packages) can pick the subset that they need. <rekado>we usually split outputs for documentation when the documentation is really big. <NiAsterisk>then what I meant was a separate package variant, like inherit and then change the parts needed. <Jookia>"Cloning into '/gnu/store/8gkbj6sl6v1syjfmsy29vd7cll4zffad-guix-0.9.0.c3f29bc-checkout'... Checking out files: 100% (1134/1134), done." Woo! HTTP proxy support for git:// URLs. <Jookia>It's always better to have applications know they're being proxied <Jookia>I'm using socat + git's proxy configuration variable <Jookia>So this means Guix can now fetch git repos over Tor <Jookia>calher: How's your mcwm packaging going? :) <calher>I don't want to experience the failure. <Jookia>Without failure we can't get anywhere in life <Jookia>I believe in you calher, you can do this <NiAsterisk>there's no failure, only things one can improve and learn from :) <Jookia>I failed to the point of giving up the other day on getting this proxy stuff to work but today I had another shot and after a few hours it worked out <Jookia>calher: Congrats on running it :) Okay, let's figure out what you need for substitute* <Jookia>calher: You need to use the module 'guix build utils' <Jookia>I just 'git grep'ed until I saw it <Jookia>Nope, everything's in the Guix repository ***mordocai_ is now known as mordocai
<Jookia>calher: Oh ok, this will blow your mind a bit- the modules you added it to is for stuff run in the build environment- you want to add it to the top modules of the package <Jookia>calher: Guix generally has two environments- the Guix environment and the build environment for packages, which makes sense if you think of things like cross-compiling or installing in a VM where you send the source to the builder and the builder doesn't have Guix there, only Guile modules <Jookia>"(modules '((guix build utils)))" should be added to the (source (origin thing <jin>hi guix's, what it's license used for creative commons in the package definition? <calher>Jookia: Is the only error the fact that I didn't modify the Makefile to create the dir? <Jookia>calher: Yep :) Do you have your patch file? <Jookia>Well, if you have a patch that you're sending to someone you can just use that, but you could mod it from guile using substitute if you wanted :) <calher>Jookia: I showed you the response. <Jookia>calher: Ah, I see. Well if you change it from mkdir -p to install -d it might be worth their time but if you don't want to that's okay too, just substitute it :) <mark_weaver>jin: if it's not one of those, we'll have to add it. <jin>ok thanks, Jookia, mark_weaver <Jookia>jin: What license are you in particular using? <jin>there are COPYNG files with ccby2 , ccbsa2 , ccbysa3 <Jookia>calher: Aww cool! So add that patch to the package <calher>Uh-oh, Jookia. I didn't see this: <calher>+⎇ uninstall: deinstall deinstall: <Jookia>calher: Uh-oh :P Time to resent it? ;) <jin>Jookia: there are COPYNG files with ccby2 , ccbsa2 , ccbysa3 <Jookia>jin: I see, neat! I love CC-BY and CC-BY-SA <calher>rekado: How do I add lines to a Makefile from Guile? <Jookia>I'm not rekado but you can take your patch you just made and get Guix to apply it for you <calher>but where will other people get the patch file <Jookia>or in the guix repo, gnu/patches I think <Jookia>gnu/packages/patches contains all the patches Guix uses <Jookia>Also Guix built on my Novena! (No GuixSD yet) <calher>Jookia: Can't find info in Guix manual on code snippet management. <Jookia>calher: Code snippet management? <calher>a Scheme expression to modify the source code <calher>I thought it was already up weeks ago but a few days ago I tried to visit something and I got a 404. ***kelsoo1 is now known as kelsoo
***nckx|offline is now known as nckx
<roptat>hi, I'm trying to install guix SD, but the installation hangs at downloading nss <roptat>it's because of the firewall I have here, it is not configured correctly and blocks passive mode on ftp <roptat>I have the file guix tries to download though, but when I try to copy it in /gnu/store, it gets deleted <Jookia>guix download <URI>, where you can use http:// or file:// <davexunit>roptat: it's important to *never* modify the store manually <mordocai>Btw, I was having trouble downloading nss the other day too but it seemed to me like a mozilla infrastructure problem not a my-internet-or-firewall problem. <mordocai>I didn't investigate much because it was late and I was tired <mordocai>(downloading the nss source not the hydra substitute) <roptat>how could guix know it didn't download the file I put there? <mark_weaver>roptat: guix-daemon keeps an sqlite database that keeps track of what's legitimately in /gnu/store. <mark_weaver>roptat: things that you manually put there will be ignored <roptat>ok, I won't try to mess with the store anymore <mark_weaver>and as davexunit said, you must *never* modify anything in /gnu/store yourself. doing so will cause non-obvious problems. <efraim>in regards to our trying to depreciate qt-4, with a straight substitution to qt, soprano didn't build and polkit-qt built without issues <fhmgufs>The common distro's packages are so lazy. There are a lot of dependencies that are not needed or missing. <fhmgufs>They often depend on the fact that most users already have a lot of things installed. <NiAsterisk>I might be able to fix gnunet-gtk. But not this week, I'm applying for a job which has priority. went through the logs of the gnunet-gtk build, I'll compare it to gnunet-gtk on gentoo soon when I have time, but I see a couple of errors which shouldn't exist. <achilles`>Will guixsd gain a larger userbase once 1.0.0 comes out? Will this distro be more beginner friendly later on? As of now, I have not been able to successfully install this on my machine and so I am worried this distro will be ultra niche, which is unfortunate because the idea behind it is revolutionary. <NiAsterisk>what are your issues? maybe it can help to work towards a more useable state <achilles`>well, I tried this around two weeks ago and addressed the problem to this channel. The problem was with the installation of guixsd. <achilles`>I think it had to do with missing some file, I might try it again soon for fun. <achilles`>A major problem was that it took awhile to install (what parts were able to install), but <NiAsterisk>maybe you could collect and send it to guix-help list? It might help with the bigger list of improvements I want and write down at some point. <achilles`>I heard this was due to the lack of servers and a large number of users <NiAsterisk>yes, hydra is a problem currently, but will be replaced soon <achilles`>Also, this is coming from someone who is a relative newcomer to GNU/Linux (4ish years) and non-programmer. <Jookia>achilles`: we need people like you to test- basically right now things are a bit rocky because there's underpowered build hardware. but it's happening <NiAsterisk>this is especially what I want to address, what I want to address in a talk later this year :) <NiAsterisk>feedback of people who are just starting really helps. <achilles`>but is this distro for a userbase like that of Trisquel's? or at least Debian? (Slightly more advanced userbase) <Jookia>achilles`: Hmm. Hopefully, yes. But that'd require more documentation than now, and some pre-configured images with GUIs <achilles`>besides the package manager which is great, the direct connection to the GNU project and FSF endorsement is big plus for me. <NiAsterisk>ideally, in my opinion, it should be a distro which makes itself as accessible as possible to beginners and experienced users <Jookia>I can see it being a bit difficult given the lack of GUI configuration system but I think if people are okay with using the command line then it would be okay for them- it's probably easier than Arch Linux in this case since you don't configure things by hand <NiAsterisk>which requires more documentation etc.. I'm not inexperienced myself and have issues getting started. I'm collecting notes and ideas and everything and will improve docu and other materials at some point <achilles`>how can I directly suggest improvements to the docs? <NiAsterisk>try the help list, and see what can be done with it :) <Jookia>achilles`: You can always edit the documentation and send git patch files on the mailing list if you want :) <achilles`>remind me, what is the guix command to update the source list (like apt-get update)? And okay, got it. <achilles`>right, I was told to do that, and then there was a suggestion to update the docs, but it hasn't changed since then <achilles`>I was told to guix pull before installation since i was having problems <mordocai>achilles`: I believe there was an update to the docs to tell people to guix pull but it just hasn't made it out to the docs on the internet yet. <Jookia>achilles`: At the USB installer you should run 'guix pull' before installation to get the latest packages, otherwise you'll install the old version of Guix + packages <achilles`>another thing. I knew how to format the drives from some prior experience with Arch linux, but there is little mention in the docs on how to format the drive which can cause confusion. <NiAsterisk>okay. would be great to have this on the mailinglist, so it does not get lost in the discussion logs on irc :) <davexunit>now, I imagine mediagoblin doesn't actually run yet, does it? <paroneayea>davexunit: not yet, at the very least it needs to be setup to do the autotools bootstrapping <paroneayea>davexunit: also the css will be a stickler, since we use an external css tool <paroneayea>we can more easily drop javascript deps, since they aren't "necessary" <paroneayea>davexunit: also, the sqlite issue makes it so it doesn't actually work. <NiAsterisk>achilles`: in october/november i'll do a guix packaging for beginners thing (hopefully can get it recorded) with my experience of the time from 0 (gentoo, arch packaging experience) up to that point. <paroneayea>I can probably get gmg packaged well enough to go in guix this week, excepting that issue. <mark_weaver>paroneayea: I updated sqlite to 3.10.2 in core-updates. it would be nice to know whether that version has problems with sqlalchemy <Jookia>Does --check rebuild all dependencies too? <Jookia>mark_weaver: I see, I just made a world rebuild with my proxy patch then. :\\ Hmm <paroneayea>so we're going to have to do something about that <paroneayea>I *did* make that patch that has the downgraded sqlite only for python <paroneayea>davexunit raised concerns about it, but the more I think, it's probably ok? <paroneayea>I mean it's specifically linking to sqlite at build time <mark_weaver>is sqlite linked into the main python executable, or does it dynamically load it at runtime? <mark_weaver>well, that would require a rebuild of almost our entire archive anyway <paroneayea>mark_weaver: yeah, it's annoying, but in the meanwhile anyone using sqlite with python may be having serious db errors <davexunit>paroneayea: I thought the problem was only for sqlalchemy? <mark_weaver>and if python tries to load something else that's linked with a different version of sqlite, that might be bad. <davexunit>my concern is that a single python application will try to link against 2 conflicting sqlite libraries <paroneayea>those look like some operation was meant to happen <NiAsterisk>haha. cash system where I am right now runs on windows 8 <mark_weaver>we had two versions of nettle, and then ended up linked into the same executable further down the line and everything blew up. <mark_weaver>yeah, I think we need to get to the bottom of this. find out where the bug is and fix it at the source. <davexunit>for a quick hack for the wip-mediagoblin branch, go ahead and use the downgraded sqlite and move on with other issues. <mark_weaver>spending a week more of hydra's time to rebuild our entire archive to downgrade sqlite is something I would prefer to avoid, especially if it turns out to be some bug in sqlalchemy <mark_weaver>especially since downgrading sqlite will probably re-introduce bugs that had been fixed there. <davexunit>for the record, I'm not suggesting we do that. <mark_weaver>but from where I sit, I don't see other good options <NiAsterisk>what's the traffic like for substitute servers for hydra? I could imagine to set up one in berlin at some point. <achilles`>haven't there been donations for new servers? When will these servers be set up? <paroneayea>I'll update the email thread pointing to that too. <roptat>I'd like to help with packaging, but I don't know exactly how I could set things up <roptat>like where the package repo is, and where I should clone it for guix to find it <mark_weaver>roptat: see the "Contributing" section of the Guix manual <mark_weaver>roptat: however, one important note that's not mentioned there: make sure to pass --localstatedir=/var to ./configure when building Guix from source code. <roptat>so even though guix is already installed on the system, I need to rebuild it? <mark_weaver>(to match the localstatedir of the Guix you currently have installed) <mark_weaver>roptat: to contribute changes to Guix (including adding new packages), you need to build Guix from git. <kristofer>mark_weaver: I have a question about that! After building guix locally I ln -s ~/.config/guix/latest and also /root/.config/latest <davexunit>roptat: guix doesn't have a "package repo" in the sense you may be used to from distributions like Debian or Fedora. for them, a "repo" is a server that hosts binaries. for us, the entire set of package *recipes* is stored on your machine. all of the package recipes are included with the rest of the guix code. <kristofer>I notice after running ps aux|grep guix-daemon that the daemon is actually running from /gnu/store/someHash-guix/guix-daemon <davexunit>so to add/update a package is to write some Scheme code and send us a patch. <kristofer>do I need to update the path so guix-daemon runs from the git build in ~/guix <davexunit>kristofer: the daemon protocol is stable, so you almost never need to update it. <mark_weaver>the oldest guix-daemon can build the latest packages <roelj>How can I get the sha256 checksum of a git commit? <davexunit>roelj: clone the repo, 'git checkout commit', delete .git, 'guix hash -r .' <davexunit>don't do this on a checkout you care about, of course. <mark_weaver>roelj, davexunit: to be more clear, do that on a fresh clone, and not in a git repo that includes local commits that you care about, because the entire local git repo lives in .git <roelj>davexunit: Thanks. That is pretty cool. <davexunit>I want to extend 'guix download' to do this automatically. <NiAsterisk>what's the name of the meta package which provides developer tools (gcc, make etc) on debian again? <roelj>So I see this in "glibc/hurd": (origin (method git-fetch) ... (file-name "libpthread") ... ). What kind of file does a git checkout create? I thought it would be a directory..? <paroneayea>mark_weaver: I'll work to get a patch into guix. <paroneayea>mark_weaver: it appears so. It looks like there was a new release today. <paroneayea>mark_weaver: maybe that release contains the fix <NiAsterisk>ha! i can reproduce the error on debian (server) when SYSATOMS and lispf4 and BASIC.IMG are all in /usr/local/bin <NiAsterisk>but taking apart the code of lispf4 can take a bit to understand it. <NiAsterisk>both readonly. okay, that's not the situation in guix. damn <NiAsterisk>great. so strace -f lispf4 with SYSATOMS having chmod +x runs lispf4.. unlike in guix. getting interesting. <NiAsterisk>well, does not. same. maybe the author never tested it outside of home. ***wgreenhouse is now known as grinhaus
<nckx>Is ‘gtk-doc’ known to be broken at the moment? Building it fails with ‘checking for DocBook XSL Stylesheets in XML catalog... not found’ here and I'm not sure if it's my installation or Guix proper that is wonky. <nckx>efraim: Ah OK, thanks. :-) <NiAsterisk>this lispf4: beh.. trying to get into it to see if it's code related is not easy. <NiAsterisk>I can reproduce the error on debian without guix. so it's definitely not guix related. <NiAsterisk>had a chat about this right now, could be on the devs side. <paroneayea>mark_weaver: davexunit: upgrading python-sqlalchemy to today's release fixed it! <Jookia>mark_weaver: Should I be adding stuff to build/utils.scm or creating a new file to avoid world rebuilds? <mark_weaver>any change to guix/build/utils.scm will force a full rebuild <mark_weaver>guix/build/utils.scm is an implicit input to almost every derivation <Jookia>Not sure if it's the right place but I have a function and one to wrap it that takes the HTTP proxy environmental variable (http_proxy) and regexes it in to something useful <mark_weaver>Jookia: you know that Guile already includes an HTTP client with proxy support? <Jookia>I don't have the skill to use that to build a proxy program <mark_weaver>Jookia: if this is for git-fetch, just add things to guix/build/git.scm <mark_weaver>note that already has some stuff relating to http_proxy <mark_weaver>if you want to use socat for now, that's fine, but I'm not sure how civodul will react to it. he might want to rewrite it to use pure Guile. <Jookia>That'd be great, but it'd be a bit of a task <Jookia>It's not using the proxy to download anything, instead tunnel <mark_weaver>I don't know, I suspect that Guile already has everything needed <Jookia>I suspect it should, but either way I'm writing it in such a way it's somewhat modular <paroneayea>. o O (pushing to savannah seems really slow right now on the email step...) <mark_weaver>paroneayea: I noticed the same thing when I last pushed. <paroneayea>ACTION structures so as to not ping while pondering pinging <lfam>I noticed that too. It does eventually succeed. <lfam>For the past several days <xd1le>NixOS has /usr/bin/env, i haven't used GuixSD yet, can anyone tell me if GuixSD has /usr/bin/env too? <lfam>What's the workflow for using `guix refresh -u`? When I use it from the top of my source tree, I get "guix refresh: error: mkstemp!: Permission denied" <lfam>xd11e: We don't have it. Of course, you can create it with a symlink if you want it. <xd1le>i ask because i'm wondering why NixOS does have it <xd1le>lfam: what do you use for shebang headers? <lfam>I'm not using GuixSD full time yet <lfam>But there's been talk of a shell-script importer that would patch shebangs <xd1le>davexunit: i know this conv happend before <lfam>We really need a section in our manual explaining why having /usr/bin/env discards most of the benefits of functional package management <xd1le>it's because nixos *does* have it, so wondering all over again <lfam>Okay, then we don't have to argue about it again :) <davexunit>NixOS, in general, is less rigorous than we are. <xd1le>just tell me the right think to do <lfam>I would ask them if they use it in a way that throws away all the benefits of Nix or not <lfam>I guess it's fine if you don't mind your scripts breaking when you update the target of the shebang <lfam>Or, potentially breaking <xd1le>other than it's "the universal standard" or something, so it's okay <xd1le>but ionno if that was someone 'official' or someone who contributes to nix a lot <lfam>For example, if your script targets python-3.4, and then we upgrade to python-3.5, and your shebang was #!/usr/bin/env python, then your script breaks <lfam>Did you ask on their IRC channel? IME it's not really as useful as ours. <xd1le>yeah i should probably asking on ml <lfam>Their discussions seem to happen elsewhere <xd1le>all i know is the irc, ml, and github <xd1le>i'm mainly just asking for my own *unmanaged* (by guix) scripts <lfam>I would make a symlink in that case <lfam>Or help write that shell-script importer <xd1le>as in, is the shebang patcher completed? <Jookia>It'd be good to have /usr/bin/env in development containers <lfam>I imagine a user interface like this `guix shell-import ./myscript`, and it copies it into the store, puts it in your profile, and patches the shebang. Not sure about the details. <xd1le>lfam: that's annoying though <Jookia>lfam: I wonder how that'd handle dependencies <mark_weaver>xd1le: for now, you can use #!/run/current-system/profile/bin/python if python is in your system profile <lfam>Jookia: I'm not interested in discussing it again <mark_weaver>I think the *right* solution is to provide a super-easy way to import a script into a proper package that gets added to your profile <Jookia>I thought we were going to flesh out the idea <xd1le>that's what i think too, i think it's okay <Jookia>I guess the first rule of discussing ways to make the tool is to not discuss how it'd work ;) <mark_weaver>I don't have time to discuss it now, but maybe on guix-devel? <xd1le>ideally, i'd like a way for it to 'just work' on other non guix systems, but i understand that obviously that may just not be possible <lfam>We've discussed it so many times. Someone needs to do the work and propose a patch. <xd1le>and besides, i expect to only use guixsd in the future <Jookia>lfam: Is it written down on how to do dependency resolution? <xd1le>but it still maybe useful for those not on guixsd, if it's possible <lfam>efraim: Do you use `guix refresh -u` when updating? How do you invoke it? <xd1le>mark_weaver: nws, i don't want to take your time <Jookia>xd1le: I think there's two problems: Handling external development environments that assume /usr/bin/env and adding shell scripts, Guix has to invent a way to handle shell script dependencies <Jookia>ie I have some scripts and they call each other, but importing one and then the other, how would they know to call each other? <davexunit>I think I've said this before, but those shell scripts are *broken*. <Jookia>Shell scripts sound broken by design if we can't write them <davexunit>/usr/bin/env is a hack that only works on FHS distros. <xd1le>Jookia: wait, i don't understand why the dependencies are a problem there <Jookia>xd1le: How would a shell script A call shell script B if they're both 'imported'? <xd1le>davexunit: so /usr/bin/env is a FHS convention <xd1le>davexunit: yes, well we all know guix isn't compatible with FHS, so probably end of discussion there <davexunit>#!/bin/sh is basically the *only* portable shebang. <Jookia>I think a shell script importer is the wrong way to go about it and we need to work on either autotools shell scripts or running them in environments with patching <xd1le>davexunit: is /bin/sh *needed* by guix though? <davexunit>xd1le: one reason why it exists, AFAIK, is that glibc uses /bin/sh for the 'system' function. <xd1le>Jookia: wait, what do you mean call? <Jookia>I think the only way to solve this is to write a runtime shebang patcher <xd1le>can't it just use relative paths <xd1le>Jookia: i think if it's that complicated of a 'script', better just package it up with guix <davexunit>for software projects, the right answer is to use your build system correctly. <Jookia>xd1le: how would an importer use relative paths? <xd1le>and save yourself the hassle <xd1le>Jookia: a runtime one would be nice, yes that's what i was thinking <zacts>what issues are blocking stumpwm from being ported? (quicklisp stuff?) <Jookia>actually this is an unfixable problem <xd1le>Jookia: wait, a step back. what do you mean when a shell script 'imports' another script? <Jookia>xd1le: if guix had a shell script importer <mordocai>zacts: Basically figuring out how we want to build common lisp systems <xd1le>as in, doesn't that depend on the 'module' system of whatever language the script is in <davexunit>all of my projects use Autoconf to find the absolute path to the needed executables and generate shell scripts with the correct shebangs. <xd1le>as in, doesn't that just 'work' if the m <Jookia>davexunit: Does that happen after every 'make'? <xd1le>*'module' system for the language works <Jookia>davexunit: Can you show an example of this? <mordocai>zacts: AFAIK no one has spent much time on it yet. <xd1le>davexunit: that's nice, i mean shell scripts that we write ourselves <dmarinoj>mordocai: last time I checked stumpwm can just be built with the gnu-build-system <Jookia>davexunit: So what's the workflow of editing this? Do I edit the generated guix then copy the changes before committing? <xd1le>zacts: i guess no one using guixsd uses it yet <mordocai>dmarinoj: not with proper dependency management <xd1le>anyone know if that shell script importer work has been started? <davexunit>Jookia: scripts/guix.in is in the Git repo, scripts/guix is not. <mordocai>dmarinoj: For it to work in guix, we need to build all the lisp libraries ourselves and tell asdf where to find them. <Jookia>davexunit: Yes, but as a developer how would you make changes that get put back to scripts/guix.in? What's the workflow? <dmarinoj>zacts: I was trying to package it this summer but did not finish <Jookia>xd1le: I don't think there is one <zacts>dmarinoj: what issues did you encounter? <Jookia>davexunit: Then you run ./configure before running it again? <Jookia>I should convert my scripts to use something like that <dmarinoj>mordocai: I really just started writing the template according to the dependencies detailed in debian...I'm really green <dmarinoj>mordocai: also I looked at the quicklisp importer for debian <davexunit>we need asdf-build-system and 'guix import quicklisp' for CL stuff <mordocai>zacts: dmarinoj: Yeah, we could use a similar importer to make the package definitions. One of the interesting things about lisp is generally people just ship the code and cache the fasls locally where as I think guix might want to actually ship the fasls. Not sure. <Jookia>xd1le: I think the most constructive solution is to write a 'scripts2autotools' thing that replaces all scripts with '.in' files and changing /usr/bin/env X to @X@ and having autotools finding that <mark_weaver>Jookia: we already have 'patch-shebang' in guix/build/utils.scm that we use automatically in gnu-build-system <Jookia>Interesting- but I think this is more for retrofitting existing project trees <Jookia>ie if I download Libreboot code I could run this to give me an autotools system I can use to fix things <davexunit>dmarinoj: ah okay. in that case, we would build our own. <mordocai>davexunit: Yeah, compiled common lisp. Typically we treat them a bit similar to pythons .pyc even though that isn't a perfect analogy. <xd1le>Jookia: nice, but you mean at runtime, correct? <xd1le>because we obviously shouldn't be changing files and stuff <mordocai>davexunit: It is typically actual compiled native code, not bytecode like python <Jookia>xd1le: I mean at build-time as a patcher that would be useful for upstream projects to use an dremove /usr/bin/env for once and all <dmarinoj>mordocai: as for the importer I already wrote some of that code, I recall it is just parsing a csv <xd1le>Jookia: yep i understand now <mordocai>davexunit: It wouldn't be pre-built. Those are what are generated by compiling. We don't typically have a single file as output of a library build for instance <xd1le>Jookia: that also seems quite ugly, but i can't think of much other options either atm <davexunit>just wanted to make it clear that if quicklisp hosts binaries, we wouldn't use them. <mark_weaver>Jookia: you seem to be aiming to make upstream software buildable and installable on Guix *manually*, as opposed to building things in the build containers, putting things in profiles, etc. <mordocai>I'm actually on the fence as to whether guix should ship fasls or not. <mark_weaver>Jookia: and I'd like to know why you think that's better than importing things as packages <mordocai>Usually lispers don't, but it seems more akin to the guix philosophy to do so... <mark_weaver>Jookia: the gnu-build-system *automatically* scans the entire source tree for shebangs and converts them before building. <Jookia>mark_weaver: Not installable, no. I don't think it's better than importing things as packages, but as a developer I don't want to package things all the time <Jookia>mark_weaver: Imagine if I had to rebuild the entirety of Libreboot every time I change a source file