IRC channel logs


back to list of logs

<ewemoa>rekado_: for x86_64 here, building r fails during atlas
<grantix>Should I be able to ssh right into a new install of GSD? I suspect not.
<mark_weaver>not unless you added 'lsh-service' to your OS config
<grantix>Do we currently not have an openssh-service then I suspect?
<grantix>But will add for now.
<grantix>I don't think Parabola even has a lsh package ...
<grantix>In Aur.
<grantix>It is*
<grantixx>Does Slim not have an option to load directly from an xsession file?
<grantixx>I thought I remembered something like this mentioned in here awhile back.
<mark_weaver>the .xsession file is what gets loaded after you log in from slim. not sure what you mean.
<grantixx>I might be thinking of .xinitrc then.
<mark_weaver>I suggest using 'slim-service'. I don't know off hand how to launch it in a different way.
<grantixx>Well, it didn't load it.
<grantixx>Via slim-service, ratpoison.
<grantixx>I probably just need to dig into xorg's service like you suggested the other day.
<mark_weaver>didn't load what?
<mark_weaver>grantixx: what didn't it load?
<mark_weaver>grantixx: what problem are you having with slim-service?
<grantixx>My .xsession file.
<mark_weaver>grantixx: does your .xsession have "#!/bin/sh" as the first line? is it executable? (chmod +x .xsession)
<grantixx>Ah, I did the latter not the former.
<grantixx>Well, I had enough for tonight. It is now crashing, but it is obviously loading.
<grantixx>I'll look into it tommorow. Thanks for the starting push though, mark.
<rekado->grantixx, ewemoa : thanks for confirming that the R build fails. Do you also see a segfault?
<rekado->If the R build fails during building ATLAS, then it's probably unrelated to R itself.
<rekado->I got past the ATLAS build.
<taylanub>grantixx: by the way, were your issues with that one package on a 32b machine resolved? (I forgot which one it was that was failing to build on your side.)
<rekado_>I'm packaging another bioinformatics application called rseqc. It happens to be implemented in Python and uses the python-build-system. I may still place it in the bioinformatics module rather than the python module, right?
<rekado_>Is there a way to display a dependency graph for a particular package?
<rekado_>I wonder why a package depending on python-matplotlib when converted with "package-with-python2" pulls in "python2-pycairo" as input, although it should be "python2-py2cairo".
<taylanub>our curl doesn't support --capath? getting "curl: (4) A requested feature, protocol or option was not found built-in in this libcurl due to a build-time decision." from Freenet's ./ and that option seems to cause it
<rekado_>it would be helpful if guix were to show the download percentage when downloading binary substitutes.
<rekado_>I'm sitting in front of a terminal that's stuck at "1171725.7 KiB transferred" (for icedtea6) and I have no idea if I should abort it or wait.
<taylanub> 2 days, 4 hours remaining for organization applications
<rekado_>trying to package Julia, but it depends on quite a few unreleased libraries.
<rekado_>femtolisp had no release; dSFMT has no actual build target for a shared library; AMOS is just a bunch of Fortran files...
<rekado_>Julia bundles all dependencies in their release tarball, of course.
<rekado_>I wonder how far I need to go to package the dependencies.
<rekado_>on Fedora dSFMT has a couple of patches applied to make it buildable as a shared library.
<taylanub>rekado_: if the dependencies are in Julia's tarball, with external versions being optional, I'd just use them. or did you mean something else?
<bavier`>rekado_: add a comment in the Julia package recipe the dependencies can be factored out at a later date. We've done that with other packages.
<mark_weaver>taylanub: curl currently only supports capath when linked with openssl. curl's gnutls backend needs to grow support for capath.
<mark_weaver>taylanub: see
<rekado_>bavier`: ok.
<rekado_>luckily, the build is rather flexible and allows passing USE_SYSTEM_<name>=1 to use system libs.
<bavier`>rekado_: that's nice, yes.
<bavier`>I looked at packaging Sage at one point, but I didn't get the impression that its dependency could be so easily factored.
<mark_weaver>rekado_: package-with-python2 changes the names of the packages by replacing the 'python-' prefix with 'python2-'.
<mark_weaver>rekado_: also, see:
<mark_weaver>rekado_: packages that bundle dependencies will cause a lot of problems for us, particularly in the area of security updates, but also where things need to be patched either for guix or for non-intel platforms.
<mark_weaver>rekado_: so it would be good to split as many of those out as you have the energy for.
<rekado_>mark_weaver: python2-matplotlib specifically removes the propagated input "python-pycairo" and adds "python2-py2cairo". This is why it is surprising to me that a package depending on python2-matplotlib would pull in python2-pycairo (rather than python2-py2cairo).
<rekado_>mark_weaver: re bundled deps: agreed.
<rekado_>I'm still working with the bedops guys to fix their build procedure to not depend on patched tarballs of zlib / bzip2 and so on.
<mark_weaver>rekado_: if 'python-foo' uses 'python-matplotlib' as an input, then because of the way package-with-python2 works, it will create new packages 'python2-foo', 'python2-matplotlib', and 'python2-pycairo', etc.
<mark_weaver>it doesn't matter what the 'python2-matplotlib' package did. the package you are seeing is probably one that was created fresh based on 'python-matplotlib', without looking at the existing 'python2-matplotlib' package at all.
<mark_weaver>rekado_: read and the followups, and look at the 'package-with-python2' code for enlightenment.
*rekado_ reads it again but feels especially dumb
<mark_weaver>rekado_: basically, 'package-with-python2' is quite limited, and perhaps the solution will require enhancing it, and also maybe renaming 'python2-py2cairo' to 'python2-pycairo', dunno.
<mark_weaver>rekado_: the short version is that 'package-with-python2' just traverses the tree of inputs, converting every package that uses 'python-build-system' by changing its python to python-2, and renaming the prefix to 'python2-'.
<rekado_>I understand that. But does this mean that what python2-matplotlib does to propagate "python2-py2cairo" rather than "python2-pycairo" is ineffective?
<mark_weaver>that's one way to say it. a better way is that the 'python2-matplotlib' package that you see in guix' source code isn't even used at all. instead, another package with the same name is automatically created by 'package-with-python2'.
<rekado_>oh, okay, *now* I got it.
<mark_weaver>blah, the xorg-server update, which includes a security fix, somehow broke the gtk+3 test suite :-(
<mark_weaver>but only on x86_64, which my guix machines aren't.
*mark_weaver saves a copy of the failed log and asks hydra to try again
<paroneayea>surprised to see slib isn't actually in guix
*paroneayea wonders how much slib is as much used as it is studied
<paroneayea>(it's still broken in debian with guile 2.X :()
<taylanub>not sure if SLIB has many users
<paroneayea>I wanted to use the tsort algorithm at one point
<paroneayea>I guess if I was smart I'd write my own since it's allegedly not hard but I'm not smart :)
<paroneayea>well! I just tested porting it to standard guile
<paroneayea>and that was easy
<rekado->I'd be happy if someone could take a look at these short patches:
<bavier`>rekado-: It appears the 'arguments' field is the same in both packages. Was that intentional?
<bavier`>and could you fetch the tarball from github instead?
<rekado->bavier`: I'm no longer using github for my code, so the clone on github is empty.
<rekado->Ideally, the download from gitorious should be fixed.
<bavier`>the release tarball is still on github though
<bavier`>but yes, the gitorious downloads should be fixed
<rekado->erm, I don't see any release tarballs on github.
<bavier`> ?
<rekado->bavier`: you are right about the arguments field, though.
<rekado->oh, that's super old and I probably should remove it.
<rekado->(the version numbers have even diverged ... yuck. Completely forgot about this repo.)
<bavier`>that's what's linked on the home-page listed
<rekado->heh, forgot to push the update to the home page...
<bavier`>that was my other question: did you want to name the package lv2-mdametapiano instead?
<rekado->thanks for making me aware of this.
<rekado->the repo is called lv2-mdametapiano because it contains the shared sources for the mdaPiano and the mdaEPiano.
<bavier`>I see, ok.
<rekado->the original VST sources were very similar, so I eventually merged them in my port so that both plugins benefit from improvements.
<mark_weaver>iyzsong: would you like to add zlib to libxml2's propagated-inputs in core-updates?
<mark_weaver>or should I/
<davexunit>what implication do propagated inputs have with user profiles? there could be two packages that propagate different versions of the same input.
<taylanub>do we have a way of declaring a constraint such as "this package only works on i686 machines supporting SSE2 instructions"?
<Xiaoman>I'm trying to get GuixSD installed following the guide, but once I run "guix system init /mnt/etc/config.scm /mnt" it gives me the 2 line error:
<Xiaoman>"guix system: error: failed to load operating system file '/mnt/etc/config.scm':
<Xiaoman>ERROR: In procedure scm_i_lreadparen: /mnt/etc/config.scm:31:1: end of file
<Xiaoman>the file is a modified version of the template to keep it simple
<Xiaoman>is there anything I have missed?
<bavier`>Xiaoman: you must have misbalanced parentheses in your config
<Xiaoman>I thought so as well, but I have tripplet checked it
<Xiaoman>I found it
<Xiaoman>it was in the beginning ;_;
<bavier`>quadruple-checked now ;)
<Xiaoman>yes :3
<Xiaoman>I should really learn emacs bindings one of these days so I can work with those instead of Vim
<Xiaoman>I feel crippled when I do not have access to Vim
<rekado->Xiaoman: there's evil-mode for Emacs which gives you something very close to vim.
<Xiaoman>yeah, but still need to be able the emacs beast before I can navigate around in the browsers etc
<rekado->(I used it for a couple of years until I decided to relearn Emacs on Dvorak.)
<Xiaoman>able to handle*
<Xiaoman>man I must be tired
<rekado->On Guix System Distribution how do I load a number of kernel modules by default.
<rekado->I would like to load snd_seq on boot; this gives me a MIDI device under /dev/snd/seq in addition to /dev/snd/midiC1D0
<rekado->It's too bad that this soundfont doesn't have a reliable license:
<rekado->it sounds rather decent for a GM soundfont.
<jxself>That page makes reference to LICENSE.txt. What does that say?
<rekado->I don't know how to interpret the license. It has two sections: "License of the complete work" and "License of contained samples".
<rekado->the first is fine.
<rekado->the second is ... odd.
<rekado->"Many of the samples are original, but some were taken from other banks freely (and legally) available on the Internet from various SoundFont websites. Because GeneralUser GS originated as a personal project with no intention for publication, I cannot be 100% sure where all of the samples originated, although I do know that none of them came from commercially published SoundFont packages or sample CDs."
<rekado->I don't know if this matters.
<rekado->The first section about the "complete work" (i.e. the soundfont) is this:
<jxself>So they can't be sure that they're all distributable.
<rekado->"You may use GeneralUser GS without restriction for your own music creation, private or commercial. This SoundFont bank is provided to the community free of charge. Please feel free to use it in your software projects, and to modify the SoundFont bank or its packaging to suit your needs."
<rekado->I don't think they can make this statement when the origin of the samples used is partially unknown.
<jxself>Yeah, "I don't know where this stuff came from but have fun with it."
<mark_weaver>we can't use it unless it has a clear license
<mark_weaver>I'm sorry, but I don't think we can use it.
<mark_weaver>for non-functional data, we can include "as long as its license gives you permission to copy and redistribute, both for commercial and non-commercial purposes."
<mark_weaver>(quoting the "Non-functional Data" section of )
<mark_weaver>rekado-: ^^
<jxself>But we don't even know if that's there, since the person doesn't know where they even came from much less what terms they had...
<rekado->I agree. Already looking for other soundfonts with clear license.
<rekado->There is TimGM6mb, which is allegedly released under GPLv2, but I cannot find a license declaration on the homepage, only on
<rekado->I'll just package up fluid (MIT license) as any other GNU/Linux distribution has.
<a_e>rekado-: What do you think of freepats?
<rekado->a_e: confusing.
<a_e>What is confusing?
<rekado->I downloaded the zip file, but there was nothing in there but patterns.
<rekado->no soundfont.
<rekado->I have never used it before, but I have used fluid.
<a_e>Oh, they have lots of separate patches. And a configure file is included.
<a_e>It works with timidity.
<rekado->well, I need a GM soundfont.
<rekado->for all 128 GM instruments.
<rekado->I cannot seem to find a file whose name suggests GM compatibility.
<a_e>They have a little bit less than 128, if I understood correctly.
<a_e>The configuration file specifies a few replacement patches.
<rekado->which configuration file are you referring to?
<a_e>If you untar the tar.gz, there are two - freepats.cfg and crude.cfg.
<a_e>freepats.cfg is created automatically.
<a_e>crude.cfg is hand edited.
<a_e>For instance, there is no patch for 003 HonkeyTonk.
<a_e>So they reuse 001_Acoustic_Brite_Piano.pat in its place.
<a_e>And they use 122 seashore for 127 gunshot :-)
<a_e>In timidity.cfg, you can ad a line
<rekado->oh, I see. These configuration files are to be used with timidity only; they don't provide a full soundfont file.
<a_e>source freepsts.cfg
<a_e>to make it work.
<rekado->got it.
<a_e>But if you have a good alternative, I am fine with it of course.
<rekado->well, fluid is 140+MB and has no dedicated homepage, so I think freepats is the better choice.
<rekado->It's just a pity that they don't offer an sf2 file for use with other soundfont players.
<a_e>The lack of homepage is indeed annoying. The size not so much.
<a_e>Is it difficult to assemble an sf2 from a set of patches?
<a_e>Time to go now. Good night!
<bavier`>rekado-: I had an arpack package recipe sitting around on my work computer, sorry for not sharing it sooner
<bavier`>I hadn't heard of the "-ng" version though, so thanks for that.
<Xiaoman>hmm... udev seems to be missing its folder from /etc - so how do I write udev rules?
<Xiaoman>specifically I want to get rid of unpredictable predictable interface names
<Xiaoman>oh, I seem to have found it under /run/udev
<Xiaoman>hmm... didn't work :(