***Apteryx_ is now known as Apteryx
<OriansJ``>well janneke, how does this sound as an idea. How about we punt the problem like so: we fork Hex2 to make a specialized program that reads hex2 and only outputs binary symbol tables that are elf compatible and turn the elf generation into a binary stitching. <janneke>OriansJ``: so, a separate program that (looks a bit/lot like the hex2 linker and) produces the elf footer: sym and str tables and we leave hex2 linker as is? <rekado_>since yesterday I get no substitutes for modular qt <rekado_>it’s a bit heavy to build on my laptop <efraim>I've rebuilt gtk3 a couple of times the past couple of days, that might be related <efraim>And that commit to really update packages with propagated inputs <reepca>OriansJ``: Question - how do addresses past 65,536 get handled? For example, JUMP seems to just take a 2-byte offset. ***fps_ is now known as fps
<rekado_>sneek: later tell civodul Thanks for your work on #27426! I started reviewing it but then got lost in the sea of C. <jonsger>rekado_: does guix pack has cross-compilation support? <rekado_>“guix pack” takes “--target” and “--system”, so it has as much support for cross-compilation as “guix build”. <mekeor>if i specify a the 'source'-field of a 'package' with 'local-file', there's no way to specify 'patches', is there? <jonsger>rekado_: so guix pack -S /opt/gnu/bin=bin --target=armel-linux-gnu --system=armhf-linux diffutils should work? <OriansJ``>reepca: all jumps (except JSR_COROUTINE) are relative and will only work to reach code that is within the 32KB jump range. Should you require a longer jump (say as large as the possible address space) JSR_COROUTINE exists for that purpose, simply load your target into the desired register and JSR_COROUTINE will always work. <rekado_>mekeor: the “patches” field belongs to the “origin”. I think you may be able to use a “file://” URL instead of local-file. Would that work for you? <cbaines>I'm installing GuixSD at the moment, and it's been building a lot of packages. I used the latest installation image, and did guix pull, but it's build linux, a load of Gnome related packages, and move as it's been running for several hours... is this to be expected? <mekeor>rekado_: yeah, i should try that out <rekado_>cbaines: I had problems like that too. <rekado_>cbaines: looks like a commit to master caused a rebuild of gtk and qt <mekeor>cbaines: if you or rekado_ can determine which commit caused a rebuild of gtk and qt, you could use `guix pull --url=https://…COMMIT…` before you do `guix system init …` <mekeor>(where COMMIT would be the hash of the commit before the commit which caused the rebuild) <OriansJ``>sneek: later tell janneke that I probably will not take a crack at it until I finish figuring out the solution to reepca's disk operations request for FORTH (which means I also need to add the primitives to the VM spec) <cbaines>mekeor, good idea, I'll try and see how many packages I've got remaining to build, and then consider that option <cbaines>In general, I was pondering what it would be like to have some branch that followed master, but only advanced once there was a commit to advance to where some threshold was met about substitutes being available... <OriansJ``>sneek: later tell janneke that with all of the modifications, I'll probably be changing the name of the M0 to M1 to reflect all of the enhancements over the M0 which is supposed to be the minimal Macro-assembler which can self-bootstrap <mekeor>cbaines: yeah, currently you could just do that manually by looking up the state of hydra.gnu.org or so, i think <rekado_>cbaines: there are discussions about implementing --only-substitutes <cbaines>mekeor, yep, that is what I'm going to try and do now <sneek>Welcome back civodul, you have 1 message. <sneek>civodul, rekado_ says: Thanks for your work on #27426! I started reviewing it but then got lost in the sea of C. <mekeor>so the new aarch64 platform should support raspberry pi v3, right? <mekeor>has this guix ever been installed on an physical aarch64 device? <civodul>mekeor: isn't raspberry a 32-bit thing (ARMv7)? <civodul>mekeor: efraim runs Guix on an aarch64 device, but efraim might be the only one doing that right now :-) <rekado_>civodul: oh, yes, C++. I don’t feel qualified to review this. <mekeor>civodul: "ARM Cortex-A53 is a microarchitecture implementing the ARMv8-A 64-bit instruction set" <civodul>i'm skeptical, because everything in Nix is a hash table (aka. "attribute set") <civodul>so it's weaker than the records we have, for instance <civodul>and i'm not sure typing can really help, unless they first move away from attribute sets <mekeor>rekado_, civodul: doesn't guix also have the same issue (the lack of types) because guile/scheme is untyped? <janneke>mekeor: guile (scheme) has strong typing <sneek>Welcome back janneke, you have 2 messages. <sneek>janneke, OriansJ`` says: that I probably will not take a crack at it until I finish figuring out the solution to reepca's disk operations request for FORTH (which means I also need to add the primitives to the VM spec) <sneek>janneke, OriansJ`` says: that with all of the modifications, I'll probably be changing the name of the M0 to M1 to reflect all of the enhancements over the M0 which is supposed to be the minimal Macro-assembler which can self-bootstrap <mekeor>janneke: won't (string-append 1 2) compile in guile/scheme? <janneke>mekeor: yes, it compiles; because guile uses dynamic typing <reepca>"Typed" doesn't require compile-time guarantees. Some find it useful to have, but there are very few "untyped" languages out there - assembly, forth, etc <mekeor>okay. what i mean is strong+static typing <rekado_>For some parts of Guix I’d like to have type annotations. <reepca>That's one of the parts I really liked about common lisp <rekado_>I would find this useful for monadic functions <janneke>i should have a look at the typed racket thing <janneke>goops can be quite useful, but i don't much like the magic of and restrictions on methods <rekado_>it doesn’t have to be types — if we could express types with invariants or validators that would be just as useful <koosha>rekado_: It's really crazy . I reinstalled GuixSD and in this time I gave the configuration file my device instead of label and also I wrote zero to the sector 33 so I didn't got that warning after installation and no error . But now I get that kernel panic again : | <mekeor>is there any other reason to choose scheme to implement guix other than guile is a *GNU* high-level prog-lang? <rekado_>koosha: exactly the same kind of panic? <mekeor>reepca: haskell also has eDSL, no? <civodul>the thing is, by definition, Nix & Guix compose pieces of code dynamically: code that defines packages, OS configurations, etc. <civodul>so at some point, i think type errors are effectively "run time" errors from the user's viewpoint <civodul>even if we were to use Haskell/OCaml <rekado_>mekeor: Scheme is a very elegant language that also makes it easy to write own syntax. (Haskell lacks the latter part.) <civodul>mekeor: Scheme lends itself well to some of the things we want, in particular syntax extensions and code staging <rekado_>other language properties aren’t really that important; e.g. laziness or currying by default (as in Haskell). <rekado_>in Guix we define a big lazy graph without having to have laziness be a language feature. <civodul>i personally also like that Scheme is so simple and (i think) easy to learn <rekado_>it’s definitely easier to get into than Haskell <mekeor>civodul: what do u mean by "compose pieces of code dynamically"? <rekado_>another thing that Scheme does better than Haskell: records. <koosha>rekado_: I don't really know what should I do . I just did some regular instructions . <mekeor>haskell's records are fine, IMHO <reepca>well, they both send me searching wikipedia for an explanation of what monads are pretty often, which never ends satisfactorily <rekado_>koosha: I understand that this must be very frustrating :( <rekado_>koosha: have you checked that the image you downloaded is not corrupt? <rekado_>koosha: did you check the signature? <rekado_>reepca: monads are computations with context. <mekeor>koosha: are you using the correct image for your platform? which platform? <civodul>mekeor: when you run "guix system build foo.scm" or "guix package -m foo.scm", the file "foo.scm" contains code that is composed with the bigger "guix system" or "guix package" command <civodul>mekeor: same with GUIX_PACKAGE_PATH and so on <civodul>this is code that's discovered and composed at run time <mekeor>koosha: the best thing you can do is try to debug it, and send all information you get to thread of your bug on the bug-mailinglist <mekeor>civodul: ah, right. how does guix do that? how does guile do that? how is that called? can haskell do that, too? <koosha>mekeor: I used the X86_64 for a 64bit cpu . <civodul>mekeor: pretty much any language can do that of course, but my point is that this is dynamic in nature <civodul>and thus a "dynamic" language like Scheme is happy with that <mekeor>i don't understand that, civodul. why can pretty much any language do that? and what do you mean with "dynamic in nature"? – sorry for being stupid <civodul>"dynamic" as in "it happens at run time" <civodul>"any language can do that" because any language can have an interpreter that you invoke at run time to run code <civodul>it's just that in Scheme this is routine, much less so in Haskell <koosha>reepca: I got this : "gpg: no signed data gpg: can't hash datafile: file open error" <rekado_>koosha: what is the command you used? <mekeor>so in guile it's easy to write the source of a program which loads more guilesources at run-time <koosha>rekado_: gpg --verify guixsd-usb-install-0.13.0.x86_64-linux.xz.sig <mekeor>what's the name of the guile-function which loads a string as guile-code? <koosha>rekado_: Wait , I put the decompressed file near the signature . <janneke>mekeor: do you mean: (with-input-from-string "(foo)" read) <mekeor>hmm. i don't really know what i mean, maybe. <mekeor>i wonder what 'guix package -f f.scm' really does with f.scm <reepca>guix/scripts/package.scm:448:9 shows what the option does, and the entry point is way at the bottom in case you want to look <koosha>rekado_: It seems the file is healthy . <rekado_>koosha: that was the last idea I had. <koosha>rekado_: Thank you for all of your helps . <koosha>rekado_: Maybe it's because of the hardware <rekado_>a kernel panic is quite an extreme reaction, though. <rekado_>it may be hardware-related, but I’ve never seen it before when installing GuixSD. <rekado_>the kernel panics in my experience have all been due to a mistake in referring to the disk/partition. <reepca>ACTION flashes back to the time when a syntax error in a herd command caused a kernel panic <koosha>reepca: But you checked the configuration file . <mekeor>mekeor: hah, so it's just the load* function (in case of '-f') (and in case of '-e' it is read/eval-package-expression). interesting! <mekeor>ACTION is looking where load* comes from <rekado_>koosha: do you only have a single disk installed? <koosha>rekado_: One harddisk that GuixSD should be installed on that and the flash I use for live os . <rekado_>koosha: when you boot from disk you remove the flash drive, right? <mekeor>reepca: thanks. (i like using git grep, but i'm not at home right now. i am at work and don't have a local clone of guix here) <mekeor>in emacs, i use counsel-git-grep <reepca>rekado_: woah, I never knew that existed. <efraim>mekeor: it should support the RPI3 but only 1 gig of RAM doesn't sound fun <mekeor>efraim: it's fine for small things. but not fun for building packages. that's what you were saying, too, right? :D <efraim>And the SD card isn't fun for compiling on <efraim>I limited my board search to 2+ gigs of RAM only <mekeor>efraim: what board did you get finally? <efraim>I have the odroid-c2, hikey lemaker 2GB, firefly 3399 with 4/128 and the pine64 with 2GB, but only the odroid and the firefly are hooked up right now <efraim>I don't really expect the pine64 to be better than the odroid but the hikey has 8 GB of emmc so it might work out <efraim>The odroid now just compiles guix packages randomly and runs guix publish, I do most of my guix work now from the firefly running screen on a tty <efraim>It actually compiles faster than my 2007 macbook with guix on debian <efraim>But that machine has a spinning hard drive so it wasn't going to do well anyway <rekado_>in my operating system configuration I told nscd to load the nss-pam-ldapd package <rekado_>but when I run “id account” what happens is that it tries to look up /gnu/store/…-glibc-…/lib/libnss_ldap.so.2 <rekado_>not nss-pam-ldapd-…/lib/libnss_ldap.so.2 <rekado_>I have confirmed that nscd runs with LD_LIBRARY_PATH set to nss-pam-ldapd’s lib directory <rekado_>when I do “LD_LIBRARY_PATH=/gnu/store/…-nss-pam-ldapd-0.9.7/lib id account”, however, it does work. <rekado_>why is it not enough that nscd knows about this nss plugin? <mekeor>efraim: if your odroid compiles enough packages, my raspi wouldn't have to compile them :D <mekeor>do you use paredit-mode when you edit scheme with emacs? <janneke>is there a handy recipe for injecting a ccache package/output from a previous build or previous package version build as an input? <koosha>rekado_: I have emailed . about half an hour . <janneke>ACTION runs guix build regression-test --cores=16 with happy offloading <janneke>just started to play with this hassle-free feature of Guix, wow! <civodul>janneke: i'm glad you're describing it as "hassle-free" :-) <janneke>civodul: me too! ... less hassle :-) <janneke>and wanted to say a thank-you for that, to Guix and whoever implemented it <rekado_>I’ll work on a pam service for LDAP authentication next week. <rekado_>I wonder if we could simplify authentication in the future. <rekado_>doing this with a service here and a service there isn’t really pretty <rekado_>(I’ll essentially copy and adapt pam-krb4-service-type) <janneke>sneek: later tell OriansJ``: i'll be working to remove hex3 from mescc altogether and directly produce hex2..small steps :-) <mekeor>ACTION discoveres "guix pack" :O <mekeor>does anybody use the emacs-package `use-package' within an emacs installed with guix? i have something like (use-package undo-tree). but although i have installed the guix-package "emacs-undo-tree", use-package installed "undo-tree" itself and created a directory ~/.emacs.d/elpa/undo-tree-…. <alezost>mekeor: what's the problem? use-package installs packages through the emacs package system, so the packages are ended in ~/.emacs.d/elpa <mekeor>alezost: ah, right! i was hoping use-package would check if the package was already installed <mekeor>but i guess it only checks if undo-tree was installed in ~/.emacs.d/elpa, right? <alezost>mekeor: well, use-package is pretty unrelated, it is the in-built emacs package system itself (aka "package.el"); and right, it checks things only in ~/.emacs.d/elpa :-) <mekeor>so my main problem actually is that at work i have to use Mac OS, leaving me unable to install Guix there :D <alezost>no problem, I also mix emacs packages from guix and (m)elpa <boskovits>I am trying to package quagga, and I am almost there. <boskovits>I have a patch to make the build reproducible, and now I need to apply it. <boskovits>I see, that patches are applied using search-patches. <janneke>boskovits: put the patch in gnu/packages/patches/ <RX14>i just ran guix system init (from the usb install) and it seems to be compiling ghostscript, is that normal? <RX14>does the usb install add the hydra public key by default? <rekado_>I find it worrying that we still don’t have a substitute for Qt. <RX14>i did not, i was following the install guide <rekado_>the most up-to-date version of Guix does not yet have substitutes for all packages. <rekado_>there should be substitutes for the last release, though. <RX14>yeah i downloaded the 0.13.0 release iirc <RX14>at least that was the version of the bootable iso <RX14>not sure if thats what it installs though <RX14>it's been going for about 6 hours now <RX14>i think I forgot to turn on KVM for the VM but still <lfam>RX14: Although we *should* be providing a substitute for ghostscript, and every package corresponding to the 0.13.0 release, using KVM will make a huge difference if your hardware supports it. <RX14>but for some reason when I used virt-manager to create the VM it failed to boot from the disk image <RX14>even though fdisk -l <image file> showed a dos partition with the boot flag set <lfam>Hm, I always invoke QEMU directly, so I don't have any advice about virt-manager <RX14>well it appears to be downloading most of the other packages <RX14>so far i've seen it build btrfs-progs and ghostscript <RX14>...it just downloaded ghostscript from hydra lol <lfam>Regarding beta status, I'd say "It is still software so some bugs are expected" ;) <earthfail22>A few days ago I tried installing guixsd on my pc and it took all night to tell me in the morning that there is an error. <lfam>What did the error message say? <lfam>earthfail22: Please feel free to report it to <bug-guix@gnu.org>. However, without knowing what failed specifically, it will be hard to take action based on it <earthfail22>lfam: no problem I have few hours to spend tommorow and would try it again :) wish me luck <lfam>Good luck! Ideally you wouldn't need luck to install GuixSD :) <RX14>i'm considering trying using guixsd as my daily driver... should be fun <lfam>Please let us know if you have any problems or suggestions!