<paroneayea>davexunit: the default j-bob appears guile compatible <paroneayea>or based on recent commits, where some guile things were fixed. <davexunit>also, does anyone know what the deal is with the 'guix.d' directory in share/emacs/site-lisp ? <paroneayea>my goal is to finish all my copies of the Little books before year's end. <paroneayea>I can tell you this much so far: it has a lot of nice drawings of owls :) <lfam>That's a great reason to read a book <paroneayea>ther'es probably a high chance that if a book has drawings by Duane Bibby that it's worth reading. <lfam>Does anyone want to take a look at bash.scm with me? ;) <lfam>I'm trying to fix bash:include <lfam>Particularly the install-headers-phase. It has the line (mkdir-p include). I can't tell based on bash.scm where in the directory tree that is executed, but the bash tarball unpacks with an include/ directory at the top-level. <lfam>However, the contents of the directory aren't getting copied into the store directory for bash:include <davexunit>lfam: try inserting a debugging print statement just before that <lfam>The contents of the tarball's include/ directory, that is <lfam>Is pk a print statement? <lfam>Is it documented anywhere at all? ;) <lfam>I foresee needing to do a lot of print debugging for this, unless I get lucky <lfam>Oof, my one line of print debugging in bash.scm means I need to rebuild / subsitute pretty much everything <lfam>Hopefully it's just this once <paroneayea>lfam: yes bash is used by nearly everything... so my advice is: <lfam>So far I have not created any profiles from "scratch". I have just package -i and -r'ed them into shape. But is there a way to make a new profile with just bash? And I guess locales? <lfam>Even with a bash only profile, there is still a lot to do <lfam>Well, at least the transitions between profiles are atomic and fast :) <lfam>It's a shame though. The bash:include package shouldn't need to compile anything. It's literally just copying files from the tarball into the store, unless I am mistaken. But the whole dependency tree is changed when I change bash.scm. <bavier>lfam: yes, bash is used during bootstrapping <bavier>so changing the bash package recipe leads to re-bootstrapping <bavier>but you could possibly test recipe changes by building a bash that's lower down the dependency chain <bavier>lfam: building the "bash-final" package may save you some building <bavier>it's in the (gnu packages commencement) module, but not exported <bavier>your should be able to do something like `guix build -e "((@ gnu packages commencement) bash-final)"` <lfam>So, the result of that would satisfy the bootstrap dependency on bash so that I can play around with (gnu packages bash)? <bavier>it's the first bash that's built in the bootstrapping <bavier>so it'll use the recipe in (gnu packages bash) <lfam>Hm. Do you think that would help me with testing my changes to bash:include? I'm not actually trying to build bash itself. I just want the headers. <bavier>lfam: the "include" output is a product of building bash, so, yes, it needs to be rebuilt. <bavier>thought, in this case, you might be able to experiment with the header installation by defining a temporary package that does only the header installation. <bavier>then merge that into the bash recipe once it's working the way you want <lfam>bavier: I definitely need to try something different. Learning guile would be faster than what I'm doing right now ;) <bavier>yeah, bootstrapping isn't so much fun <lfam>Also, I would probably have to use LVM to resize my / again, like I did when I first tried Guix. The last few hours have consumed several gigabytes :/ <lfam>Thankfully I kept notes after the last time ***francis7 is now known as francis7-awol
***francis7-awol is now known as francis7
***francis7 is now known as francis7-sanctua
***francis7-sanctua is now known as francis7
***francis7 is now known as sanctuary
***sanctuary is now known as fchmmr
***fchmmr is now known as fchmmr-sanctuary
***fchmmr-sanctuary is now known as francis7
<lfam>francis7: welcome back to your 7th self ;) <xd1le>is it possible to use xinit/startx to start an x session instead of a <mark_weaver>xd1le: it's possible in theory but difficult, and I don't know off hand how best to do it, but part of the job would be to create an xorg.conf that tells X where to find things like its modules and fonts, and then to pass the needed command-line arguments to use that configuration file. <mark_weaver>we'd like to find a way to support startx, but it's not yet done <xd1le>mark_weaver: ah that sounds like a lot of work for not much benefit so i <xd1le>but i hate unnecessarily starting x <xd1le>ofc i'm on a slow hardware.. so yeah. <xd1le>wait is it possible to not use any desktop environment or window manager? <mark_weaver>xd1le: yes, just don't include 'slim-service' in the 'services' field of your OS config <xd1le>so login would just be a tty prompt or something? <xd1le>what does it mean when a collision has been encountered? <taylan>xd1le: two packages you installed into your profile provide the same file. only one of the files will be chosen and installed into your profile. <xd1le>taylan: ah i see, so it's not really a problem <sneek>davexunit, you have 1 message. <sneek>davexunit, nalaginrut says: actually it's migration ;-) <civodul>i've pushed a 'dbus-update' branch, which updates DBus + GLib <civodul>if you think of related updates to make, go ahead <iyzsong>since dbus-daemon-launch-helper only read /etc/dbus-1, does it mean we should write the dbus configuration file into /etc/dbus-1/system-local.conf? <civodul>iyzsong: yes, your patch is even better, sorry for not discussing it on the list before! <civodul>could you rebase it on the 'dbus-update' branch? <civodul>and yes, we'll have to add /etc/dbus-1/system.conf <civodul>i discovered this as i was implementing dbus activation <iyzsong>sure. so, I should add a a commit to remove 'dbus-localstatedir.patch'? <iyzsong>I should send to the ML about it.. while waiting for the fantasy services-refactor then forget :- <civodul>iyzsong: yes, or you can commit directly the patch removal + new phase <civodul>what do you mean regarding services refactor? <iyzsong>civodul: yeah, when thought about update dbus, I think better do it after the services things merged :-) <toothbrush0>Hello all! I have added a crapton of Haskell/Cabal packages; i guess i should send individual patches. What i'm worried about though, is that it will be a non-trivial task to sort out the order in which packages should be added. <iyzsong>cool, icecat get update. thanks mark! <civodul>toothbrush0: do you think you could manage to do that? :-) <toothbrush0>um, i'm not sure; it sounds like a Lot Of Work, since i've been massaging packages till stuff works <toothbrush0>(cabal makes it rather unclear when an input should be propagated or not, for example) <davexunit>alezost: okay, now my question is, do I have to manually add each directory in there to my load path? <alezost>davexunit: if you don't use (require 'guix-init), then yes <toothbrush0>civodul: i guess my question is, how important is it that in any arbitrary git revision, all packages (the ghc-* ones in this case) can build? <davexunit>I do require 'guix-init and it still doesn't work <civodul>toothbrush0: in this case the question is more how important it is to have separate commits <civodul>maybe you could post a single patch, explaining the problem, and see what people think? <alezost>davexunit: look at "M-x find-library guix-init" <toothbrush0>civodul: alright. i'll see if it's perhaps easyish to do "the right way" before succumbing :) <alezost>davexunit: is `guix-package-enable-at-startup' set to t? <alezost>davexunit: try "M-: (guix-emacs-find-autoloads)" <alezost>hm, I didn't get it, so what doesn't work then? <alezost>what is the value of `guix-emacs-autoloads' var? <iyzsong>oops, forget to remove the patch file, and I can't do a 'force' update. (hope no one notice it) :- <davexunit>alezost: it's a list containing the autoloads file I expected, the one to typo-autoloads.el in guix.d <toothbrush0>oof, 115 new packages at my last count :/ and i still have to neaten up the descriptions etc. :/ <davexunit>toothbrush0: it's better to work in small increments. we couldn't possibly review a single patch that adds 115 haskell packages in any thorough way. <toothbrush0>it's just that i want to be sure that my target (Idris) works properly before committing anything <toothbrush0>cabal has a nasty habit of telling you rather late that an input should actually have been propagated <iyzsong>toothbrush0: that's really amazing! but I think you should sleep well (for a long run) :-) <davexunit>alezost: I installed emacs-typo and ran (require 'typo) and it couldn't load. do I have to re-evaluate some code for newly installed elisp to be noticed? <alezost>davexunit: does load-path contain that guix.d dir? <toothbrush0>well, it's like, i manage to compile package P1 which requires P2, but later when requiring P1, cabal tells me that P2 is broken because of missing packages <davexunit>alezost: I added it manually, but that wasn't enough <davexunit>I had to add guix.d/typo-1.1 to the load path <alezost>it definitely should be added automatically <alezost>but even with that (require 'typo) doesn't work, right? <davexunit>after I added the typo directory to the load path manually, it worked. <alezost>davexunit: could you start a new instance of emacs, and check load-path there? <davexunit>alezost: (require 'typo) works in a new instance. <davexunit>so I guess installing a new elisp package that puts code in guix.d needs special attention if you are using an already running emacs. <alezost>davexunit: you probably installed this emacs package after you started emacs, so the .../guix.d/typo wasn't exist when (require 'guix-init) was performed <alezost>davexunit: did you use an emacs interface to install it? <iyzsong>toothbrush0: how about propagated all the haskell libraries? I think (not sure) that's what nixpkgs does. <davexunit>I don't really know how to use the emacs interface tbh <toothbrush0>iyzsong: that would make my life much easier, but i'm not sure if it's the correct way to do things? <alezost>davexunit: if you would, it would happen automatically, otherwise load-path cannot be changed by magic – emacs doesn't know what/when you install outside of it. <davexunit>I just didn't know how these ELPA repos worked. <davexunit>it was just surprising because all of the other elisp I've ever installed didn't have this issue <alezost>davexunit: actually there is no need to add a package manually in such cases. After installing you can run "M-x guix-emacs-load-autoloads". It should add things that are not in load-path yet <toothbrush0>iyzsong: it looks like you're right, although i haven't checked exhaustively <alezost>davexunit: yes, all other emacs packages worked for you, because all of them were installed in ~/.guix-profile/share/emacs/site-lisp, but for the packages installed in guix.d, each new subdir should be added to load-path separately <iyzsong>um, propagated all inputs for library-type packages make our life easier, since we don't install them typical, the mess can be ignore? toothbrush0, yes, we should talk it to the mailing list. <davexunit>concerning Fedora becoming more lenient towards bundling <bavier>it'll become freely available on the 22nd ;) <davexunit>I forget that I have still have a subscription through the FSF and that I see paywalled stuff. <davexunit>basically, everyone thinks bundling is just great <Gamayun>Hmm, they've just removed the old policy on their wiki, not put up the new one, it seems. <davexunit>"Programmers don't care to the point that they welcomed Docker (which is "bundling on steroids") with open arms, red carpet and whatnot." <davexunit>"If distros want developers to unbundle their dependancies then the distros need to start making some promises about compatibility, for 5-7 years, of the libraries they want developers to be able to depend on otherwise this doesn't fix the pressure toward bundling and containerizing." <davexunit>"Who cares about bundling? I say, bundle the whole world and to hell with distributions. Bundle everything above syscalls: ditch glibc for musl, jettison distro-provided libraries, get rid of complicated packaging. <davexunit>Security issues? Who cares, just update all the libraries once in a while. Utilize OS-level sandboxing and exploit protection to help mitigate the usual exploits. " <civodul>these comments sound as if distros had no raison d'être <davexunit>Guix, and all distros, have a tough battle to face against the average software developer. <davexunit>even lwn readers, who you'd think would be more likely to be on the side of distros, are in favor of bundling. <civodul>as users, people probably understand the benefits <mark_weaver>ACTION is making good progress on setting up the wandboard quad as a build slave. <mark_weaver>I hope this debian stock kernel for it has the features we need... <civodul>Steap: some of the links lack whitespace, like "GNUproject", "guixrefresh" <toothbrush0>..and currently, the one included in the tar.gz makes it impossible to build the package... <davexunit>as much praise as haskell gets, it seems like a real disaster to work with. ***davi_ is now known as Guest68627
<Steap>I used markdown to write the article, and had to convert it wordpress <davexunit>I think it illustrates the advantages of Guix well <Steap>gotta find out how to do "--" <Steap>davexunit: yeah, a bit "heavy" though <Steap>my presentation is said to be easier to understand <davexunit>I guess I'm not the best person to judge understandability, I know too much about the subject. ;) <davexunit>I've gotta get 'guix environment --container' merged now so you can remove that note about the full file system access thing ;) <toothbrush0>this is becoming rather tiresome, i just want Idris :p <toothbrush0>okay, so i'm rather frustrated at Hackage right now. I just discovered that they think it's reasonable to update the .cabal file (which should be inside the checksummed .tar.gz) on hackage.haskell.org (as a so-called `Revision') without updating the .tar.gz! <toothbrush0>so, dear Guix, how can i replace a file inside a downloaded tar.gz with *another* downloaded file? <davexunit>toothbrush0: you can create a patch files for this and include it in the 'patches' field to the relevant 'origin' object. <toothbrush0>davexunit: okay. you think that's cleaner than including the on-line "revision file" with a checksum, as an extra input, like the ghc package does? <davexunit>I was under the impression this had to be in the tarball <davexunit>but if not, perhaps that way will work, too. <toothbrush0>well, once the tarball is unpacked, we can swizzle the files <davexunit>I don't know anything about haskell and its build system. <toothbrush0>and i don't know much about Guix's way of manipulating build targets :P <davexunit>toothbrush0: guix can unpack, patch, and repack tarballs <toothbrush0>okay. i don't even think that's needed. i should be able to add a (alist-cons-after ..) phase <toothbrush0>(but still, OMG, frustrating! There, had to vent :p) <davexunit>toothbrush0: use 'modify-phases' instead of 'alist-cons-after' and friends. <davexunit>after so much alist consing, we decided to formalize the process with new syntax <toothbrush0>hm, maybe someone can help. I'm getting an error "ERROR: In procedure copy-file: No such file or directory", but the displayed path does exist on my filesystem. it points into /gnu/store/.. <civodul>toothbrush0: you're getting that error when doing what? <toothbrush0>it downloads the replacement cabal file (i can find it in my /gnu store) <civodul>at that point, OUT does not exist yet, i guess <toothbrush0>taylan: what would be the argument against turning *all* hackage inputs into propagated-input? <civodul>but then, you probably don't want to copy test.txt directly to OUt <toothbrush0>it throws an error and only shows the first argument to (copy-file ..) not the last one :p <taylan>toothbrush0: propagated inputs are generally not nice. when a user installs X, all its propagated inputs are installed too, in a user-visible way. this should be avoided when not absolutely necessary. I think we might eventually want a better solution for pkg-config's broken logic too. <davexunit>long-term, sure, would be great to avoid propagating inputs. <toothbrush0>i'll just propagate the minimum necessary to make packages work, then <davexunit>but many systems simply don't have a RUNPATH equivalent. <taylan>toothbrush0: does Hackage somehow use pkg-config, or does it happen to have the exact same problem as pkg-config? <toothbrush0>i think that their ghc-pkg is a sort of clone of pkg-config <toothbrush0>ACTION .. indicating that it's not a precise description <taylan>well indeed, as davexunit says, many programming languages seem to have this problem. IIRC Elisp also had it. I don't remember what we do with Python, and no idea about Perl. <davexunit>propagating is unideal, but thankfully Guix has profiles to deal with any conflicts that may happen. <taylan>in fact in the case of Elisp (and maybe Guile?) it's not just a mistake of the checking mechanism; all dependencies of a library really need to be installed because there's no such thing as referring to them with absolute file names. (actually there seems to be, according to the docs of 'require' in Elisp, but it hasn't been looked into much yet AFAIK) <taylan>maybe the problem in Haskell is more like with Elisp than with pkg-config then <toothbrush0>i'm honestly not too clear on the nuts and bolts, indeed <mark_weaver>civodul: hydra-slave2 is online and functioning. should the 'donate' web page be updated? if so, how? via the CVS repo on savannah? <mark_weaver>hmm, I guess those pages are generated from sxml, but I don't know how that works or how to modify it. <bavier>toothbrush0: the patch I sent recently to the mailing list should let us avoid propagating most inputs in ghc packages <bavier>and even then it would be pushed to core-updates <toothbrush0>then i'll wait before trying to submit my patches for review <bavier>btw, what are you packaging that's requiring so many ghc packages? <lfam>If I alter bash.scm, and then build it from within `guix environment guix` and /.pre-inst-env, which takes forever, is there a way to make that new bash package visible to operations that are not performed within `guix environment`? <lfam>For example, I did that, and then I rebuilt a package that depends on bash, but guix selected the old bash. <lfam>I could just build the dependent package from within `guix environment`, but I'm wondering if there are other ways. <lfam>I mean, I think I "could just" do that. It's building now and I didn't see which bash it chose. I will find out after the build. <bavier>lfam: were you also using ./pre-inst-env outside 'guix environment'? <lfam>No, you can't do that, right? <lfam>I thought it only worked once you set up the environment <lfam>No, my failed try was a regular ol' `guix package -i package_name` <bavier>it makes sure guix picks up the modules in the working tree <lfam>Oh no, it's bootstrapping again! :( <lfam>I just let it do this overnight. What is going on here? <lfam>I didn't make any changes between now and then <mark_weaver>lfam: if you modified the 'bash' package, then since 'bash' is needed for almost every build, everything will need to be rebuilt. <bavier>lfam: does it do the same from within 'guix environment'? <lfam>bavier: I already rebuilt bash overnight, with everything that entails, from within `guix environment`. Now, I wanted to rebuild the package recutils from within `guix environment`. Recutils depends on bash. Shouldn't the bash and deps I rebuilt overnight be used here? <lfam>bavier: Maybe I am wrong about what's happening, and different things are being rebuilt. I'm not sure how to read the "to-do" list while `guix build` is happening. But it's rebuilding libgcrypt, gmp, etc. Things I thought were rebuilt overnight. <davexunit>lfam: any reason why you didn't build a separate bash package to test this includes thing so that you didn't have to rebuild the world? <lfam>davexunit: I did. Once that worked, I put it into the guix source tree to test the patch for real in advance of submitting to the ML. <bavier>is that the bash you built already? <lfam>I didn't think it was proper to submit the patch without seeing what happened when all of Guix is using it. <mark_weaver>lfam: I guess that's not needed in this case. it will have to be applied to the 'core-updates' branch anyway, where it is expected that breakage might result, and also if the only change is to install more headers to the 'include' output (seldom used), we can probably guess that it's most likely safe. <toothbrush0>bavier: do you think it's best if i try to rework all my hackage patches against core-updates, to see if your patch makes a difference for the propagated-inputs? <bavier>toothbrush0: I wouldn't worry about it at this point <bavier>we may just take a sweep over all the ghc-* packages later to clean up <civodul>mark_weaver: yes, you can update donate.scm in guix-artwork.git, then run export-web-site to put the HTML files in a CVS checkout, and finally "cvs ci" in there <toothbrush0>bavier: yeah, at the moment i'm just making stuff consistent with the most recent Haskell Platform release. <civodul>it's great to have another ARM box online <bavier>I'd offer you the several hundreds of haskell packages I have sitting localling, but many of them are surely outdated anyhow <toothbrush0>Gaaaah, right at the end of the process, it says "command `cc` not found!" <toothbrush0>but that won't work in my case, since it's a cabal build, not gnu <bavier>question -> many of the font packages we currently have simple copy tarball contents into the store; if the option exists, would we rather build the OTF etc files from source? <civodul>bavier: why not, we'd need to investigate the pros and cons <bavier>I've not looked at our current fonts to see if it's possible, but I was looking at adding a new font where it's an option <mark_weaver>bavier: sounds good to me. I'd prefer to build everything from _true_ source code wherever practical. <civodul>yes, same for me; i was just wondering about the "practical" bit <mark_weaver>civodul: when I attempt to check out the guix web site CVS repository, it gets stuck at some point, after printing "U guix/static/base/img/screenshots/thumbs/guixsd-xfce-icecat-emacs.png" <mark_weaver>I tried it on both my Yeeloong (mips) and X200 (x86_64) both running GuixSD <mark_weaver>the commands I used are: export CVS_RSH=ssh; cvs -z3 -d:ext:mhw@cvs.savannah.gnu.org:/web/guix co guix <civodul>mark_weaver: you may have to C-c and then "cvs up" <civodul>i did that checkout a long time ago and don't have any problems with "cvs up" tho <davexunit>I wish GNU would just give projects permissions to rsync to a subdir of the website <toothbrush0>does anyone have a hint to setup emacs to indent (define-public ...) package clauses properly/automatically? <toothbrush0>well, on the ML people sometimes suggest using only one space for indentation, whereas my Emacs automagically puts 2 in <toothbrush0>okay, then i'll stop worrying and learn to love the... wait, what? <civodul>toothbrush0: there's a .dir-locals.el file that should DTRT <civodul>plus a brand new guix-devel mode that does crazy things <davexunit>I need to learn how to use all the nice emacs stuff <toothbrush0>when i thought it did, it actually didn't, back then <civodul>davexunit: BTW, was my reply about 'guix environment --container' of any use? <davexunit>civodul: I haven't looked further, but you got to about the same point that I did. <davexunit>I understand why that second exec would fail <davexunit>that's the whole reason for using system* and not system <davexunit>to not rely on a command interpreter to exec a program <civodul>iyzsong: i think you forgot to remove the patch from gnu-system.am <davexunit>civodul: btw, that service graph is *awesome* <davexunit>I love the visualizations we can do on our systems. <davexunit>today I showed some people at work the graphs I can generate of ruby gem dependency graphs <rekado>davexunit: did it have the desired effect or did they vow to stop using ruby ...? <davexunit>someone was having trouble with the exact gem that I included a graph of in my "ruby on guix" blog post <davexunit>because they didn't have the postgresql header files available <davexunit>and they asked me "why can't bundler install this?" <davexunit>and that's just such a great question to be asked for a Guix hacker. <civodul>can't bundler produce a dot graph as well? <davexunit>but it certainly describe the full dependency graph of a gem with native extensions <mark_weaver>ah, and the GC finished on hydra, so I can start another evaluation to build it <davexunit>uh oh, for some reason guix isn't aborting downloads when I press C-c in my terminal <civodul>davexunit: i was playing with call-with-container; if i add the 'mnt' name space, then the child process (the one that calls the thunk) segfaults <davexunit>what specific list of namespaces were you using? <davexunit>civodul: anything else special? I can try to replicate. <civodul>i was trying to see if i could come up with a reduce test case for the 'guix environment --container' thing <mark_weaver>civodul: thanks for the suggestion to abort and then use "cvs up". that worked. <mark_weaver>ACTION used CVS every day 20 years ago, but now I can hardly remember how to use it. <mark_weaver>civodul: where is the 'export-web-site' program that you referred to above, and how do I run it? <davexunit>civodul: thanks, I'll see what happens on my machine. <davexunit>it's disheartening that it caused a segfault :( <civodul>mark_weaver: it's a procedure in the (www) module; you give it the target directory and that's it <lfam>Is there a way to tell guix-daemon to use something besides /tmp to build in? Or do I need to enlarge my /tmp? <lfam>And if I do need to enlarge from 3.1 gb, what's a good size? <rekado>lfam: TMPDIR=/somewhere-else guix-daemon .... <mark_weaver>hmm, I was hoping that "C-x v d" in emacs would show me what changes were made to the CVS repo, but I guess that's not implemented. <mark_weaver>I'd like to see what changes were made by 'export-web-site' before I push. <davexunit>civodul: I do not see a segfault when I run your code <davexunit>I tested on a mixed ubuntu/guix system, but AFAIK only guix stuff was used and I'm on libc 2.22 as well <mark_weaver>it's not easy to see the changes in this diff output, since the changed line is about 1.5 kilobytes... <davexunit>because it's typically not for people to read <davexunit>civodul: works fine on my guixsd laptop as well <mark_weaver>bavier: yeah, the problem is that I don't see a "cvs wdiff" command, and it doesn't give me easy access to the things being compared. <mark_weaver>obviously I can make this work, just wondering if anyone knows an easier way to do this. <mark_weaver>okay, I copied the output of "cvs diff -u" into an emacs buffer, put it into diff-mode, and then used 'diff-refine-hunk' to highlight the changes.