<rain1>i don't think you need gexps for that <katco>rain1: how does the package know how to build? <rain1>like you said, start with trivial-build-system but then you add/modify a phase to run the bash script <katco>rain1: i thought trivial-build-system required a builder sexp which defined how to build it? <katco>rain1: np, thx for taking the time <rain1>chehck out gnu/packages/fonts <rain1>a lot of them use trivial-build-system <rain1>that shows how to do the builder sexp <efraim>bavier: while I'm quickly checking and running off, did you forget to register your patch with gnu-system.am? <rain1>wonder if anyone got around to reading my ML post and was that sort of thing nice/useful? <katco>rain1: those examples really helped, ty! the bash script begins with "#!/usr/bin/env bash" how can i give the build environment access to that? <mark_weaver>katco: you need to patch that shebang. gnu-build-system includes a phase that handles that automatically. <mark_weaver>it might be best to use gnu-build-system and remove/replace the phases that are needed <katco>mark_weaver: i'm using trivial-build-system because there's no ./configure or make, just the bash script. should i be using gnu-build-system? <efraim>you could delete the phases you don't need <efraim>I find it easier than than using the trivial build system <katco>efraim: so delete all the phases and then use the same builder sexp to run the script? <katco>sorry i'm completely new to guix <mark_weaver>katco: I wouldn't delete all the phases. I would just delete 'configure' and replace the 'build' and 'install' phases to work as required <mark_weaver>many of the other phases are still likely to be useful <katco>mark_weaver: oh, i didn't realize the phase wasn't tightly coupled to how the phase was executed <mark_weaver>I normally only use trivial-build-system when copying is all that's required <katco>mark_weaver: ah i see. there's no install phase, just build... i think. still squishy on the store concept <mark_weaver>use 'modify-phases'. there are many examples in gnu/packages/*.scm <mark_weaver>if the script builds and installs together, then I suppose you could just do both in the 'build' phase and remove the 'install' altogether <katco>mark_weaver: we'll see what i end up with here :) <katco>hm. it's telling me i don't have access to write out to a subdir of the source dir ***lyk_ is now known as lyk
<rekado>I changed (guix http-client) to be more tolerant when parsing date headers by replacing "parse-rfc-822-date" in (web http). <rekado>(use-modules (guix http-client)) <rekado>((@@ (web http) parse-date) "Wed, 30 Jul 2014 3:47:42 GMT") <rekado>but even after "make clean-go && make", restarting the daemon and using pre-inst-env the actual download with Guix still fails with the old error. <rekado>ERROR: Bad Date header: Wed, 30 Jul 2014 3:47:42 GMT <efraim>removing gtk2 and glib from pinentry drops the closure from 700.8 to 101.2 <janneke>ACTION lets libtool gits the better of him, again Ugh <jmd>efraim: I don't understand how a closure can have a fractional value <jmd>Oh I assumed it was the package count. <efraim>pinentry-qt has a closure of 1482.9 MB <wingo>lol that something security-related could depend on a gigabyte and a half of code <janneke>meanwhile... drwxr-xr-x 3 guixbuilder01 guixbuild 4096 26 apr 14:38 guix-build-cross-ncurses-6.0.drv-23/ <efraim>the most i've ever kept was foo...drv-3 <janneke>ACTION is too lazy to remove and has been bitten too often by not using --keep-failed <rain1>github has got marked unacceptable for hosting code <rain1>hopefully more people will switch to hosting on free github replacements <Igel>it's wierd that sourceforge === github <Igel>i mean.. last i checked github wasn't injecting malware release blobs.. <rain1>yeah I've sent them an email suggesting that sourceforge should be marked LOWER than F! <rain1>I doubt they will created a new category but hopefully they will include note of the virus <rain1>sadly for too many software is on sf, many many guix packages could not exist without sf <rain1>at least people know about the problem and are slowly moving off it <rain1>(and guix itself protects against malware insertion) <df_>wow, that's pretty bad <Igel>how does guix depend on sf projects/? <davexunit>please don't conflate downloading tarballs from sourceforge with using sourceforge. <Igel>i dont even know how guix determines integrity of a tarball/package so.. im no expert.. <rain1>Igel: grep sourceforge on the packages directory <rain1>all sources are hashes and those hashes are stored in the package definition <rain1>so sf cannot manipulate the files without guix detecting a change <rain1>that's what I meant by 'protects' <davexunit>ACTION thinks about how to use guix to make relocatable binary distributions of things <janneke>davexunit: GUB does that for LilyPond <davexunit>I'm trying to come up with a way to make a gross binary bundle so lazy people can easily play a game <janneke>LilyPond's mini source-based distribution for cross building binaries <janneke>it may do what you want...but i'm working on guix hoping to replace GUB <davexunit>I think I can scrape together something that uses guix <davexunit>if I am successful, it will likely only apply to my particular use-case right now. <davexunit>I basically need to distribute a few SDL shared objects + a few compiled guile libraries <davexunit>and use a wrapper script to set GUILE_LOAD_PATH, GUILE_LOAD_COMPILED_PATH, and LD_LIBRARY_PATH before booting the game <davexunit>of course, the shared objects produced by the existing SDL packages won't do, because they have /gnu/store references in them <davexunit>so the build system I make needs to compile them from source in its own way. <janneke>that seems easy enough...still puzzles me that sometimes we're all writing and rewriting almost the same thing <janneke>it feels that guix could be putting an end to that, distribution-wise <davexunit>well with guix we have a chance to converge on something <civodul>davexunit: do you allow yourself to ask the user to use chroot(1) or user namespaces? <wingo>or maybe you just use patchelf and dynamic search paths? :) <davexunit>civodul: my current idea is *not* to provide a complete closure, but only bundle what I cannot reasonably expect to be on a user's machine. <davexunit>and build all of those dependencies from source with custom scripts that don't do the guixy stuff. <davexunit>not exactly something that scales, but I don't have all that many dependencies. <davexunit>civodul: I think we need better statistics about how our users use Guix. what do you think about adding Google Analytics tracking? users could opt-out with an environment variable. <shymega>davexunit: imho opt-in for statistics would be better, personally i'd rather i didn't have to explictly opt-out of analytics tracking <shymega>it's april fools again? man, my calendar is going backwards <davexunit>Homebrew, a package manager for OS X, has just added Google Analytics tracking that users are automatically opted into. <davexunit>apparently everyone is supposed to be okay with it because it's anonymous tracking <rain1>firefox opts you into various tracking things that you have to disable every single time you reinstall it, it's really disrespectful <davexunit>the justification from HN users is "every website already uses Google Analytics, so why shouldn't Homebrew?" <df_>well apple are probably tracking everything they do anyway... <davexunit>but does that justify Homebrew opting users into their own tracking? <df_>it doesn't justify it no, but we're talking about people who have already opted in to a proprietary OS <rain1>I think every bit of freedom is valuable <civodul>i agree with df_, it's already an osx/github/open-source culture <civodul>that's stereotypical, but not far from reality i'm afraid <civodul>roelj: the filevercmp commit seems to have weird indentation around 'origin' <civodul>no big deal, but i thought i'd mention it for future commits ;-) <rekado>civodul: oh, I pushed the filevercmp patch :-/ Sorry! <rekado>rofiquzzaki: do you mean Guix? It is free software. We provide linux-libre and our packages are stripped of proprietary stuff if necessary. <ADFENO>rofiquzzaki: If you mean Guix and GuixSD: GuixSD is one of the fewer free system distributions, that means, it's one of the fewer that follows the GNU Free System Distribution Guidelines. See the following pages for a list of the free system distributions: <janneke>how do I collect all dependencies for a cross-built package? <janneke>I would like to use guix environment --ad-hoc <bavier>civodul: what's the intended difference between (@ (guix http-client) http-fetch) and (@ (guix build download) http-fetch)? <civodul>bavier: both are in part about providing fixes to Guile's HTTP client <bavier>I noticed that they behave differently for some uri's <civodul>first thing would be to remove workarounds for Guile < 2.0.7 <bavier>specifically, I was trying to rewrite some of the importers to use http-client's http-fetch, so that we can avoid the whole stdout/stderr-to-/dev/null business <bavier>but ran into some difficulties with pypi urls <janneke>davexunit: thanks...still stuck in a wierd compile problem while trying <bavier>civodul: I don't have the error in front of me, and I hadn't pinpointed the issue; but I think it was something with the http headers <janneke>ACTION discovers the wonders of make clean ;-) <lfam>I just had nscd flake out on me in the 0.10.0 installation image <davexunit>rain1: binaries are already signed from the substitute server <bavier>rain1: do you mean commit signing? <davexunit>when people talk about "package signing" in other distros, they mean binaries. <bavier>it seems it suffers from the bootstrapping issue <rain1>yeah I'm having trouble building it for openbsd <rain1>getting it to bootstrap off a different scheme (e.g. guile) would be great! <lumidragon>Hey guys is it possible to get the dhclient in GuixSD to send the hostname to the dhcp server? I found that debian has a config that has this already, so I'm wondering how I could replicate this on Guix. <bavier>the "nanopass" software is funny; the dissertations went from "a nanopass infrastructure for compiler education" to "a nanopass compiler for commercial compiler development" <rain1>yeah turned out the idea was really good :) <bavier>not much different from guile's current compiler tower it seems <rain1>did you try bootstrapping it? <rain1>there is a difference in time it takes <rekado>efraim: <efraim> [22:27:27] also, I broke python2-pysnptools in my fight against propagated inputs <rekado>what's your plan to get rid of propagated inputs? <zacts>how is any recent progress towards full disk encryption + LVM?