<zerwas>If anyone with experience in building RPM packages is in here: We could use the openSUSE build service to provide packages for several other distributions at the same time <Steap>I don't really know much about the openSUSE build service <zerwas>Well, if you provide a .spec file, OBS will be able to build packages for Fedora, CentOS, Red Hat and so on <Steap>zerwas: so, have you ever used OBS ? <Steap>they only do .rpm based distributions, right ? <zerwas>No, Debian and Ubuntu are also supported <Steap>Would be nice to also have them in the official repos of the distros <zerwas>but as long as this does not happen, we can build unofficial packages with OBS <Steap>Usually, building packages require some hand craft <Steap>how does OBS do that automagically ? <zerwas>well, you still need to provide a hand-crafted .spec file <zerwas>name, description, ./configure && make && make install and the commands to create the buildusers for Guix etc. <ggrant>Besides the Aur, (and NixOs -- but that's too old for me to count afaik), is Guix easily available in any other selected distro repoes and/or should there even be this push till 1.0 hits? <ggrant>Assuming 1.0 brings some more "big name" packages along with it. <zerwas>ggrant: arch has Guix git, but that's it <ggrant>zerwas: Yeah, in Aur there is both a build for Guix 0.5 and Git. <ggrant>Both fail the download.sh test,for me -- so I had to edit that phase out. That being said, after that, it seems to work like usual. <zerwas>I don't see why it would hurt to start early with packaging Guix. It might even attract more helping hands <Steap>ggrant: have you reported the failure ? <Steap>ggrant: is the bug that happens because a stupid ISP ? <zerwas>ggrant: the AUR PKGBUILD does not create buildusers <ggrant>Steap: Maybe? Are there more specifics on it? <ggrant>zerwas: Ah. Well, I sided with just a traditional install -- so that's not a problem, personally. :^P <Steap>ggrant: I think one test failed once because we tried to reach a invalid URL - just to be sure it failed as expected. But some guy's ISP was doing crap, and it did not fail :d <Steap>ggrant: maybe you should report your bug <ggrant>ggrant: I'm not sure what I'd say, besides saying that is failed on x. <ggrant>Doesn't seem that helpful, unless people were completly unaware this was an issue. :^P <Steap>well, pasting the log might be usefull <ggrant>Steap: I'm about to passout, but I will make a note of it. <ggrant>Yeah, I'm about to KO for the night. Peace people. ***Infiltra1or is now known as Infiltrator
*ggrant is in-process of packaging Unison. *ggrant is building glibc from source... this may take awhile. :^P <civodul>ggrant: i was about to say you'll need OCaml first <civodul>ggrant: re glibc, are you unable to use the substituter? <ggrant>civodul: I'm just becoming accustomed to building, with --no-substitutes, because it seems with anything of relatively large-size ... the server become unresponsive. :^/ <ggrant>This way, it's "guaranteed" to build, without having to restart because it faulted or what-not. <civodul>but the message that says it's "unresponsive" isn't necessarily bad <civodul>i mean, it's just that it might be slower than expected <ggrant>civodul: I also still had the build error, when it ran a check -- failing on download.sh ... so that could be problematic. <civodul>in general you should report "make check" failures <ggrant>civodul: It'll give me some message like "fault", after it tries for X amount of time. <civodul>but ISTR that your ISP did DNS hijacking, no? <ggrant>civodul: Wasn't me, but I heard about that... don't know if I'm too on that ISP (Charter, North America.) <civodul>so you should post tests/guix-download.log, so we can see what's wrong <ggrant>civodul: Yeah it's on my list; I'll probably post it tomorrow, then -- I'm trying to fix my sleep schedule right now, so I'm staying up all night/day today... so I'll do so when I'm more level-headed/rested. :^I <ggrant>Really, I shouldn't even be working on yet another package module, but for the most part ... it's fairly brain-dead simple. :^U <civodul>yeah, having a rest is more important <dueno>civodul, yeah, the latest libssh seems to have cool features - worth packaging it (and/or libssh2) ? ;-) <civodul>but i was wondering if one should be preferred over the other, what the differences are, etc. <civodul>the only real downside i see is CMake ;-) <ggrant>Unison seems to require etags... I'm not sure if that means Emacs, or something else. <ggrant>Yeah, it builds (most of the way) via adding Emacs, but that's a huge dependency... <jmd>I have just noticed this entry in my .guix_profile <jmd> ls -l /home/john/.guix-profile/bin/ | head -2 <jmd>lrwxrwxrwx 1 guix-builder1 guix-builder 64 Jan 1 1970 [ -> /nix/store/cj0cvmzglkri51v1p3laz88f7cafz24v-coreutils-8.21/bin/[ <jmd>What is that doing there? <jmd>Is there a way to specify additional files which must be shebang patched ? <civodul>jmd: what's wrong with .guix-profile here? <civodul>jmd: re patching, you can manually call patch-shebang or patch-makefile-SHELL in a phase <jmd>What are the args to patch-shebang ? <jmd>There are some examples which pass more than one argument <civodul>well yes, there's an optional and a keyword argument too, as you can see ;-) <jmd>If I want to patch more than one I have to use foreach or can I pass it a list? <civodul>(for-each patch-shebang '("foo.sh" "bar.sh")) <civodul>there are a few occurrences of that in gnu/packages/*.scm i think <atheia>When trying to install IceCat through Guix I get an error message when util-macros is being downloaded, prior to it being built: <atheia>download failed #<<uri> scheme: http userinfo: #f host: "hydra.gnu.org" port: #f path: "/nar/fmnq0pqdkr789v28flfybzfg4qqivika-util-macros-1.17.tar.bz2" query: #f fragment: #f> 410 "Gone" <atheia>guix package: error: build failed: some substitutes for the outputs of derivation `/nix/store/j6qa9nv7afq7qj6ziwc573r63zmavnfa-util-macros-1.17.tar.bz2.drv' failed; try `--fallback' <atheia>The 410 suggests the file's missing at the source if I'm not mistaken? ***frusen` is now known as frusen
<jmd>I have something wierd and annoying. <jmd>I've modified a package definition, but whenever I do ./pre-inst-env build ... an old derivation is built. <civodul>jmd: how can you tell it's an old one? <jmd>I build it with -K and when I examine the build directory it is completely out of date. <civodul>could it be that there are several /tmp/foobar.drv-* ? <civodul>and what's the mtime of those files? <jmd>I didn't look, but I cleaned /tmp before building, and looked at the one that got generated. <jmd>The only way I can get my new package to build, is to change its name. <mark_weaver>if there are multiple definitions of the same package in your tree, it might be picking up the wrong one. <civodul>ah yes, that may be the reason, then <civodul>if there's an ambiguity, 'guix build' tells you so, normally <civodul>then you can you 'guix build -e ...' to remove that ambiguity <jmd>When you say "tree" you mean the source tree ? <jmd>ie, the git working directory? <jmd>There's only one package with this name. <mark_weaver>if you use ./pre-inst-env, then that directory is the relevant one. <jmd>I'm using ./pre-inst-env <jmd>maybe I need to do clean-go <mark_weaver>unless your mtimes got really messed up. was your clock way off recently? <mark_weaver>any .go file that is older than your source file shouldn't be used. <mark_weaver>so unless somehow your clock was set wrong and you ended up with a .go file with mtime in the future, or your clock is now set wrong and your .scm file is in the past, things should work correctly. <jmd>I have completely removed the package definition. Yet when I do ./pre-inst-env guix build it starts building. <mark_weaver>does your GUILE_LOAD_PATH contain another directory that contains gnu/packages/*.scm with the package definition? <jmd>Ok. Solved the problem. There it was picking up a defintion from an old emacs backup file. <jmd>How can I stop that happening? <civodul>didn't you get the "ambiguous package name" warning? <jmd>I didn't see it, but perhaps it was too fast off the top of the screen. <civodul>only .scm files are looked at, not backup files <jmd>But they are both called *.scm <civodul>when that happens, (1) you normally get a warning, and (2) this can be worked around with -e <jmd>It was #ghostscript.scm <civodul>but not that if the two contained (define-module (gnu packages ghostscript)), then one was effectively ignored