IRC channel logs

2018-09-09.log

back to list of logs

<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
<ecbrown>(are set)
<ngz>Ah. Of course. I don't have this in root's home.
<ngz>Fixed. Thank you :)
<civodul>in that case 'guix pull' should use Let's Encrypt certificates though
<civodul>not sure why it didn't
<civodul>(see honor-lets-encrypt-certificates! in guix/scripts/pull.scm)
*civodul -> zZz
<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
<janneke>ecbrown: i suspect the work simply hasn't been done. if you find a package that's broken, please file a bug report. as to gcc, see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30756
***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
<rekado>what do you mean by “leaky”?
<janneke>that more dependencies than the explicitly listed ones are used (leak in)
<janneke>like: gcc-bootstrap-0, binutils-bootstrap-0
<rekado>oh.
<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 can imagine
<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>hmm, that's weird
<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
<Gooberpatrol66>hi
<roptat>finaly! my torrent implementation received a piece :D
<roptat>now I need to do something with it :)
<nckx>Hullo Gooberpatrol66.
<nckx>If that is your real name.
<jlicht>hey guix!
<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)
<janneke>ecbrown: thanks for your interest
<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”
<rekado>huh
<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?
<efraim>sounds like it
<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.
<nlyy>ah
<nlyy>ty
*janneke just tries to add oftc.net to znc -- what a disaster interface this is
*ecbrown successfully packages OpenMolcas \o/
<nlyy>\o/
*ecbrown plotzes
<ecbrown>(collapses in a heap)
<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>that's a huge change
<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
<ecbrown>damn, python-scipy breaks...
<apteryx>inheriting a package doesn't mean the package has to be bult beforehand, right?
<apteryx>*built
<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
<apteryx>roptat: OK
<roptat>apteryx: I think you can do that
<apteryx>OK, I'll try :)
<roptat>because the dependency graph is loop-free
<roptat>(inheritance doesn't count)
<apteryx>oh, that's neat
<apteryx>:)
<roptat>I think if you look for *-bootstrap packages in the java world you'll find a few examples like that
<apteryx>OK!
<nly>s/same hash/same commit
<nly>Lol
<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?).
<hulten>Is this valid in the channel topic?: «bugs and patches: https://issues.guix.info/» — I get a 504.
<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>Last lines on xterm: https://paste.debian.net/1041557/
<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! :-)
<hulten>and for listening :-)
<jlicht>rekado: I was a bit confused; does mumi use mailutils, or the soap debbugs interface to get its info?
<rekado>the SOAP interface
<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.
<hulten>nckx: Thanks, I may try that!
<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>we have a whole bunch of ideas here: https://libreplanet.org/wiki/Group:Guix
<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.
<rekado>I think that would be too late.
<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)
<civodul>roptat: woohoo!
<rekado>roptat: exciting!
<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>PackageKit integration maybe?
<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> https://github.com/hughsie/PackageKit/blob/master/src/org.freedesktop.PackageKit.xml
<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>hmm right
<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> https://wiki.gnome.org/Apps/Software
<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)
<lfam>(as you discovered)
<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
<apteryx>atw: eh
<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 ;)
*civodul -> zZz
<civodul>later!
<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>(i think i meant 2**32 - 1)
<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.
<ecbrown>rekado: i can do that.
<rekado>thanks!