<quiliro>i wish guixsd would have some kind of synchronizing my girl's ipod <quiliro>if you can or teach me how to do it, it would be great <quiliro>i would like to know how to hack guixsd <jlicht>quiliro: unless you are running rockbox, I reckon you won't find much support for any ipod-related issues ;-) <rain1>the only way I got it working was install itunes inside windows inside virtualbox and usb do passthrough <rain1>gtkpod may work depending on your model, mine was an unlucky one <bishopj>Is there an example of creating a guix build script for an application? <rain1>www.gnu.org/software/guix/packages <rain1>click any package here to see its definition <bishopj>rain1: No, as sort of a walkthrough for someone who wanted to get started <rain1>if you get stuck feel free to ask <rain1>quiliro: that's the nasty type! <rain1>i think you will have trouble with it, sorry <rain1>not sure, thaths just my experience <rain1>looked same on google images <quiliro>be back in a couple of days when i come to connect to telecommunications <jlicht>when I continue the (failed) build by issuing a make with the correct environment setup, things seem to work out <jlicht>so what would make bash not be able to see/run an executable relative to the current directory :O <lfam>I bet the error message is wrong <lfam>I wonder if the file exists but has some strange quality that causes `make` to reject it? <jlicht>it only happens when using the guix daemon to build it <mark_weaver>jlicht: it might be a parallel-build issue. maybe try adding #:parallel-build? #f to the arguments <lfam>How did you set up the environment where it succeeded? <jlicht>lfam: I just sourced the /tmp/nix-build-rust-1.8.0.drv-0/environment-variables :-) <jlicht>and did a guix environment rust (from my git /pre-inst guix) <jlicht>mark_weaver: I'll try this overnight; it takes about 30 minutes to build on my system, so I'd know more tomorrow <jlicht>having lots of fun. Even having read the manual, it doesn't actually 'click' for me until I actually have to apply some arcane tidbit of knowledge :D <mark_weaver>jlicht: is rustc a shell script that refers to /bin/sh ? <mark_weaver>jlicht: /bin/sh is available in the main GuixSD environment, but not within the build environment <jlicht>mark_weaver: rustc is (sadly) a bootstrap binary which I provide via an origin reference <mark_weaver>and if the interpreter in the shebang of a script does not exist, you'll get that error when trying to run it, iirc. <mark_weaver>jlicht: are you doing this on GuixSD, or Guix on top of another distro? <jlicht>guix on top of ubuntu 14.04 derivative <mark_weaver>binaries include an absolute file name of the dynamic linker to use. <mark_weaver>you can't simply run an executable built for another distro on Guix <jlicht>mark_weaver: would that be /lib64/ld-linux-x86-64.so.2? <mark_weaver>you'll probably need to use patchelf to hack it, but unfortunately patchelf only works on intel systems <mark_weaver>is there any way to bootstrap rust without using their binary? <jlicht>theoretically you could bootstrap from scratch (I guess/hope), but this would involve a successive chain of around 400~ish iterative compiler builds as far as I know <mark_weaver>if not, see our 'ghc' package, where is calls "patchelf" "--set-interpreter" <jlicht>mark_weaver: after me nagging them about their stuff being horrible in guix-land, they started a disscussion about at least having a default procedure for bootstrapping recent compilers. <jlicht>I had a (quick) look at their list of snapshots. <mark_weaver>it might be that a snapshot can be built with something older than the previous snapshot <jlicht>yes, but that would not be a fun couple of days/weeks for some unlucky person :P <lfam>There has to be someone on their team that knows how to do it <jlicht>as far as I know, the imho good ideas discussed are still not properly implemented, so it would seem that most people don't have this as a priority <rain1>that sounsd like it might take a while <rain1>I don't think this approach of compiling from genesis is practical <rain1>having a reproducible build fixed point seems like a better priority to me <jlicht>*319. Sorry for the misinformation <jlicht>anyway, thanks for the technical and emotional support, and have a nice weekend all. I'll be continuing this somewhere next week <rain1>what percentage of guix packages are reproducible builds? <joshuaBPMan>Hello, i'm trying to burn a dvd with the guix install image. <joshuaBPMan>But when I do a dd if= of=/dev/sr0 I get an error that /dev/sr0 is a read only filesystem. <joshuaBPMan>Does anyone know how I can burn this image to a disc? <koz_>joshuaBPMan: Does /dev/sr0 correspond to your actual DVD drive? <joshuaBPMan>I have a usb stick that I can probably use tomorrow to burn the image, but I'd prefer to burn the install image to a DVD. <rain1>bishopj: it's really nice, would you like to add it to my wiki? or i can add to save you time <bishopj>rain1: Could I get a link to your wiki? <OriansJ>I am in the process of writing a self bootstrapping hex assembler who's only dependency is itself, I was hoping to help the reproducible build process by reducing the number of binaries that have to be trusted to 1 in the case of C. A 1416 Byte Hex file that produces a hex assembler that is exactly half that size. <OriansJ>I have already written it in assembly but thus far have only made it for AMD64 <OriansJ>To have it compile, one needs only hex < Sourcefile.hex > binary <OriansJ>It supports line comments and is case insensitive, for testing and validation; I have created its partner program which converts any file to its hex equivelent. That too has been written in assembly <sneek>civodul, you have 1 message. <sneek>civodul, ng0 says: Okay, thanks. I see how and if I can or want to mirror this (a fix would be if there already was a .onion of the whole gnu.org/s/ space.. partyvan.eu has a mirror, but i haven't checked for /s/guix <jmd>So what's the next thing that Guix needs? <jmd>(define (make-user) (make-user)) <z0d>(define y (lambda (f) ((lambda (x) (x x)) (lambda (g) (f (lambda a (apply (g g) a))))))) <janneke>ACTION just built his first lilypond.exe on guix <jmd>Does lilypond depend on ghostscript? <z0d>everything depends on Ghostscript and/or LaTeX <-: <jmd>Hmm. How did we get ghostscript to cross compile? I sent a few patches to the maintainer some years ago but he refused to apply them. <janneke>we have been cross compiling ghostscript for lily since 2003 or so, though <jmd>Does it now cross compile in Guix? <janneke>i got quite a number of patches applied, no need to patch anymore <jmd>So they're not yet in the official GNU ghostscript source? <janneke>oh, i was referring to the whole wip-mingw32+lilypond branch <jmd><janneke> jmd: yeah, ghostscript is a bitch \\n .... <janneke> ghostscript isn't so bad <janneke>ghostscript used to be really problematic to cross compile <anthk_>where doex guixsd store the timezone? <OriansJ>Well I feel guix needs a lower level bootstrap, so I am working on that. [Hand assembled Hex eats time] But if someone feels like getting guix to support network proxies, I would appreciate it. ***imrekt is now known as imr
<jmd>OriansJ: What do you mean by "lower level bootstrap" ? <janneke>the guix build is /a lot/ simpler as you can see <jmd>The bootstrap binaries are (guile gcc binutils libc coreutils) <OriansJ>jmd: I am aiming to make the only assumption for the bootstrap is a 512 (or less) Byte Hex assembler and a 256 (or less) Byte exec_enable program <rain1>OriansJ: that sounds amazing!! <jmd>It sounds ambitious! <rain1>I had been thinking about some similar ideas but didn't get to programming <jmd>I would take it in steps ... <OriansJ>Well, I have written a version of the assembler in assembly and and nearly done converting it to hex by hand <rain1>I really hope you're doing writeups on this! I would love to read all about it <OriansJ>I am right now doing it for AMD64, then I'll do it for i386 <jmd>But to build gcc one needs more than an assembler. <jmd>I would have started at the other end. <rain1>I've been looking at the 8cc compiler, it looks really nice <jmd>Can one for example build gcc tinycc <jmd>I suspect not since, in their wisdom, the gcc devs now need a c++ compiler to build gcc. <OriansJ>And any hex file with # line comments <jmd>If it could build tinycc that would be a decent proof of concept. <rain1>this is such an exciting project to me OriansJ <jmd>Where one goes from there would be .. interesting. <rain1>OriansJ: you might like to ping mark_weaver, IIRC he was considering making a ML for this sort of bootstrapping work <OriansJ>My though is bootstrap only 1 architecture and use it as the basis of bootstrapping the other architectures <rain1>I think that's an excellent idea <jmd>I wonder if the bootstrap Guile actually needs to be a fully blown Guile or if a limited cut-down version would do? <rain1>reduces the amount of extremely hard work, but still retains a good trust chain <OriansJ>Aka, we need only bother doing a full hex bootstrap on 1 architecture and simply use C level porting for the rest <rain1>jmd: yeah I bet it could be cut down a bunch! in fact i think there is a C interpreter inside guiles code that can do the bootstrap <rain1>if we could build that using 8cc or something, that could be big step <OriansJ>I was thinking of going the small C route <jmd>For example, for bootstrap purposes, does one really need arbitrary precision arithmetic? <OriansJ>Hex -> Assembly -> Macro Assembly -> Subset of C -> C subset needed by GCC -> GCC <jmd>OriansJ: The trouble is, GCC needs a C superset. Not a subset. <OriansJ>jmd: arbitrary precision arithmetic isn't hard if you are willing for the implementation to be slow <jmd>That might be a possible route. Use gcc-2.x to build a modern gcc. <OriansJ>random-nick: but could gcc1 build gcc2? <OriansJ>random-nick: I've seen that and I was wondering if I could use that to save some work for myself <rain1>I just want to say this work is really really important and it's so exciting to see people working on it and discussing it ): <OriansJ>But honestly, I still don't feel like I finished the hex assembler to sufficient level yet <OriansJ>right now the compilation is ./trial < sourcefile > binaryfile && ./exec_enable binaryfile <random-nick>also there's something called QEMU Tiny Code Generator <OriansJ>and I haven't finished converting exec_enable to hex yet <random-nick>it's what QEMU uses to translate guest architecture's code to host's architecture <jmd>civodul: It seemed to work fine for me. <civodul>jmd: does "guix package --show=ao" worK? <jmd>(IMO it would be better if there was less vertical whitespace. But it works) <civodul>oh wait, the bug above is about HTML output, so you can't see it this way <civodul>but it would prevent generation of gnu.org/s/guix/packages <civodul>for now, could you change it to @enumerate instead? <jmd>Which is the buggy package? <OriansJ>I probably should include a C program for people to compile for them to bootstrap the hex assembly binary themselves <civodul>jmd: ao, just saw your commit on guix-commits <OriansJ>Since I don't want people to have to trust binaries I provide <jmd>civodul: I posted it to the list about a week ago, and didn't get any feedback. So I assumed that silence gives consent. <civodul>i just didn't notice until now, but that's fine :-) <jmd>ok I'll change it to enumerate. <civodul>probably not that complicated, but i never took the time to investigate <jmd>It'll be nice when there'll be a complete texinfo written in Guile!! <z0d>jmd: anyone working on that? <jmd>Not that I'm aware of. <random-nick>guix should have started when we had those lisp machines which had hardware support for lisp <rain1>random-nick: that reminds me of this paper... <jmd>random-nick: Also "car" and "cdr" wouldn't have seemed such bizarre names! <rain1>Long Tien Nguyen, Alan Kay - The Cuneiform Tablets of 2015 <z0d>thank, will check it out <jmd>civodul: gnu.org/s/guix/packages needs to be split. It takes too long to load. <random-nick>the package list browser arch and parabola use are nice <jmd>civodul: If you're interested, I have the start of an ncurses based installer. But I fear that until guile-ncurses is made a lot less unstable it'll be of limited use. <jmd>I think it is "quick bindings" which have caused a lot of problems. <jmd>bindings should be more than simple wrappers. <jmd>One needs to think how the library would be used in the target language. <jmd>guile-ncurses for example. <rain1>but that is a decade of work <OriansJ>For a basic user interface prototype, couldn't you use bash and zenity to get a quick prototype? <rain1>the extra complexity is what causes all the problems <jmd>NAhh. It might have been 3 weeks work in 2005 and then another 2 weeks in 2015. But it is not 10 years work. <rain1>I don't understand why you would say that <jmd>I don't think that the person who did it, ever tried using it for anything other than very small example programs. <rain1>why do you say "it is not 10 years work."? <jmd>In 4 days, I have found lots of issues, which render it essentially unusable, except for VERY trivial uses. If there had been continuous work over 10 years these would have inevitably been discovered and fixed. <rain1>but it's just so strange to me that I'm trying to be positive and helpful with this and you keep telling me that I am wrong <jmd>Odd. I got the feeling you were continually tell me that I'm wrong. <rain1>(also it is very rude of you to repeat back what I said like that) <jmd>No. I refuse to participate in an argument. <wingo>ACTION whistles for high horse <janneke>ACTION just merged zlib-mingw into zlib -- crosses fingers <rain1>what do I need to install to get past this? configure: error: C compiler cannot create executables <df_>look at config.log to see what the actual error was <mark_weaver>rain1: on Guix, you normally need to use the ld within 'ld-wrapper', which automatically adds rpaths to the linker command line so that the built executable can find its shared libraries in the non-standard places <mark_weaver>rain1: it's best to use 'gcc-toolchain', which includes gcc, binutils, glibc, and ld-wrapper <jlicht>mark_weaver: what is the advantage of using gcc-toolchain over all (or some) of these packages separately? <mark_weaver>well, for one thing it ensures that the 'ld' from 'ld-wrapper' will take precedence over the one in 'binutils' <jlicht>I might need some _big_ pointers on my initial work on rust then ;-). <jlicht>when do packagers decide to split package outputs? Is there a certain rule of thumb regarding size, or something else? ***imr is now known as imrekt
<mark_weaver>OriansJ: what's your plan for the kernel, drivers, and hardware initialization? or will your hex assembler assume that it's got a POSIX kernel available? <mark_weaver>i.e. what is the set of binaries that have to be present on the machine before your bootstrap begins? <cesar2>anyone has used an nvidia geforce 9800gt video card with free drivers and free firmware? <anthk_>can I install a 32 bit chroot (guix environment) under guixsd? <wingo>jlicht: i think it's size mostly. don't split unless you need to, basically <wingo>you can only significantly decrease size if splitting outputs allows the built products to trim their dependencies relative to each other <jlicht>wingo: so looking at the size of the closure makes the most sense if I understand correctly? <mark_weaver>anthk_: you should be able to pass --system=i686-linux to guix environment iirc <mark_weaver>cesar2: Guix includes nouveau. if that video card works well with nouveau, then it should work with GuixSD afaik <jlicht>how can I make the guix build daemon aware of the 'cc' linker? <jlicht>setenv and make-flags seem to not work <mark_weaver>jlicht: the guix build deamon is not aware of things like that. it's just given a builder program to run and arguments and environment variables to pass to it. <mark_weaver>i guess what you're really asking is how to convince your prospective package build system to use 'gcc' instead of 'cc' <mark_weaver>and the usual way is to add "CC=gcc" to #:make-flags <anthk_>mark_weaver, guix environment --system=i686-linux --pure bash gcc-toolchain -- bash <mark_weaver>anthk_: probably not, that would create an environment with the build requirements for gcc-toolchain and bash <mark_weaver>anthk_: why not make a guix package? that often easier? <mark_weaver>because gnu-build-system takes care of fixing up common build system problems <anthk_>mark_weaver, because I am on a 64 bit system <mark_weaver>that's not a problem. just say "guix build --system-i686-linux txtmap" <mark_weaver>and then it will build it in an environment containing only 32-bit toolchain/programs/libraries <anthk_>mark_weaver, ok. Basically is downloading from that git repo, cd'ing to the src folder, and do a make <anthk_>but it doesn't have an "standard" autotools setup <anthk_>the binary is built without any extras, man pages or such <mark_weaver>okay, it still usually makes sense to use gnu-build-system and to modify the phases as needed <mark_weaver>anthk_: pastebin blocks tor users, so I can't see that <rain1>I think arguments needs fixed up too <rain1> (arguments `(#:configure-flags ("--enable-silent-rules"))) <anthk_>btw, the download method is from git so <kyamashita>Does Guix have anything equivalent to Debian's ia32-libs package? <lfam>Do we have a canonical path to install upstream init scripts? <lfam>I was unclear. They are "init" scripts for a variety of initialization systems <lfam>There's sysvinit, gentoo, systemd, and one that I don't recognize <lfam>This is for the thinkfan package that is pending review on the list <lfam>Should I suggest they install each script into that init system's preferred path? <kyamashita>lfam: I suppose you could do that for each init system's most common distributions. <kyamashita>lfam: Similar to the Guix binary installation instructions for SystemD and Upstart.. <lfam>kyamashita: Could you reply to the thread on guix-devel with that suggestion? <lfam>kyamashita: I think you forgot to reply to the list regarding parole <kyamashita>lfam: I sent a second email that also went to the mailing list. <mark_weaver>anthk_: sorry for the delay. MIT uses many licenses, so the "mit" license is ambiguous. I guess it should be either the x11 or expat licenses <kyamashita>lfam: I'm going to be AFK for a while, but I'll send that email when I get back. <mark_weaver>anthk_: anyway, what problem are you seeing with the package as is? <mark_weaver>well, I see it's no where near ready. it still has the hello source URL, module name, the package name is mispelled, etc. <anthk_>mark_weaver, steps to define, form github <anthk_>mark_weaver, ofc it wasn't ready, I used gnu hello as a base