IRC channel logs


back to list of logs

<paroneayea>might need to package j-bob-guile in guix next
<davexunit>ooh someone wrote that?
<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 ?
<davexunit>paroneayea: that's good news
<paroneayea>I have The Little Prover
<paroneayea>but have not worked my way through it yet.
<paroneayea>my goal is to finish all my copies of the Little books before year's end.
<paroneayea>an unlikely goal :)
<paroneayea>but I will try
<davexunit>that's a nice goal
<davexunit>I need to pick up the little prover still
<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>But my guile is weak
<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
<davexunit>(pk 'current-directory (getcwd))
<lfam>Is pk a print statement?
<paroneayea>lfam: pk is a print debugging tool deluxe
<paroneayea>but little documented!
<paroneayea>lfam: it returns the last thing evaluated
<paroneayea>lfam: but also prints out the expression
<paroneayea>so you can wrap parts of code in pk
<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:
<paroneayea>build bash in its own profile
<paroneayea>it'll save you sanity.
<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
<lfam>bavier: yes :(
<bavier>but you could possibly test recipe changes by building a bash that's lower down the dependency chain
<lfam>Do explain!
<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.
<lfam>bavier: ^
<bavier>It should save some building
<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
<bavier>ACTION goes afk
***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 ;)
<francis7>carousel is a lie.
<xd1le>is it possible to use xinit/startx to start an x session instead of a
<xd1le>display manager in guixsd?
<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>right now, that's all handled by our 'slim-service'
<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>can understand
<xd1le>but i hate unnecessarily starting x
<xd1le>just a waste of time imo
<xd1le>ofc i'm on a slow hardware.. so yeah.
<xd1le>wait is it possible to not use any desktop environment or window manager?
<xd1le>i.e. just a tty?
<mark_weaver>xd1le: yes, just don't include 'slim-service' in the 'services' field of your OS config
<mark_weaver>(it's included in %desktop-services)
<xd1le>so login would just be a tty prompt or something?
<xd1le>cool. thanks.
<civodul>Hello Guix!
<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
<civodul>ACTION adds "guix system graph"
<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>civodul: hi! I looked into dbus update too, and think we can remove the 'dbus-localstatedir.patch', the $out/etc can be remove safely. here is my patch:
<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>(keeping the comments in there)
<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?
<davexunit>the service refactor is a reality. :)
<iyzsong>civodul: yeah, when thought about update dbus, I think better do it after the services things merged :-)
<alezost>davexunit: re 'guix.d': Federico used it to avoid name clashes among emacs packages: <>
<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>hey, toothbrush0!
<civodul>toothbrush0: do you think you could manage to do that? :-)
<toothbrush0>civodul: yo!
<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>alezost: okay, well I thought I did that...
<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>we could make an exception
<toothbrush0>right, sort of same thing
<civodul>maybe you could post a single patch, explaining the problem, and see what people think?
<davexunit>I'd like to have some sort of organization
<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?
<davexunit>yes it is
<alezost>davexunit: try "M-: (guix-emacs-find-autoloads)"
<davexunit>that returns the correct thing
<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
<davexunit>perhaps I have to restart emacs
<toothbrush0>oof, 115 new packages at my last count :/ and i still have to neaten up the descriptions etc. :/
<davexunit>or re-evaluate something
<toothbrush0>ACTION prepares for a sleepless night
<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>that's clear
<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) :-)
<toothbrush0>haha thank you iyzsong
<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?
<davexunit>I haven't had to do that in the past.
<toothbrush0>davexunit: so don't worry, i'm not done yet
<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?
<civodul>davexunit: is this on GuixSD?
<davexunit>civodul: yes
<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
<davexunit>that's what I was asking about
<davexunit>and you said it would happen automatically
<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>but OK, this is a sensible explanation.
<davexunit>alezost: no.
<davexunit>I don't really know how to use the emacs interface tbh
<davexunit>still need to learn it.
<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>sure, I understand.
<davexunit>I just didn't know how these ELPA repos worked.
<davexunit>thanks for the explanation.
<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
<davexunit>but I guess they weren't ELPA packages.
<davexunit>alezost: thanks
<davexunit>I'll do that
<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>this thread is depressing
<davexunit>concerning Fedora becoming more lenient towards bundling
<davexunit>and a lot of lwn users being pro-bundling
<bavier>:( subscription only
<davexunit>bavier: damn it. sorry.
<bavier>davexunit: no worries
<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
<davexunit>and that distros are terrible
<toothbrush0>davexunit: :(
<Gamayun>Hmm, they've just removed the old policy on their wiki, not put up the new one, it seems.
<bavier>uff da
<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>oh well
<civodul>as users, people probably understand the benefits
<civodul>(of distros)
<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>mark_weaver: excellent!
<civodul>Steap: thanks for the nice article!
<mark_weaver>looks like the kernel has the needed features :-)
<civodul>Steap: some of the links lack whitespace, like "GNUproject", "guixrefresh"
<toothbrush0>geez. Has anyone ever had this issue? There's a discrepancy between the Cabal file in the tar.gz and the description page on Hackage! Example: versus
<toothbrush0>..and currently, the one included in the tar.gz makes it impossible to build the package...
<civodul>woow, scary
<davexunit>as much praise as haskell gets, it seems like a real disaster to work with.
***davi_ is now known as Guest68627
<Steap>civodul: oh right
<Steap>I used markdown to write the article, and had to convert it wordpress
<Steap>so there are a few glitches
<Steap>gotta fix that
<davexunit>Steap: also -- were turned into em-dashes.
<davexunit>really nice article, though.
<davexunit>I think it illustrates the advantages of Guix well
<Steap>oh right
<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>davexunit: that's sort of the way i see it
<toothbrush0>oh my, has a similar discrepancy! this time the base library. it's <4.8 in one, <4.9 in the other!
<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 (as a so-called `Revision') without updating the .tar.gz!
<toothbrush0>that is causing my breakage!
<toothbrush0>see here:
<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>i'll look at the haskell build system
<toothbrush0>thanks davexunit
<toothbrush0>(but still, OMG, frustrating! There, had to vent :p)
<davexunit>toothbrush0: use 'modify-phases' instead of 'alist-cons-after' and friends.
<toothbrush0>um, okay, i'll look for examples to crib from
<davexunit>after so much alist consing, we decided to formalize the process with new syntax
<toothbrush0>ah, that can't hurt!
<toothbrush0>the alists do get cumbersome
<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/..
<toothbrush0>here's my package so far: <>
<civodul>toothbrush0: you're getting that error when doing what?
<toothbrush0>./pre.. guix build ghc-split
<civodul>ah, ok
<toothbrush0>it downloads the replacement cabal file (i can find it in my /gnu store)
<toothbrush0>but cannot seem to copy it
<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>so you'd have to (mkdir out) first
<civodul>but then, you probably don't want to copy test.txt directly to OUt
<toothbrush0>maybe out isn't the right place then!
<civodul>yeah :-)
<toothbrush0>why isn't the error clearer, argh :P
<toothbrush0>it throws an error and only shows the first argument to (copy-file ..) not the last one :p
<toothbrush0>okay thanks for the pointer!
<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.
<davexunit>(including Guile)
<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
<taylan>I see
<toothbrush0>ACTION waves hands
<toothbrush0>ACTION .. indicating that it's not a precise description
<toothbrush0>civodul: it works! yay! thanks!
<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.
<toothbrush0>building ghc-split
<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)
<toothbrush0>right, that's kind of the thing with Haskell
<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
<toothbrush0>when was it pushed, bavier? i should fetch again
<bavier>hasn't been pushed yet
<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?
<bavier>lfam: you can
<lfam>I thought it only worked once you set up the environment
<lfam>I had no idea
<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?
<mark_weaver>yeah, that seems like the right approach to me.
<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.
<davexunit>lfam: oh okay. nvm me, then!
<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.
<mark_weaver>but I appreciate your thoroughness!
<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
<toothbrush0>okay, good news — that'd be a lot of work now :)
<bavier>we may just take a sweep over all the ghc-* packages later to clean up
<civodul>mark_weaver: woohoo!
<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
<mark_weaver>civodul: okay, thanks!
<civodul>thank *you*!
<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>toothbrush0: cool
<bavier>I'd offer you the several hundreds of haskell packages I have sitting localling, but many of them are surely outdated anyhow
<toothbrush0>Idris is built! :D
<toothbrush0>that was rather involved :/
<toothbrush0>lesson: GHC compilation is slow :P
<toothbrush0>Gaaaah, right at the end of the process, it says "command `cc` not found!"
<toothbrush0>lfam: yeah, thanks, something like that is needed.
<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
<bavier>mark_weaver: ok
<bavier>civodul: I'll explore it a bit
<mark_weaver>bavier: thanks for working on it!
<bavier>mark_weaver: np
<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>does anyone else see this?
<mark_weaver>the commands I used are: export CVS_RSH=ssh; cvs -z3 co guix
<civodul>mark_weaver: you may have to C-c and then "cvs up"
<civodul>this thing is a bit unreliable :-)
<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
<davexunit>then we could skip all this CVS craziness
<toothbrush0>does anyone have a hint to setup emacs to indent (define-public ...) package clauses properly/automatically?
<civodul>toothbrush0: it just works!
<civodul>(or does it?)
<davexunit>yeah, it does.
<toothbrush0>well, on the ML people sometimes suggest using only one space for indentation, whereas my Emacs automagically puts 2 in
<toothbrush0>(i don't mind, but if you people do i'll change)
<davexunit>2 is correct
<toothbrush0>okay, then i'll stop worrying and learn to love the... wait, what?
<davexunit>love the parens, I think.
<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>craaaAAaAazy things
<civodul>courtesy of alezost, the Emacs boos
<civodul>yeah, cwazy!
<toothbrush0>yeah i'll have to try that mode, thanks civodul !
<davexunit>I need to learn how to use all the nice emacs stuff
<toothbrush0>idris builds and installs and runs
<toothbrush0>when i thought it did, it actually didn't, back then
<davexunit>back in the day
<toothbrush0>yeah, like, an hour ago :P
<davexunit>those really were the days
<davexunit>I remember like it was yesterday...
<civodul>davexunit: BTW, was my reply about 'guix environment --container' of any use?
<toothbrush0>davexunit: :P
<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>but the first remains a mystery
<davexunit>the first should work
<davexunit>that's the whole reason for using system* and not system
<davexunit>to not rely on a command interpreter to exec a program
<davexunit>and the bootstrap guile is executable
<davexunit>#o555 permissions
<civodul>bah, ok
<civodul>iyzsong: i think you forgot to remove the patch from
<civodul>ah no, you did, sorry
<davexunit>civodul: btw, that service graph is *awesome*
<davexunit>I love the visualizations we can do on our systems.
<civodul>yes, it really helps
<davexunit>today I showed some people at work the graphs I can generate of ruby gem dependency graphs
<davexunit>trying to get everyone on board ;)
<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.
<davexunit>s/for a/as a/
<civodul>can't bundler produce a dot graph as well?
<davexunit>maybe it can, dunno.
<davexunit>but it certainly describe the full dependency graph of a gem with native extensions
<civodul>yes that's for sure
<davexunit>er, it certainly can't!
<davexunit>bad typo
<davexunit>I "accidentally a word" there
<davexunit>mark_weaver: thanks for upgrading icecat!
<mark_weaver>np, I'm glad to be able to use it again :)
<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
<davexunit>maybe it's a screen problem I'm having
<davexunit>nvm me
<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>civodul: well, that's new to me.
<davexunit>what specific list of namespaces were you using?
<civodul>'(pid user mnt)
<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.
<civodul>ah, see?
<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 :(
<davexunit>all my existing container tests succeed
<civodul>mark_weaver: it's a procedure in the (www) module; you give it the target directory and that's it
<mark_weaver>ah, okay
<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.
<mark_weaver>ah, "cvs diff".
<davexunit>civodul: I do not see a segfault when I run your code
<davexunit>I have another computer to try it on
<davexunit>this is weird
<civodul>i'm on libc 2.22; you?
<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
<davexunit>now to test on my laptop running guixsd
<mark_weaver>it's not easy to see the changes in this diff output, since the changed line is about 1.5 kilobytes...
<bavier>mark_weaver: wdiff?
<davexunit>bavier: sxml->sxml writes a single line
<davexunit>it doesn't pretty-print the output
<davexunit>because it'
<davexunit>because it's typically not for people to read
<bavier>I see, ok
<davexunit>civodul: works fine on my guixsd laptop as well
<davexunit>I am presented with a guile REPL
<davexunit>and I exit with ,q just fine
<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.
<mark_weaver>not quite as nice as magit, but workable :)
<bavier>yeah, nice
<davexunit>cool :)
<civodul>iyzsong, mark_weaver:
<mark_weaver>civodul: thanks