<espectalll>ok, so seems like I forgot that, otherwise it's fine <espectalll>...oh, and the boot manager stores previous configs!? <espectalll>...that has just saved me a ton of effort trying to fix my installation – I'm shocked, really impressed <baconicsynergy>Imagine just instantiating a minimal GNU system running on top of the Minix kernel <espectalll>(from what I know, efforts are already ongoing there) <rain1>minix is working good with freebsd, i wonder if guix could be used on that? <espectalll>but yeah, a few additions such as Minix or… perhaps other BSDs, perhaps Redox, perhaps ToaruOS??? <baconicsynergy>Getting a fully functional microkernel multiserver running under GuixSD would help us learn a few tricks <baconicsynergy>But GuixSD being kernel agnostic would only strengthen the framework as a whole <baconicsynergy>has anyone been able to setup a successful GuixSD/Hurd setup yet? <baconicsynergy>(but we really need to get rid of mach... im sorry if this is an unpopular opinion) <baconicsynergy>but it's ancient at this point and is in no condition for a modern operating system <espectalll>Don't worry, I barely know stuff about Mach other than it's on NeXTSTEP and Hurd <baconicsynergy>It would be incredible if the l4-hurd mailing list starting talking about the idea of using the seL4 kernel and have a Memory Server that delegates memory as a matter of policy <baconicsynergy>It doesn't matter what microkernel runs on the Hurd... it'll always be the Hurd we know and love <espectalll>oh yeah, I've been hearing for long about porting Hurd to L4 as well as seL4 <espectalll>however, just as with Mach, can barely talk about it other than "it's a thing, looks cute" <espectalll>I can happily go to bed now that I know this little utopic project works <OriansJ``>ah the joys of hunting down recursion to prevent stack overflow <OriansJ``>janneke: and now M0 supports separate architectures (usual 1 for x86 and 2 for amd64) <efraim>it looks like debian crossbuilds gccgo for aarch64 from amd64 <rekado_>sneek later tell koosha_ I can reproduce the problem to build grub. <rekado_>sneek: later tell koosha_ The failing test in grub has been disabled in the latest version. <balduin>I use a gnu-build-system in the package definition, but get the following error message: make[1]: cc: Command not found <efraim>balduin: you'll need to set a make-flag for "CC=gcc" <sneek>Welcome back koosha, you have 2 messages. <sneek>koosha, rekado_ says: I can reproduce the problem to build grub. <sneek>koosha, rekado_ says: The failing test in grub has been disabled in the latest version. <koosha>rekado_: So now if I repeat the installation there should no be a fail ? <balduin>@efraim: by the way thanks for the aarch4 binaries. I was able to start and use certain guix commands. <balduin>However, I have to understand guix better, before I can do more experiments with aarch64 and ripi3 <balduin>@efraim: is there an example package/code I can look for the make-flag command, because I did not understand how this should look like in code <balduin>I found an example file with make-flag <sneek>Welcome back civodul, you have 2 messages. <sneek>civodul, ng0 says: about the email I sent today, I think I looked at it the wrong way. I am reading (gnu packages make-bootstrap) now which obviously comes before (gnu packages bootstrap) <sneek>civodul, mekeor says: that maybe "please use a pastebin like paste.lisp.org" should be added to channel-topic? <civodul>rekado_: did it come back since last week-end? <civodul>ae was supposed to take care of it this week-end <rekado_>didn’t ae write that it had been rebooted? <rekado_>the email was sent on Sun 25 Jun 2017 05:21:47 PM CEST <civodul>did you try to reboot it via the APC? <civodul>you don't have to go through fencepost though <civodul>i've rebooted it but it's not coming back (yet?) <rekado_>ah, I thought one has to go through fencepost. <rekado_>hmm, direct connection times out for me. <civodul>there's an IP whitelist on that one? <civodul>it takes several seconds to get connected <reepca>civodul, rekado_: I've noticed there's a lot of functionality that is almost exactly what I want to use already written, but it relies on rpc calls for the low-level stuff (mostly accessing the database). How feasible would it be to modify, for example, define-operation so that operations become generic functions which can be specialized on the "server" type? <reepca>... and I just realized that "rpc calls" is much like "RIP in peace". <civodul>i would be tempted to do something ad-hoc until we have evidence that this leads to too much duplication :-) <civodul>but maybe you already have enough evidence <civodul>reepca: conceptually though, it would be interesting to make those RPCs more like "methods" <ng0>I have an really plain question, just started reading into the whole bootstrap. Is the content of https://alpha.gnu.org/gnu/guix/bootstrap/{arch}/{date}/ the binaries of upstream or generated from make-bootstrap? after what I've read yesterday and looking into one of the archives on there I am at the position where I see that it is from make-bootstrap. <civodul>most of it was generated a long time ago though <civodul>in the early days of make-bootstrap.scm :-) <ng0>I was told yesterday that my goals with infotropique OS and LIVE are very intransparent.. I'm writing an handbook which hopefully should make more clear why I'm asking questions like these and how I came to the layout of the system where I am now. in the very beginning I hoped it would be easier. <ng0>I admitedly suck at creating transparent websites and I am much better at explaining all of this in person. <ng0>where in person means offline, talking to people of course. <ng0>my friend suggested I should get a writer like Plato or make video recordings :D <OriansJ``>ng0: well there is a project of sorts to replace the current bootstrap with something easier to audit by reducing the total number of binaries down to ideally 1 and under 200 bytes total. <ng0>well without having time to offer an in-depth explanation today, I want to build everything with musl instead of glibc. So I have to change the bootstrap when I want to kick out glibc. <ng0>more than just in the bootstrap though <ng0>I haven't been following your project in depth. Is this tailored around the current set of bootstrap binaries of Guix? I know what it is about, just not the current state or its ultimate goal, OriansJ`` <rekado_>I don’t get substitutes for many, many packages. <rekado_>and that’s despite hydra telling me that it has built these packages already and nothing is waiting in the queue. <ng0>OriansJ``: I have to leave now, email works better for me these days. May I send you an offlist message asking about the status of the whole project and everything? <rekado_>ng0, OriansJ`` I’d like to suggest using the bootstrappable.org mailing list. <ng0>okay, didn't know you had an mailinglist. Okay :) <ng0>have a nice day everyone <rain1>Firefox can’t establish a connection to the server at bootstrappable.org. <rekado_>rain1: yeah, it’s on bayfront, which hasn’t come back to life :( <rekado_>the bayfront hardware is a great source of frustration. <efraim>What about marioush's(sp?) Amazon Hydra cache? <rain1>fundamentally you just need to consider whether the inputs required to build a project contain the result of building the project <rain1>if you take each project that does this, e.g. gcc, and find a way to build it with something smaller then you should be able to reduce everyting down to a core <civodul>rekado_: hydra is apparently building stuff, according to M-x guix-hydra-queued-builds <espectalll>oh, so there's a way to check Hydra's current activity locally? <nee`````>The "compiling..." stage of guix pull takes a lot more time since the switch to guile-2.2 <nee`````>guix build --target=i686-w64-mingw32 perl <nee`````>this always fails for me, because (assoc-ref inputs "libc") is #f <civodul>nee`````: it may be that this simply isn't supported, you'd have to talk to janneke who wrote the MinGW cross-compilation target <ng0>rain1: I intend to keep this mirror in sync manually (rebased branch), eventually there'll be a short downtime when the content of the server is moved somewhere around the end of the month (hopefully) <ng0>*I intend to keep this mirror, and keep it in sync… <janneke>nee`````: the only packages supported are currently: hello and guile+dependent libraries <nee`````>ah okay, so building a game based on sly with mingw will probably fail somewhere. Thanks for the info janneke, civodul. <rain1>(for bootstrapping) im building binutils with strace running to get an overview of the programs it requires to build <janneke>nee`````: it depends, what are the dependencies of sly? <nee`````>janneke: guile-opengl, sdl2, sdl2-image, sdl2-mixer, and sdl2-ttf I think. <janneke>yeah, that probably needs work here and there <nee`````>janneke: also gsl (GNU Scientific Library) <rekado_>rain1: the mailing list is hosted separately, so it should work even if bootstrappable.org cannot be reached. <rekado_>civodul: usually I would expect hydra to indicate that there are queued builds waiting for a particular package. <rekado_>but that’s not the case for the packages I looked for. <civodul>do you have an example of a package that looks stuck>? <rekado_>e.g. the arm-none-eabi cross gcc @ version 4. <rekado_>I did not see any queued builds on the page for that package <rekado_>(can’t load the page right now, because hydra.gnu.org times out) <civodul>it could also be that the substitute wasn't baked yet <rekado_>I hope to hear from the asset manager soon to get a decision on whether the many retired cluster nodes could be donated to Guix Europe. <rekado_>I suppose we would need to get new network cards for each of them <rekado_>hosting them would be a bit of a challenge in any case. <rekado_>does hydra still need to compress so much to cause a build to be performed on a build node? <civodul>yes it still compresses when offloading things, see (guix build offload) <rekado_>or would it make more sense for this cluster of build hosts to have its own cuirass instance…? <civodul>but honestly, the main problem on hydra.gnu.org right now is that i/o is slow, not that compression eats all the CPU <civodul>the machine often has a very high load despite being idle CPU-wise <civodul>as for the usage of this cluster i don't know <civodul>problem is that hydra.gnu.org is the bottleneck now :-/ <rekado_>re Emacs: I submitted a bug (27498), and the response is that this is bug 26952. <rekado_>for 25.2 configuring with REL_ALLOC=yes should fix it. <civodul>rekado_: for the M-x shell-mode bug that leads to a crash? <rekado_>it doesn’t lead to a crash for me; it just eats up all memory, which sometimes forces me to reboot when I don’t catch it early enough. ***octe_ is now known as octe
<janneke>can i get package-version of the current package in the build recipe? <rekado_>I suppose you could do (package-version parent), where “parent” is the same package that you inherit from. <rekado_>if doing this inside of a build phase, you’d need to unquote <janneke>the recipe is defined in the parent, i'd like to access the version of the inherited package that is being built <ng0>in the build phase or receipe? <ng0>if just the version so that you have "versioN": (inherit parent) (version (package-version parent)) <ng0>so what rekado_ wrote <janneke>in arguments, actually i want to set #:parallel-build? #f only for some broken versions <janneke>hmm, better just handle in child package prolly <jsierles>rekado_: you mentioned R CRAN definitions might be fully imported into upstream. is that still a possibility? <espectalll>Hey again! I have what's hopefully my last question <espectalll>I have installed GNOME Shell + GVFS but noticed devices don't automount <espectalll>I noticed by looking at other's public `config.scm` that there is a service called `udisks-service` <civodul>espectalll: no, i think GVFS is responsible for the automount feature that you see in GNOME <civodul>note that you should be using 'gnome-desktop-service', which sets up everything correctly <espectalll>maybe I'm doing something wrong while trying to insert stuff…? <civodul>espectalll: could you paste your OS config? <ng0>rekado_, civodul: so I have an interest check. imagine that with the help of one or two people I manage to move a large portion or all packages which are possible from openssl to libressl. would this be accepted into Guix? this is one of the two big batches of code which would be major pain to maintain in difference (but will be done). <ng0>basically using libressl instead of openssl with the exclusion of software which wasn't properly tested with it <civodul>ng0: that would need to be discussed on the list, there are pros and cons i suppose <ng0>ok. once I have my design written down and published, would you like an text version of it send to our guix-devel list? I'm really interested in keeping the amount of micro-forks in the code to a justified minimum. <civodul>ng0: i think it's OK to just send that sentence that you wrote above, to get initial feedback <civodul>maybe clarify the rationale a bit and that's it <ng0>I tried in the past I think. Didn't go very far <ng0>"someone needs to do it" <civodul>right, but other than that, there are questions about the strategy <civodul>what seemed like an obvious choice at the time of heartbleed is less obvious today <ng0>Okay. I will add more detail to the sentence <civodul>OpenSSL gets funding from CII, LibreSSL does not, for instance <ng0>Okay, funding is one of the implicit things I did not consider <ng0>Ah, but isn't LibreSSL funding by OpenBSD (in case OpeNBSD gets funding)? <ng0>I'll look into this. Anyway, thanks. I'll send an email about this soon. <lfam>It's definitely a discussion for the mailing list, since interested people might not be on IRC right now <ng0>yeah.. I might lag a bit, so I hope to get it out this week or next week. What I'd really prefer is a modular approach to SSL libs, libc's etc. This is taken in consideration to look into after what I planned, not immediately. Vague sentences, maybe it's easier I finish the text and have it public. <ng0>I have to leave now. Bye :) <rekado_>espectalll: you need to install gvfs in the system profile. <espectalll>I had it explicitly typed, I have just changed it to `gnome` (after finding out that USB automount works) <rekado_>jsierles: yes, I could commit an initial patch to add the (gnu packages cran) module this week <rekado_>we do have a problem with the size of the full module, though. <jsierles>it would be good to have it upstream to start adding things like system dependencies <espectalll>…OK, it was as simple as adding the user to the `cdrom` group <espectalll>Excuse me while I go format my macOS partition table <jsierles>with a default install of guix, using 'guix package -i package' asks me to update the PATH to include the default guix profile <jsierles>is there a way, for a given set of packages, to just directly create a symlink to their associated profile? <jsierles>i'd like to skip this step of updating the path, and instead just have .guix-profile link directly to my updated profile. <bavier>jsierles: that is what ~/.guix-profile is <bavier>jsierles: the warning is letting you know that binaries installed there will not be found, since that directory is not in $PATH <jsierles>bavier: OK, thanks. would a solution simply be to source .guix-profile/etc/profile? <jsierles>OK. so as long as I always source that when entering my shell, i should have the profile I last entered using 'guix package' <jsierles>is there a way to append to an existing profile? for example if I already am using 'guix package -i r-minimal' and I just want to add a few packages to that, without having to know about 'r-minimal'. <bavier>jsierles: just `guix package -i ...` again <bavier>jsierles: the profile gets a new "generation" <jsierles>can I use 'guix pack' to copy entire profiles to be untarred into another guix store? <janneke>OriansJ``: how do i get started with M1/M0? I see x86-like stuff: ADD_eax_Immediate but also more cpu-agnostic things like LOADUI R0 10 -- I'm confused <rain1>i sent a message to the bootstrapping list! <rain1>it might be obvious to most people but I thought i'd say it anyway <solene>hello, I'm trying to install a haskell software with cabal but it complains that libgmp isn't availale. I installed it and it's available under ~/.guix-profile/lib/libgmp.so.10 is there something special to do ? <solene>efraim: what, the cabal problem ? <efraim>it sounds like it should be built with gmp, but i don't know, i've never used haskell <efraim>this is from the cabal-install package? <solene>maybe I'm doing something wrong, cabal complains about GHC_LIBRARY_PATH so I need to unset it... I'll investigate before asking on the mailing list <ng0>sneek: later tell civodul: Okay I ditched the whole OpenSSL->LibreSSL after talking with a friend of mine <ng0>sneek: later tell civodul: in short, it's not worth the effort. <adfeno>Long time no see, I had to be absent on IRC for some time. I'll still have to, but I must solve some problem I have with my copy of Guix. :) <ng0>sneek: later tell civodul: And it is likely to introduce problems on its own technically besides incompability. I don't want to go into detail. <adfeno>ng0: I don't know about differences between OpenSSL, LibreSSL, and GnuTLS, but I'm in favor of GnuTLS. :) <ng0>What you missed was about a potential discussion on globally (where it technically makes sense) to replace OpenSSL inputs with LibreSSL inputs. <efraim>ghc definately links against libgmp <efraim>and cabal from cabal-install links against libgmp, I don't know what to say <solene>efraim: I'm running cabal-install from a folder of an haskell program with <solene>cabal install -j --only-dependencies <adfeno>Well, back on my own track: I just followed the discussion on the issue while building glibc for i686, and I'm quite puzzled on what to do now, as I do have a i686 here, I did a `guix pull` as root last weekend, but when trying to `guix package -u guix` (as root too) I got the glibc bug... <adfeno>... Morever, seeing that core-updates branch has the update that tries to fix the bug, I attempted the following today: <adfeno>But I still get stuck on the glibc bug. <adfeno>(note: prior to the last `guix pull`, `guix gc` was used, and the last `guix pull` was also run as root) <solene>efraim: I see that I have ghc 7.0 installed and 8.0 <rekado_>sneek: later tell civodul The memory leak in Emacs is gone when configuring with "REL_ALLOC=yes". It still grows as output is produced, but it frees the memory when the buffer is closed, so recovery is easier. <rekado_>adfeno: there was a problem with glibc on i686. <solene>offtopic : I know common lisp and learn Scheme a bit using chicken. Does guile differs a lot compared to another scheme interpreter ? <adfeno>rekado_: Indeed, there was, I was following the topic on the mailing list :) <adfeno>Now, I just have to find a way to make my `guix pull` work again :) <solene>how is that possible that /gnu/store is a read-only filesystem while it's on / ? <solene>I would like to add a firmware file for the kernel, how can I do ? <civodul>solene: /gnu/store is a read-only bind mount <sneek>Welcome back civodul, you have 4 messages. <sneek>civodul, ng0 says: Okay I ditched the whole OpenSSL->LibreSSL after talking with a friend of mine <sneek>civodul, ng0 says: in short, it's not worth the effort. <sneek>civodul, ng0 says: And it is likely to introduce problems on its own technically besides incompability. I don't want to go into detail. <sneek>civodul, rekado_ says: The memory leak in Emacs is gone when configuring with "REL_ALLOC=yes". It still grows as output is produced, but it frees the memory when the buffer is closed, so recovery is easier. <davidl>Im trying to install Guix again and get the error: guix system error: profile contains conflicting entries for gtk+=out <nicorikken[m]>I finally tried out Guix, on my Debian install. I walked through the binary install procedure, and managed to install 0AD. I'm very, very impressed!! Thank you all for this wonderfull project. I'm aiming to bring some Clojure love to Guix in the future. <civodul>nicorikken[m]: thanks for the kind words! would be nice to see Clojure parentheses in here :-) <civodul>davidl: there's an open bug for Xfce about this right now <solene>civodul: hmm, I'm not sure that helps in my case. I'm trying to load non-free intel firmware, the driver is compiled inside guix (maybe it should not as the firmware isn't distributed and not free) so I thought I could get it work <civodul>solene: GuixSD does not provide non-free firmware so you'd have to look for help elsewhere <civodul>but the general principle is the same <civodul>sneek: later tell alezost do you think guix-search-by-regexp could sort by relevance like 'guix package --search' does? <rain1>would be amazing to bootstrap all of guix from just guile <ng0>civodul: why has #27388 been closed? I've seen other "wishlist" bugs aswell… <ng0>having a keyless ssh file is not so uncommon <civodul>i admit i also didn't understand the Subject line <civodul>ng0: please reopen it if i just messed up! <ng0>Hm... the limitations of text. Yes, it was wrong. I thoight about a possible solution and ended with "this solution can't work and I'm open to anyone else who comes up with one" <civodul>ng0: but please make sure to describe the problem rather than the solution <ng0>I think my gnunet-fuse problem suffered the same case. <ng0>and the other bug you closed. it is an issue, and I tried to describe both more in detail some minutes ago <ng0>but it's too late, just wanted to check what's up with that :) <civodul>hmm no the gnunet-fuse problem was not a bug from Guix's perspective, as i wrote <ng0>how is it not a bug if the package definition doesn't even remotely includes a package and it pop ups repeatedly into the build environment instead of the one I defined? <ng0>in my world that is a bug :) <ng0>but I described it a bit better in the last email