<ecbrown>i have a package that would normally be installed in /opt/mypackage/, and in that dir is the usual bin lib, plus two necessary static data directories, plus a bit of documentation. is there a guix convention for handling this? i would not want to crap up the ~/.config/guix/current directory <ecbrown>(though if you are installing this package, you really really wouldn't mind :-) <efraim>You could swap out '/opt/mypackage' for $PREFIX <ecbrown>efraim: i guess i meant that it seems that there are programs that fit nicely into /usr/bin, /usr/lib, and /usr/share/myprogram/data-and-whatnot and those that go into an "opt" directory because they are not respectful <ecbrown>i will work on it some more... maybe that stuff is relocatable <ngz>Hello. I have an error when trying "git pull" from root: "error: Git error: the SSL certificate is invalid". Do you know what is that? <civodul>ngz: does /etc/ssl/certs exist, and/or did you set SSL_CERT_DIR? <ecbrown>ngz: i think you need to make sure nss-certs is installed, and also SSL_CERT_DIR, SSL_CERT_FILE, GIT_SSL_CAINFO <ngz>Ah. Of course. I don't have this in root's home. <civodul>in that case 'guix pull' should use Let's Encrypt certificates though <civodul>(see honor-lets-encrypt-certificates! in guix/scripts/pull.scm) <tune>anyone else seeing rust fail to build? ***jonsger1 is now known as jonsger
*ecbrown wonders why guix doesn't target latest and greatest gcc compilers, and pin packages back that don't build ***daviid is now known as Guest31072
***Guest31072 is now known as daviid
***rekado_ is now known as rekado
<rekado>ecbrown: there were some problems with our GCC 6, so it isn’t currently used. Many packages failed to build with GCC 7, so it didn’t make sense to use GCC 7 as the default. <rekado>something isn’t quite right with the mechanism that fetches the bootstrap binaries. <rekado>the first thing I noticed is that make-bootstrap builds Guile 2.2, but (gnu packages bootstrap) seems to expect Guile 2.0. <janneke>rekado: working on the new i686-linux bootstrap, i think i found package-with-explicit-inputs to be leaky <janneke>i rewrote most packages that use that to a (arguments `(#:implicit-inputs? #f...(inputs '()) form <janneke>that more dependencies than the explicitly listed ones are used (leak in) <janneke>like: gcc-bootstrap-0, binutils-bootstrap-0 <janneke>ah, but that's a different issue i guess <janneke>it took me quite a while to have the initial mes bootstrap packages really not depend on anything unwanted... <rekado>I’m having really weird problems, like the derivation that should download the static Guile seems to succeed, but later the derivation that should unpack it fails — and sure enough: the tarball doesn’t exist, only a lock file. <rekado>but I *saw* it download the file! <janneke>rekado: this inspired me to collapse the wip-bootstrap branch into a couple of patches <janneke>probably some (hopefully) harmless preparation patches, and a couple of mes bootstrap patches <janneke>possibly we could work together or benifit from eachother wrt the preparations... <mbakke>janneke: That would be really helpful! I am interested in bootstrap too, as I'm trying to get GCC7 to become default. <janneke>mbakke: ok, great. civodul and i talked about this but i hoped to postpone it and possibly have civodul do it :-) <janneke>now i'm inspired to take it up and have some ideas of how to do the split <roptat>finaly! my torrent implementation received a piece :D <roptat>now I need to do something with it :) <nckx>If that is your real name. <nckx>jlicht: o/ (and: thanks!) <ecbrown>thanks all for your comments on default gcc. *janneke collapsed the 210 commits on wip-bootstrap to 13 (well more than the promised hand-full) <rekado>bleh, I get a segfault trying to run “patch-and-repack” on the hurd, specifically using tar and xz from the bootstrap binaries. <rekado>the segfault only happens when using “--mtime=@0” <nly>What is run-time search path? <nlyy>In the context of "To ensure that libraries written in those languages can find library code they depend on at run time, run-time dependencies must be listed in ‘propagated-inputs’ rather than ‘inputs’." <janneke>the path that such a program uses at run time to look for its dependencies? <janneke>nly, nlyy: it may help if you make your question more specific <nlyy>janneke, that's what i meant, where does it look for the binaries it needs to run? <nlyy>This is from guix manual 4.1.1 'package' Reference <nlyy>sounds like a complicated task to do, when these hashes are involved <rekado>nlyy: different languages handle this with different mechanisms, but often they respect environment variables. <rekado>Guix can set these variables automatically. <rekado>for example, the R will look for R packages in directories listed in the R_LIBS_SITE environment variable. *janneke just tries to add oftc.net to znc -- what a disaster interface this is *ecbrown successfully packages OpenMolcas \o/ <ecbrown>having done this, i have a number of questions, i hope #guix would indulge me <ecbrown>i had to make a change to openblas. i would like to rebuild all packages that depend on it, and i can get this with guix graph. is there an easy way to just dump a list of dependents of the first level, in textual form? <ecbrown>i'd even settle for (what seems to be) a better approach and rebuild each dependent, at infinite level <ecbrown>(basically the change is to insist that the Fortran interfaces are 64-bit on 64-bit machines) <ecbrown>ahh guix refresh --list-dependent openblas gets me close enough <nly>ecbrown: I think one way to do what you want is by: cloning the guix repo locally <nly>1. Cloning the repo to local dir <nly>2. Making desired changes in openblas <nly>3. Using the local repo to build the packages <nly>But I think you are asking which packages will be affected? I am noob, though <nly> # note if the local guix repo is on the same hash as guix-channel then only the updated openblas dependents should re build <ecbrown>nly: yes, i've cloned guix and am working with ./pre-inst-env <apteryx>inheriting a package doesn't mean the package has to be bult beforehand, right? <roptat>apteryx: no, you only inherit from the recipe <roptat>you don't need the binary for that :) <apteryx>I'm planning to have package B inherit from A, and package C using package B, then in package A use package C... this won't work, right? <apteryx>(B would be a documentation less bootstrap version of package A) <roptat>ah I'm so close... one more bug and I think I will be able to download a torrent <roptat>apteryx: I think you can do that <roptat>because the dependency graph is loop-free <roptat>I think if you look for *-bootstrap packages in the java world you'll find a few examples like that <nly>s/same hash/same commit <RetardedOnion>if i want to create a config file in an existing subfolder of /etc, how would i do that? etc-service-type doesnt work because /etc/subfolder does already exist <pkill9>you could use the 'special-files-service-type' which creates a symlink <pkill9>and point that symlink to a copy of the config file in the store <divansantana>Hi all. So after a guix pull, I try a system reconfigure but it results in guix/gcrypt.scm:33:2: error: %libgcrypt: unbound variable . Any ideas? :) <apteryx>rekado: do you have an idea if I should include format files (.fmt) for a latex package? Would this only work with the version used for compilation (i.e, LuaTeX?). <jlicht>hulten: the web server on that host is currently offline due to some bug that was found (and fixed) this weekend. <jlicht>but it should be back online once/when the right people have a look at it :) <hulten>OK, so people are aware, and it should work again soon, great! :-) <hulten>I am trying to burn a DVD on GuixSD, and I get «BraseroGrowisofs stderr: :-( write failed: Invalid argument». Anyone seen this? <nckx>hulten: Any logs or more info? Something similar to a --verbose option? (I don't use Brasero so can't help you find them. :-( indeed.) <hulten>nckx: I'll see if I can get more information from brasero. <hulten>nckx: If you burn to cd/dvd, what would you recommend? <rekado>jlicht: it’s weird. Attempts to get an answer from Debbugs fail on that server, but the same code works fine from other IPs. <nckx>hulten: Yeah, I'm probably the worst person to help you. I don't... <hulten>brasero(1) doesn't show a verbose option. <hulten>nckx: Thanks for trying, though! :-) <jlicht>rekado: I was a bit confused; does mumi use mailutils, or the soap debbugs interface to get its info? <rekado>it uses mailutils just to decode some mail formats returned by the SOAP service *nckx doesn't even own a burner. <nckx>hulten: All I can say from that little info is that it *looks* like a legit burning error and not a Guix packaging one. You shouldn't get laughed out of the upstream help channels... <nckx>You could take a look at that brasero-3.12.2/libbrasero-burn/brasero-burn.c:2859 line if you feel up to it. <civodul>rekado: i've been thinking about Outreachy topics, though most ideas that come to mind are existing projects to complete, which is not always "fun" <civodul>one of them would be guix-jupyter, then there's the Cuirass web UI, the GuixSD installer, things like that <civodul>the UI thing is an important milestone for 1.0, so we might not want to make it an Outreachy project <janneke>civodul: the gash/geesh thing could be fun -- but also that's not new <atw>Can I know more about why the autoconf wrapper is necessary? <rekado>civodul: thanks for thinking about topics! <rekado>I think it is crucial, though, that other members of this community do that. <rekado>civodul: Outreachy is not like GSoC; we actually need rather detailed project plans and it doesn’t seem like a good idea to enlist you in preparing one and mentor the project. <rekado>but they’d need to be “processed” enough to make for a reasonably challenging and engaging internship project. <rekado>there should be reasonable milestones and less … “we’ll see what happens, let’s explore this together” <lfam>I was thinking that the Cuirass web UI would be a really valuable contribution, with specific goals, and that I would be willing to mentor it. But I understand if we'd rather try to make it happen sooner. <rekado>yes, it would be quite some time before we could reap some usable results. <rekado>The internship would begin in December and end in March. <lfam>Right, ideally Cuirass would be approaching feature parity with Hydra by then <rekado>writing an installer might be a good project; it would not *need* to be built upon the ncurses installer. <rekado>but I know too little about existing installer frameworks that might be appropriate as a foundation. <civodul>rekado: re exploration: i agree this has to be somewhat better prepared than GSoC projects <civodul>(i also agree it'd be good for other people to chime in ;-)) <roptat>on the guile-torrent side: I'm done! (except that somehow I don't receive valid data... or I can't validate it correctly) <roptat>maybe that's just a size issue... <civodul>rekado: re the installer, it would be maybe unproductive to start anew when we already have one that seems in rather good shape <roptat>also I'm downloading everything in the reverse order (starting from the last piece) <roptat>and that last piece is the same size as other pieces, which is a bit strange unless the file size a multiple of 512KB <civodul>substitutes over BitTorrent could have been a great project but i feel like roptat will be done by the end of the week ;-) <rekado>civodul: I wasn’t so sure about the state of the installer; I only remember trying it and being unable to leave it. But this may have been in a much earlier state. <roptat>PackageKit doesn't have these nice features guix has, like rollbacks, does it? <rekado>roptat: I just looked at the dbus specs and none of the things seem to be relevant for rollbacks. <rekado>I don’t know if PackageKit would be useful for us. <roptat>installing things is already useful I guess <rekado>I guess it could be useful for the few packages that offer to install missing optional packages when certain features are requested at runtime. <rekado>but I wonder if that’s really enough for an internship. <rekado>I’d like projects to be extensible if the initial goal is reached sooner than anticipated. <rekado>I don’t see how we could do that with PackageKit where all we know is that the package installation feature is something we might want. <civodul>or maybe some other GUI frontend, provided it can meet our goals better <civodul>i think people mentioned other generic packaging GUIs in the past, not sure if they'd be more appropriate <rekado>GNOME Software supports different plugins to provide software. <rekado>One of them is a PackageKit plugin, but they also have an appdata plugin. <rekado>looking at the appdata specification, though, it also doesn’t really seem applicable. <rekado>but the idea is that plugins are supported, so one could image a Guix-specific plugin. <rekado>they already have plugins for snap and flatpak FWIW *rekado increases the proxy timeout on issues.guix.info to make it usable again <rekado>since Debbugs is a bit too slow I would like to use websockets to stream the Debbugs results to the browser after the page has been loaded. <atw>what PATH does command -p give? <lfam>atw: For which shell? It should be hardcoded in the shell's source code? <lfam>I mean, "It should be hardcoded in the shell's source code." No question mark :) <atw>lfam: bash. I needed affirmation that it was something hardcoded and non-Guix, as that explains why "command -p sh" in a makefile was causing a build failure. I'm patching it to just "sh" <lfam>Using `command -p` in a makefile is basically a bug, IMO <lfam>It makes the Makefile relatively unportable <rekado>(issues.guix.info is back, but it’s slow) <atw>I'm quite guilty of writing works-on-my-machine makefiles, in my pre-guix days :P <civodul>rekado: GNOME Software would be an interesting target indeed <civodul>rekado: i suppose that's what many use <apteryx>if we get GNOME Software to be able to use Guix, my dad will be able to use it ;) <ecbrown>i'm still hung up on this 64-bit integer thing in OpenBLAS. I'm curious if anyone is a regular user of python-numpy and python-scipy: what happens if you use an array larger than 2**31? <ecbrown>this is not very big by today's standards <rekado>ecbrown: could you send this to guix-devel@gnu.org? We could discuss it there. <rekado>I’m not using numpy/scipy, but we do have users of these packages at the institute. <rekado>haven’t heard any complaints so far.