IRC channel logs


back to list of logs

<ng0>yay! my gpgscm is an awful hack, but gnupg-2.1.14 works
<ng0>i mean the test phase works now
<catonano>ng0: yay !
<ng0>and it works. I don't feel like improving the gpgscm package - it does its job and works for its intended purpose. If anything, someone could look at what I commented and increase its length by rewriting it
<efraim>bug0067 in gd is known to fail on i686 hardware
<civodul>Hello Guix!
<csanchez> guix/ui.scm:1197:6: Bad qstring header component: 113 localhost (squid/3.1.14) This cache hit is still fresh and more than 1 day old
<csanchez>whenever I try to install any package it seems
<csanchez>any ideas? :S
<csanchez>oh, never mind, --substitute-urls= (empty) makes it work so I guess it is due to hydra problems
<csanchez>surprisingly, --no-substitutes did not solve it
<civodul>csanchez: could you show the command that triggers the problem?
<csanchez>guix build bitlbee
<csanchez>but I tried some other packages as well
<csanchez>I can not reproduce exactly now as building with --substitute-urls made it
<civodul>it happens while updating substitutes from
<csanchez>I am not sure, I am not yet so familiar with guix internal
<csanchez>but I would guess so, given it passes if give no subtitute URLs
<csanchez>"guix build irssi", same error
<csanchez>probably it will also succeed if I pass an empty --substitute-urls parameter
<csanchez>but I can do some other tests if that might help
<civodul>it's a problem on our server setup
<civodul>looking into it
<Kooda>Hi :) I’m trying to update my packages with guix package -u but it fails downloading libungif source archive and just stops there.
<Kooda>Is there a ways to update everything that doesn’t depend on it?
<civodul>Kooda: could you try again? we have troubles with our server at
<efraim>the test for bug0067 in gd is known to fail on i686 hardware
<civodul>ah, we should disable it on i686
<Kooda>civodul: I’ll try as soon as texlive has finished grafting. ^^
<Kooda>Though it would be surprising if it were to work. It fails at fetching the source frome sourceforge.
<Sleep_Walker>I'm trying to improve my system configuration but I seem to have problem in it
<Sleep_Walker>guix system: error: service 'xorg-server' provided more than once
<Sleep_Walker>the reason is that I use both service module desktop and xorg
<Sleep_Walker>I need xorg module to configure slim-service
<Sleep_Walker>if I remove xorg service module from configuration, `slim-service' is no longer recognized
<Sleep_Walker> In procedure module-lookup: Unbound variable: slim-service
<Sleep_Walker>IOW, how can I set slim-service?
<Sleep_Walker>(I can remove desktop service module, but that is not desirable, right)
<rekado>Sleep_Walker: are you using the “modify-services” syntax?
<rekado>I use this to add some xorg configuration snippet for my trackball:
<Sleep_Walker>rekado: that looks like the way to go, thanks, I'll give a try
<efraim>think there'd be any pushback if I removed vangrind from efl?
<efraim>i'm going to add harfbuzz, it's already there in `guix size efl'
<efraim>alsa and avahi are also already in guix size
<Sleep_Walker>valgrind is there only for debugging
<efraim>i'm looking at and the inputs and the configure output, looks like I should clean it up a bit
<Sleep_Walker>shouldn't be lsh-service-type also exported from gnu/services/ssh.scm so I could use `modify-services' syntax?
<ng0>I just had a positive guix moment… my torsocks-2.2.0-rc1 package needs more adjustments in gentoo than in guix :)
<rekado>Sleep_Walker: you are probably right.
<rekado>there were some other service types that had not been exported by accident
<civodul>"historically" service types did not exist, and not all of them were exported when we retrofitted them
<civodul>janneke: BTW, did you have any chance with rottlog?
<ng0>i find it incredibly satisfying that guix is smarter than emerge with some packages i have :)
<davexunit>a surprisingly nice post from linus torvalds about small patches:
<ng0>I work on some rfc for guix-dev regarding submissions and more, and yesterday I read the libreboot git guidelines. I think before I start with the longer thing I want to comments on, I'll add something they use and link to to our docs:
<ng0>for those behind tor or some very restrictive firewall blocking
<ng0>i meant to paste
<Kooda>davexunit: nice mail. :o
<janneke>civodul: sorry not really, i didnt' get past figuring out mcron/mcron2 and lost interest after a couple of reboots
<janneke>i did figure out some variable/config file settings, lemme see
<bavier>does anyone know details about GNU make's "shell" function and how its environment is setup? specifically, it seems like it's always an empty environment.
<civodul>bavier: dunno; it might be that the code is the best documentation ;-)
<bavier>yay for source code! :)
<civodul>func_shell_base does "envp = environ", so apparently it uses the current environment as is
<mark_weaver>efraim: thanks for investigating the gd test failure on i686. I'll patch out the test on i686.
<ng0>regarding perl-net-psyc: we are investigating psycion bugs at the moment and then there can be a release which does not break perl .. because apparently right now a torified connection makes libperl segfault.
<ng0>so then a native psyc client can be provided.. better than delivering a broken client.
<davexunit>"no clear focus on security"
<Sleep_Walker>I feel insecure suddenly
<ng0>that looks like the nodejs propaganda ministerium.
<ng0>and the tweet is most likely advertisment to their own product:
<bavier>I'm sure
<mark_weaver>lfam: I
<mark_weaver>lfam: I'm unsure about your "gnu: gnutls: Fix test failure" commit.
<mark_weaver>I don't see how a test failure could be fixed using a graft, because the original ungrafted derivation will still need to be built.
<mark_weaver>am I missing something?
<lfam>Hm, fair point
<lfam>I guess I already had the ungrafted gnutls in my store, so I didn't have to rebuild it
<lfam>Okay, I will revert it while we figure out what to do
<lfam>mark_weaver: It's reverted. Unfortunately, it seems that we don't have a gnutls substitute available from for the head of the master branch.
<lfam>We do have the doc and debug outputs, but not the main output
<mark_weaver>I'll see about maybe copying it from one of the build slaves
<mark_weaver>it's in hydra's store, for x86_64 at least
<mark_weaver>lfam: can you try --substitute-urls= ?
<mark_weaver>afaict, hydra has the gnutls outputs for all 4 architectures in its store
<lfam>I must have used the wrong command to try and fetch it.
<lfam>If it's there, it's there :) As an aside, is there a way to force the re-download of a substitute?
<mark_weaver>guix challenge would have to do that, I suppose
<mark_weaver>although I confess I haven't run it yet
<mark_weaver>actually hydra doesn't have the gnutls outputs for mips64el. I made a mistake when checking.
***abbe_ is now known as abbe
<jonsger>how much money did Guix raise through the foundraising campaign?
<lfam>jonsger: The last I heard, a little over $8000 USD
<efraim>I replied to the mailing list, but the red hat/fedora maintainer suggested some CFLAGS for i686
<efraim>for gd
<mark_weaver>efraim: thanks for bringing it to my attention. I read the bug report you cited, and pushed a fix to master.
<jonsger>okay, thx
<MaliRemorker>I'm trying to change the xorg configuration. Now, under section Services in the GuixSD manual, there is a bit that references the "xorg-configuration-file" function. Running this in the REPL, I see it produces a gexp object. But, if I want to make this a part of my configuration, where do I need to invoke it. I mean, how to plug it in my system?
<mark_weaver>MaliRemorker: it's a bit awkward, but here's an example:
<mark_weaver>out of curiosity, what change do you want to make to the configuration?
<MaliRemorker>mark_weaver: just the resolution; i have guixsd running under a vm and the standard is 800x600; i figured, one needs to increase it on the host side
<mark_weaver>since that example above, we now have a nicer way to modify services from existing %desktop-services, using the 'modify-services' macro in gnu/services.scm
<MaliRemorker>well, i've never encountered a mlet kind of let until now, so i'm glad there is a nicer way :)
<mark_weaver>well, the hope is that it's quite rare nowadays to tweak the xorg configuration
<MaliRemorker>mark_weaver: yeah, but there are plenty of etc files one used to tweak: for example the wpa supplicant
<MaliRemorker>couldn't there be some ... simplified way to produce conf files in a "guixy" way, say, using a simplified package definition format?
<mark_weaver>for the common cases, we try to make it fairly easy, but of course there is room for improvement and patches are welcome :)
<MaliRemorker>oh, well, i think i'll need some time to get used to guixsd first
<MaliRemorker>before starting with the patch submision process
<mark_weaver>sure, makes sense
<MaliRemorker>btw, say you have this binary blob of software you want to shove into the gnu store; do you still wrap this into a package definition, or is there another way to do it?
<mark_weaver>well, our goal is to build everything from source, so that's not a goal for us. however, there are two exceptions: (1) we have bootstrap binaries which are used to build the initial compilers and utilities to build everything else. you can see those definitions in gnu/packages/commencement.scm.
<mark_weaver>(2) some compilers are self-hosted, e.g. ghc, and in that case we need to start by downloading a pre-compiled binary and hacking it to work on Guix with its non-standard filesystem layout.
<mark_weaver>in general, pre-compiled binaries for most distros won't work on GuixSD, because of the change in filesystem layout, which is necessary to achieve our unusual features.
<mark_weaver>although in most cases they can be hacked to work on intel systems at least, using tools like patchelf.
<Teru_Akko>ACTION loves GuixSD
<mark_weaver>out of curiosity, what binary blob of software do you want to import?
<MaliRemorker>thanks Mark
<MaliRemorker>of course, that's a good point about things sitting in all the wrong places
<MaliRemorker>well, one idea was to make android SDK part of the store
<MaliRemorker>though, this is not really necessary
<mark_weaver>is it possible to build it from source code?
<MaliRemorker>i have no idea :)
<MaliRemorker>and i have no clue what's the licence
<MaliRemorker>see this: 2.3 You may not use the SDK and may not accept the License Agreement if you are a person barred from receiving the SDK under the laws of the United States or other countries, including the country in which you are resident or from which you use the SDK.
<mark_weaver>last I checked, the Android SDK itself comes with draconian restrictions and legalese that you must agree to, although most of the underlying code is free. I seem to recall that the Replicant project (a free distribution of Android) provides a free version of the SDK
<MaliRemorker>that's in terms and conditions :)
<MaliRemorker>already doesn't seem very free :D
<mark_weaver>yeah, definitely not.
<MaliRemorker>i know about replicant, but my strategy is likely going to be: 1) defile for comfort; 2) clean up as much mess as possible
<MaliRemorker>though, i certainly won't try to extort support from fellow guixers to do this :)
<MaliRemorker>anyway, thanks Mark
<Teru_Akko>ACTION really does love GuixSd
<Gamayun>Me too, Teru_Akko ;)
<mark_weaver>build logs are now accessible on hydra's web interface, newly fixed
<efraim>yay build logs
<rekado>ACTION packaged mininim; is unsure whether it’s actually 100% free.
<bavier>rekado: looks like gpl3+ to me
<rekado>bavier: yes, but it seems to contain an original level file.
<rekado>and I don’t think that any part of the original game has been released under a free license.
<rekado>the level file is a binary and I only noticed this as it contains a #\\nul character (which made Guile barf).
<rekado>I find this unusual. Wrote an email to Bruno to ask for clarification.
<Akko_Teru>the name Bruno sounds familiar.. Bruno hab..?? Someone x_x
<bavier>rekado: I must be missing it, do you have a link?
<rekado>the tarball contains a directory data/legacy-levels
<rekado>the files therein are binaries
<rekado>I don’t know if these are originals or if they are generated from something else.
<rekado>if they are generated I fail to see the corresponding source.
<civodul>ISTR it's non-free
<civodul>we'd need to check with the author, who's very familiar with that
<civodul>(and sympathetic to our cause, i mean)
<bavier>ok, I see now
<rekado>civodul: I already sent an email this morning. I’ll wait for a reply before submitting a patch.
<jeffers-media>hi all, is it possible to use guix to install a git directory?
<jeffers-media>i would rather use guix -ad-hoc to create a clean environment for hacking, instead of installing to a dir, and then changing global variables
<rekado>jeffers-media: what do you mean by “install a git directory”?
<rekado>Guix can fetch package sources from git using the git-fetch method.
<davexunit>jeffers-media: I'm not exactly sure what you're trying to do, but keep in mind that whatever you put into the store is *immutable*
<davexunit>so if you wanted to develop with that git repo, you won't be able to.
<jeffers-media>davexunit: ah i see. Well I was thinking that I install a version of guile, make some changes, and then re-install it with guix
<jeffers-media>that way I can easily roll back to previous versions if something goes wrong, but more importantly it will be easy to create clean environments to install guile/emacs using this modified version of guile
<jeffers-media>davexunit: do you think there is a better way?
<davexunit>you could pretty easily make your own guile package that builds from a git checkout
<davexunit>I do that for other software
<jeffers-media>davexunit: okay i'll look into that. btw, if i make small modifications to guile, do i have to completely recompile, or is there a way to just re-compile those files?
<davexunit>jeffers-media: you have to recompile if you're building a guix package
<davexunit>because it would nondeterministic by definition if it used some previously built version
<davexunit>if you're hacking on guile directly, running 'make' will only recompile what has changed
<mark_weaver>civodul: what do you make of this? compare with
<mark_weaver>they agree on the output paths, but it looks like they correspond to different derivations
<mark_weaver>and they also disagree about whether the build succeeded. hydra recorded it as a successful build, although the log indicates failure.
<mark_weaver>but the mismatched .drv filename is the main thing I'm curious about. is this expected?
<mark_weaver>I guess the reason for the disagreement about success is that it succeeded long ago, was lost during the disk failure, and it failed to rebuild.
<Akko_Teru>mark_weaver has account on GNUSocial ^^;
<civodul>mark_weaver: the log reads "source file /share/guile/site/2.0/guix/config.scm", weird!
<civodul>there can be several .drv mapping to the same output file
<civodul>this can happen due to fixed-output derivations: several fixed-output derivations can obviously map to the same output
<civodul>and so this is recursive
<mark_weaver>ah, I see
<Akko_Teru>ACTION confused weaver for dave tomson x_x;
<jeffers-media> davexunit okay great thanks for the info. I'll probably use guix when I have some stableish version
<Akko_Teru>ACTION installed Guix .10.0 other day; "usermod" not found in bare-bones.scm template.
<mark_weaver>Akko_Teru: in GuixSD, we configure user accounts as part of the OS configuration. see section 7.2.5 (User Accounts) in the Guix manual.