IRC channel logs


back to list of logs

<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>zerwas: how is that ?
<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: oh
<Steap>zerwas: so, have you ever used OBS ?
<zerwas>Steap: nope
<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>that'd be nice, indeed
<Steap>how does this work ?
<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
<Steap>that contains what ?
<zerwas>name, description, ./configure && make && make install and the commands to create the buildusers for Guix etc.
<Steap>I see
<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.
<zerwas>Oh, didn't see the 0.5 one
<ggrant>Both fail the 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>... Steap*
<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.
*ggrant is AFK.
***Infiltra1or is now known as Infiltrator
<civodul>Hello Guix!
<ggrant> civodul: o/
*ggrant is in-process of packaging Unison.
<ArneBab>hi civodul ☺
*ggrant is building glibc from source... this may take awhile. :^P
<civodul>ggrant: i was about to say you'll need OCaml first
<civodul>but we already have it!
<civodul>ggrant: re glibc, are you unable to use the substituter?
<civodul>(or unwilling)
<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. :^/
<civodul>are you using Guile 2.0.5?
<ggrant>This way, it's "guaranteed" to build, without having to restart because it faulted or what-not.
<ggrant>civodul: 2.0.9, on Parabola.
<civodul>ok, so it should work
<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
<civodul>but it eventually succeeds
<civodul>at least for me it does
<ggrant>civodul: I also still had the build error, when it ran a check -- failing on ... 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>hey dueno
<civodul>dueno: we have both
<civodul>but i was wondering if one should be preferred over the other, what the differences are, etc.
<dueno>a bit older but here is some comparison
<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>total 548
<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>looks good no?
<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 ?
<civodul>a file name
<civodul>see guix/build/utils.scm
<civodul>(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 ;-)
<civodul>but usually you don't need them
<jmd>If I want to patch more than one I have to use foreach or can I pass it a list?
<civodul>use for-each, yes
<civodul>(for-each patch-shebang '("" ""))
<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: "" 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?
<atheia>Ah bother, Civodul's gone… :-)
***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-* ?
<jmd>No I cleaned /tmp
<civodul>and what's the mtime of those files?
<jmd>which ones?
<civodul>those in /tmp/*.drv
<civodul>well, the generated ones
<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>that really shouldn't be needed
<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
<mark_weaver>jmd: what was the exact name of the backup file?
<jmd>But they are both called *.scm
<civodul>so that's the reason
<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