<sturm>is there a way to search on package contents? I was looking for the binary "as" and got lucky with installing "gcc-toolchain", but is there a way to search for this? ***abbe_ is now known as abbe
<atw>couple of questions about audio: is pulseaudio the only option? should I expect audio to work immediately after installing, e.g. mpg123? <paroneayea>atw: some programs require pulseaudio, but generally if so they'll start it on their own in that case. if a program isn't compiled requireing pulseaudio support, it'll just pipe through vanilla alsa <atw>hmm, maybe I'm having driver problems or something...audio isn't working in icecat or mpg123 <atw>I'm also seeing "[src/libout123/modules/pulse.c:161] error: Failed to flush audio: (null)" from mpg123 ***MightyJoe is now known as cyraxjoe
<rekado_>jmd: looks like there should be an index.html pointing at 0-9.html <jmd>We should invent some protocol to shut lint up when we know it's wrong. <alezost>sturm: there is no way to find a package by file it contains; the best you can do is to search your local store (in a hope that it contains a file you want), like: "find /gnu/store -name '<file-name>'" <jmd>alezost: Having such a feature would be nice. <alezost>jmd: I agree; this conversation raised on irc from time to time, IIUC there is no understanding how to implement it <alezost>it's the feature that I miss the most in Guix (I'm used to run "pkgfile" on ArchLinux) <civodul>alezost: the only way to do that is by building a database of files <civodul>jmd, rekado_: i've just been touching these pages, hence the churn :-) <civodul>we could have a hook in the daemon to update a local database <civodul>but in some cases, people want to know the name of a package that they have not installed yet <civodul>and that would require a server-provided database, which is more problematic <civodul>nothing insurmountable, it "just needs to be done" ;-) <alezost>a server-provided database seems like the only solution to me. A local database is useless IMO: I would like to search for file names in all packages, not just the packages I have locally <rekado_>yeah, for local search "find /gnu/store" is usually sufficient. <civodul>sneek later tell alezost we could have 'guix publish' publish a locally-build database, or answer specific HTTP requests <efraim>find is really slow on spinning drives, locate works faster since it already has a database, or even ls /gnu/store/*/*/file <jmd>I was thinking it could be a feature of hydra/cuirass <efraim>I figure we either collect the data at build time (locally or on hydra/curaiss), but then it's not always acurate since not everything is built at the moment you run guix pull <efraim>or you collect it per-derivation and have to figure out how to present it and how/when to depreciate changes <efraim>although I suppose "acurate enough" is a better starting point than no information <jmd>I agree. It'll not be a disaster if it occasionally gives out of date info. <civodul>i think guix-daemon could build a local database, and then 'guix publish' could make that info available <civodul>otherwise, a simple first step is to rely on updatedb/locate and have 'guix publish' use that as its source <civodul>it won't be as good because it'll see things that aren't packages <jmd>When is "staging" going to be merged, BTW? <civodul>jmd: when it's built, which should be real soon <civodul>are you volunteering to lead that? :-) <Helius>hi, I need to build R with x86_64-pc-linux-gnu, where I installed guix the system is recognized as x86_64—unkown-linux-gnu. I downloaded guix from git and rebuild it with ./configure --localstatedir=/var --build=x86_64-pc-linux-gnu. Does it make sense ? and then which is the next step ? Alternatively there is a right way to do that ? <Petter>How about specifying files, and commands provided, in the recipes? <civodul>Helius: if you installed Guix for x86_64, then "guix package -i r" will install R for x86_64 <Helius>civodul: yes, that is correct, the point is the “unkonw” part of the I need on the landing node to have “pc” instead of “unkonw”. I need to mix a Ubuntu system with GUIX, and I have already/successfully created a tar.gz with the self contained distribution on the R version I need, the only problem is that R when starts look at the builing system and create an alternative lib/directory with it, so if it is build with “unkonw” or “pc” it ma <civodul>rekado_ may have experience with this <Helius>civodul: maybe I am missing something, I am a very newbie and following Pjotr’s notes and official docs <civodul>at any rate, the solution would involve changing the package recipe for R, not recompiling Guix itself <jmd>In other news... Registrations for GHM 2017 are now open. I look forward to seeing lots of Guix talks there. <civodul>jmd: excellent, thanks for organizing it! <jmd>I'm just organising the venues and accommodation. I'm leaving it to others to organise the programme etc. <civodul>there were a few Guix talks at this summer's GHM, but a relative lack of hacker spirit ;-) <jmd>It is my hope that by holding GHM in the same building as the accommodation, it'll be more conducive to the "hacker spirit". <jmi2k>Can someone test if asciinema can build from source? I run guix build --check asciinema , but it fails. <Petter>guix build: error: build failed: derivation `/gnu/store/ymh3kylslsrlj293mnw016viis02vii1-asciinema-1.3.0.drv' may not be deterministic: output `/gnu/store/00n4jf8q3cg08rws8apyqfjbnyjnvkfg-asciinema-1.3.0' differs <jmi2k>Ok, thanks. When I try to build, it fails because python-requests is missing <Petter>jmi2k: I got some error with requests-http-adapter in the check phase, but it carried on anyway. <jmd>But I think jmi2k's problem is that it is not building *at all*. <jmi2k>I'll test it in a clean virtual machine, because it *just fails* for me. But thanks for testing :D <civodul>jmi2k: could you send the Guix commit you're using in that mailing list thread, as well as the "./pre-inst-env guix build" command and the tail of its output? <jmi2k>I'm using GuixSD, how do I get the build commit? And what's pre-inst-env? It isn't necesary in GuixSD right? <jmd>It's only necessary if you're building from git. <jmi2k>Oh, fine. I'm not using any git version, just regular guix commands inside GuixSD. Anyway, I'll retry it in a VM to be sure I didn't mess up anything, and I'll come back with the results <htgoebel>I run the daemon with su -c './pre-inst-env guix-daemon --build-users-group=guixbuild &' <htgoebel>When I try building I get the error: "guix: offload: command not found". <Petter>Trying to use a "package" variable, but I get an "ERROR: Unbound variable: importpath" in the 'unpack phase. Can someone help? http://sprunge.us/XIXb <thomasd>Petter: the code in 'modify-phases runs at build time, and does not "know" about the environment of the package variable <thomasd>so the variable importpath is not known to the build script <thomasd>also, "go install importpath" will not work because the build daemon doesn't have network access <Petter>The last part is a Go thing, and it works when I use text instead of variable. <thomasd>(if I understand correctly that the idea is to fetch something from github, not sure what "go install" does :)) <Petter>It install the package at $GOPATH/src/github.com/calmh/du <Petter>Can I make a "modify-phase" variable? I'm having some problems. <thomasd>so then the remaining question is how to pass this variable to the build daemon... afraid I can't help you there <Petter>Ok, thanks though! I'll drop the variable for now. <thomasd>I wonder what the solution is, though. Maybe something could be done with macros? I lack the scheme-fu (for now :0) ). <Petter>I'd like to join all (inputs) to a colon separated string. Any tips for how to do this? <civodul>Petter, thomasd: #:inputs on the build side (as seen by build phases) is an "alist" <civodul>like (("coreutils" . "/gnu/store/...-coreutils-8.25") ...) <thomasd>ah, I should stop giving advice here :-) <jmd>How can I get the configuration from which a service was configured? <Petter>civodul: Thanks! Looking into it. <Petter>thomasd: Hey, at least I got to look at hash-maps, I'm unfamiliar with those as well :) <thomasd>Petter: how about (string-join (map cdr my-alist) ":") (if you want the store path of each input) <Petter>thomasd: Thanks, it works! However, I got more entries than I expected, and want. <Petter>Guess the list is populated behind the scenes with other stuff, I was hoping for the (inputs) specified in the recipe. <Petter>Hm, maybe it's a build system thing... <civodul>Petter: there are also search-path related procedures in (guix build utils) that may be useful here <civodul>as an analogy, you cannot get source code from a .o file <roelj>What will go wrong when I have multiple machines running guix-daemon, and make /gnu/store shared between the machines? <roelj>In theory, this should be no problem, should it? <roelj>rekado_: What does guix-daemon do with it? Open it, write to it and close it? So the second trying to open it will get locked out, and has to wait until it's available again.. right? ***Digitteknohippie is now known as Digit
<civodul>roelj: there should be only one daemon, in general <civodul>when you run "make check -j32" in Guix, there are 32 daemons running, and that's ok <civodul>but that's ok only because we arrange for GC operations to be made by only 1 daemon at a time <roelj>But how could I then create containers on all machines, of guix-daemon is running on another? <roelj>So, if I disable the garbage collecting features on all daemons except one, then it might work? <Petter>Hey jmi2k, how is asciinema coming along? <jmi2k>Petter: I think it was something on my side. People say it works, but I can't test it right now, so I left it for a while. <Digit>a notion i may or may not get around to implimenting... using a guile configured window manager in my guixsd. are there others besides scwm and guile-wm ? <jmd>So I want to write a system test where I connect to a particular port on the system under test. How do I refer to that system? What is it's IP address? <Digit>or are they not worthy, n i should just settle for some more established other lisp configured wm <rekado_>Digit: I only know of guile-wm and from what I heard it's not very usable. <OrangeShark>Digit: I believe those are the only ones, but I have seen people mention they were interesting in fixing them or rewriting a new WM <jmd>I'm not sure, but I think i3 is guile configured. <Digit>ACTION might end up with clfswm yet <ng0>unless they made a total change in the last 5 years <civodul>funny thing is the "verified" box on the UI <roelj>civodul: You upload your public key to Github to have it "verify" your commits <civodul>i'm not sure if GitHub makes the connection between users and public keys <roelj>No, you have to add it to your profile. (It's not public information ;)) <roelj>In your GitHub profile, you can add your GPG key. If you don't do that, signing commits won't make the shiny "Verified" tag appear. <roelj>There's no way for others to verify your key.. <ng0>I don't get why we started to sign commits at gnunet.. the whole history before was unsigned. I get the verification bit... <civodul>roelj: it would be nice... if others could also verify commits against that list <roelj>civodul: As in, GitHub being a keyserver? <ng0>it seems like what you pull in nixpkgs is very rarely able to git log --verify-signature later on <ng0>at least I only see the complains about missing rsa and dsa keys, that's all <roelj>I'm getting 'guix: offload: command not found' when trying to 'guix build bootstrap-tarballs'. <roelj>I think htgoebel had the same problem today <ng0>do I read it correctly that there might be an hidden service access for hydra (and guix pull therefore) at some point? or is this just for administration? <efraim>is gcc-cross-boot0 supposed to have a "lib" output? <efraim>it does have a lib output on x86_64 <kyamashita>Hello all. I think I might have hit something weird in guix/build/graft.scm, namely in the call to "find-files" within "rename-matching-files". <kyamashita>Is anyone familiar with the grafting code available to help? <jmd>Why is it that there never seems to be a qemu substitute in hydra? <sneek>Welcome back lfam, you have 1 message. <lfam>On GNOME desktops a service called Tracker automatically indexes all new files. Tracker uses a variety of tools and libraries to extract metadata from files. For media files Tracker uses the GStreamer framework. Images are parsed with ImageMagick and PDF files with Poppler. <lfam>Does anyone want to try updating our bitcoin-core package? I tried the "naive" update but the tests fail with "FileNotFoundError: [Errno 2] No such file or directory: './test/data/blanktx.json". Of course that file does exist, so perhaps the tests are being run from a directory where that relative path is incorrect? <lfam>kyamashita: Yes, I thought so, since it modifies that relative path and also does something related to that blanktx.json file <lfam>I checked the Nix package and I don't see any special handling of this issue, however <lfam>I also notice they are still using the unmaintained Qt-4 <kyamashita>Indeed they are. Nix makes some choice that are questionable in Guix, though. <lfam>I found some discussion of the Qt issue on the bitcoin github issue tracker. Some people want to deprecate the option to use qt 4, but others are concerned about distro packaging issues <lfam>Anyways, I tried building 0.13.1 with qt-4, just to bring it closer to the Nix package, and that didn't help :) <lfam>Hopefully some bitcoin user finds it valuable to use the latest version of bitcoin in Guix <lfam>If I started using bitcoin, I would absolutely not use a client built with qt-4. Although I'd probably try not to use a graphical client at all <lfam>Although I'm not an expert on Qt's support policies. They seem to be under-specified IMO <efraim>pyqt5.5 and pyqt5.6 are both built with qt5.7 <civodul>i feel very lonely on this machine these days <Petter>Paste the login credentials here and see if that changes :P <efraim>the only thing that relies on python[2]-pyqt-5.5 is calibre, and it looks like it just wants qt>=5.4.1 <civodul>lfam: most of the ARM failures aren't real failures, we can restart them i think <civodul>the Ruby failures look very real though <lfam>I restarted x265 on armhf <efraim>i tracked my aarch64 issue down to "something" after stage1 of gcc-final, right now i'm trying to paper over it by passing --disable-nls to gcc-boot0 and gcc-final and see if it magically fixes itself <ovidnis>i'm trying to make a guix vm but qemu complains the image i got from ftp://alpha.gnu.org/gnu/guix isn't a bootable disk <lfam>ovidnis: Can you share the full command-line you are using? Please use paste.lisp.org if you want to paste lots of text, like error messages <lfam>And, are you sure you used the GuixSD image, and not the Guix tarball? <ovidnis>i did xz -d on it, is that not enough? <lfam>ovidnis: Yes, that's enough, assuming you downloaded a file like "guixsd-usb-install-0.11.0.x86_64-linux.xz" instead of "guix-binary-0.11.0.x86_64-linux.tar.xz" <ovidnis>pressed ESC to select boot device, chose the first drive <lfam>ovidnis: Also, if you just want to build a GuixSD virtual machine, we have tools for that: `guix system vm` (immutable) and `guix system vm-image` (mutable) <lfam>ovidnis: This works for me: qemu-system-x86_64 -net user -net nic,model=virtio -smp cores=2,threads=2,sockets=1 -enable-kvm -vga virtio -m 3072 -hda volume.qcow2 -hdb ./guixsd-usb-install-0.11.0.x86_64-linux -boot menu=on <lfam>Sorry to leave in some unecessary things. I'll pare that down <lfam>`qemu-system-x86_64 -net user -net nic,model=virtio -hda volume.qcow2 -hdb ./guixsd-usb-install-0.11.0.x86_64-linux -boot menu=on` <lfam>You might need to allocate more RAM than the default; I'm not sure. And in my example, the bootable GuixSD installer is the 2nd device in the list, not the 1st. <lfam>I do recommend using the `guix system` tools I mentioned. They'll allow you to create the virtual machine image declaratively. <ovidnis>i'll do that in the future. i'm on osx and wasn't sure of how easy installing guix on osx would be <lfam>Ah, I'm sure that someone has tried it, but I haven't heard the story :) <lfam>I think it probably wouldn't work for now <civodul>it's impossible: Guix builds packages against the GNU libc, which isn't ported to OSX <janneke>civodul, ovidnis: a darwin cross build is somewhere next on my `lets try that'-list <civodul>not sure if that's possible since we'd need to be able to package its libc <janneke>han-wen wrote the darwin cross build for gub, i'll have too look into the details