<daviid>pizzaiolo: because there is o debian package either, and they are being very nice and helpfull <daviid>pizzaiolo: anyway, if you are happy to send a reddit gnu news about GNU Foliot, it's all on the site... and thanks if you do so <lfam>I want to set up a `guix environment` for python-llfuse, but I want to use Clang instead of GCC. Is that possible? <civodul>lfam: you need to provide a variant of the python-llfuse recipe <daviid>pizzaiolo: just compiled utox for debian, a bit of work but there you go, I don't have guix yet, soon hopefully <daviid>koz_: did yu compile toxic yourelf? i ask because the tar version has no manual <daviid>and maybe you could build itand paste it for me somewhere <koz_>daviid: I used the AUR PKGBUILD. <koz_>Which should contain enough information to reconstruct a build. <koz_>Let me see if I can find it for you. <koz_>Near as I can tell, it amounts to 'run make'. <daviid>koz_: i did clone toxic but couldn't find the time to compile it yet, it's not that easy on debian, and it does not use the autotool chain,which is too bad <koz_>daviid: Yeah, I can imagine not. But that basically says that the magic you seek is its Makefile. <koz_>(since all this PKGBUILD does is call make) <koz_>(the prefix setting is because Arches default to /usr, not /usr/local for stuff) <koz_>Also, thanks for trying to make Toxic available! <koz_>I plan to make a shift to GuixSD once my Libreboot machine arrives, and that's a core part of my system. <OriansJ>mark_weaver: The hex assembler currently assumes a kernel that supports exactly 2 system calls read and write [Syscall 0 & 1 for AMD64 linux], STDIN exists and will terminate the input with EOF, STDOUT exists and that the process calling it supports IO redirection. <mark_weaver>OriansJ: if you assume that a kernel is available, I'm not sure what you gain by avoiding other binaries <mark_weaver>i.e. if you need a kernel, you might as well assume that tcc is available as well <mark_weaver>because a binary kernel is still far more than can be reasonable audited <OriansJ>Well, if need be I can convert a subset of xv6 to provide exactly the subset required. <OriansJ>That however will be a much bigger project <mark_weaver>what's your plan for getting from the hex reader up to a C compiler/assembler/linker ? how much of that process will be portable? <OriansJ>Well, I don't expect any part below C to be portable but custom for the 1 or 2 bootstrap platforms <OriansJ>This is just simply to provide a full trust path to the current bootstrap binaries <mark_weaver>IMO, it's not a full trust path if you need to boot a binary OS first before you can even run your code <OriansJ>Well, I could simply make a hex monitor to provide a bootstrap path to the grounding OS for the hex assembler. AKA I need to build more lower levels <OriansJ>If I need to hand solder a 6502 to 1 MB of RAM to build a full chain of trust, SO BE IT. <mark_weaver>well, I appreciate your goal, and I have the same goal, but I have a very different approach in mind. <OriansJ>mark_weaver: That is fine but Sometimes having multiple ways to the same goal might catch things the other might miss <OriansJ>Looks familiar and very much like my plan. <OriansJ>Also David A. Wheeler's Thesis was the basis of why I wanted to go my route, as we could have any old system that could convert the source to hex to verify the resulting binary as correct. <OriansJ>Think of it, any old C64 could verify the binaries. <kyamashita>If I were to attempt to package the Tor Browser Bundle for Guix, would ARM and MIPS support be necessary? I have seen it packaged for Nix, but they just download and extract the prebuilt x86 32- or 64-bit binaries (the definition checks for architecture). <efraim>you can limit support to only specific architectures <efraim> grep for supported-systems, there's a couple of them <kyamashita>efraim: Also, do we have packages that look for zoneinfo in /usr? I'm also trying to package orage for XFCE. <efraim>I was going to say it might look for $PREFIX/usr or something similar <lfam>Basically, add tzdata to inputs or native-inputs make your package look in $tzdata/share/zoneinfo <lfam>I mean "add tzdata to inputs or native-inputs and make your package look" <efraim>`guix build bootstrap-tarballs --target=aarch64-linux-gnueabi` failed for me on master, trying it on core-updates, which has gcc-5 as default gcc ***imrekt is now known as imr
<habs>Is there a chromium (web browser) package for Guix? <efraim>nothing officially, and I haven't seen one outside yet <z0d>I got the same error as yesterday: this GPT partition label contains no BIOS Boot Partition <z0d>error: will not proceed with blocklists <z0d>I do have boot enabled on sda1 <z0d>this is grub-bios-setup <civodul>z0d: you need to make sure there's a "BIOS boot" partition on your disk <civodul>typically 4M is enough for this partition <z0d>civodul: oh, ok. thanks <mthl>I think GuixSD doesn't work on GPT partition tables ***nckx|offline is now known as nckx
<z0d>civodul`: do I need the boot flag on that partition? ***tardyp_ is now known as tardyp
<mthl>z0d: on GPT there is no boot flag <z0d>you can set some legacy BIOS boot attrib with fdisk <civodul`>mthl: i use GuixSD with a GPT partition table <civodul`>the GuixSD part of the system doesn't really care about partition tables <civodul`>so it should be no different from other typical GNU/Linux systems <mthl>ok, then it is just me who doesn't know what he is doing :) <civodul>heh, or there's a subtle issue that i'm unaware of, who knows :-) ***tschwing_ is now known as tschwinge
<z0d>how can I install a package with an unprivileged user? <z0d>hmm. it didn't work for the first time, only as root, but it works now. <efraim>i believe it has a similar linking issue to 5.3 <efraim>linking issue is probably the wrong word, i'm still jetlagged <civodul>dunno, what are you referring to? :-) <civodul>i'm not jetlagged, but i'm somewhat tired, which doesn't help either ;-) <efraim>i mean when I half-heartedly tried to build it, the error it gave looked like a build issue that was fixed with the patch for gcc-5 <efraim>something about looking in the wrong spot for a library <civodul>we already have a libvtv-something patch, indeed <civodul>janneke: i'm applying the CROSS_C_INCLUDE_PATH stuff (finally) \\o/ <efraim>another half-hearted attempt I had was making arm64 bootstrap-tarballs, which didn't work for me on master with just the 2 patches applied <janneke>civodul: do you think there is any hope to avoid patching gcc, using system-root and profile trickery? <efraim>so now i'm running it on core-updates, definately plan on actually looking more at the error if there is one this time <civodul>janneke: not sure, what's the system-root trickery you're talking about? :-) <efraim>if it works i'll have to actually unbox my arm64 boards <janneke>civodul: wingo asked if we couldn't avoid patching gcc and i cc'd you on some musings i had about that <janneke>ACTION ah just sees civodul's reply to wingo's questions... <civodul>janneke: ah yes, i can see this message now <civodul>i seem to always lack disk space, grrr <lfam>There are patches linked from that mail <lfam>I won't be able to do it for ~12 hours ***civodul changes topic to 'GNU Guix | https://gnu.org/s/guix/ | videos: https://gnu.org/s/guix/help/#talks | bugs: https://debbugs.gnu.org/cgi/pkgreport.cgi?pkg=guix | patches: http://patchwork.sourceware.org/project/guix/list/ | paste: http://paste.lisp.org | channel logged: https://gnunet.org/bot/log/guix'
<bavier>we might need to start another funding campaign to get civodul a bigger harddrive :) <civodul>i found a spare machine at work to which i can offload <civodul>it still has GuixSD 0.8.1, and that is terrible ***jgay_ is now known as jgay
<rekado>I submitted my talk proposal too late for Open Tech Summit 2016, but they offer me a table next to the FSFE where I can present Guix. <rekado>Too bad I don't have any GuixSD t-shirts or stickers. <rekado>not sure how to do this, because I'm really just a person with a laptop. Not particularly inviting I guess. <rekado>maybe I should prepare a poster and get it printed soon. <civodul>you had done a nice poster for work, IIRC? <rekado>oh, it's the day after tomorrow already. <rekado>yeah, but the focus there was too much on sysadmin vs user. <rekado>I'd like to riff on the Emacs of distros theme this time. <rekado>i.e. "practical software freedom" <civodul>paroneayea would suggest not insisting on the Emacs analogy ;-) <civodul>on the grounds that most people we'd like to bring in don't really know what Emacs is, or at least its design philosophy <rekado>yeah, I wouldn't mention Emacs (even though it feels very much like it) <Steap>As a vim user, I'm frightened by this analogy <Steap>"Have we gone too far? What is this abomination we're building?" <civodul>we don't wanna lose the Steaps of the world <rekado>currently I have to install a lot of workstations and I must install and configure Ubuntu. It's all just sadness. <civodul>i think we should replace it with a 5mn demo <jlicht>...ergo your call for nice screencasts, probably? <civodul>GCC 6.1 build phase takes 46mn on a quad-core desktop machine <efraim>gcc 6.1 took about 6 hours on my machine <efraim>i really should have my dad bring computer parts when he comes next month <efraim>in the mean time I have some laptops to set up as guix offload machines <civodul>the fact that we can upgrade from a 1.5 year old GuixSD is pretty good <civodul>the only glitch i encountered is that guix-daemon (the old one) would insist on using hydra.gnu.org (instead of the mirror), which is rather slow <mark_weaver>bah, the fan on librenote (one of our mips build slaves) is dead again. <mark_weaver>I replaced it last year. this time I should buy more than one of those replacement fans, I guess. <davexunit>pizzaiolo: packagekit's architecture is incompatible with Guix <davexunit>because it assumes that only the root user can install software <pizzaiolo>if it works with nix, it might work with guix <frafra>I'm trying to install guix, but I encountered an error regarding ghc: it gives me an I/O error "probably due to network issues" <frafra>my connection is not so good and I would like to know if it would be possible to resume the download <frafra>do I need more than 2 GB of RAM? <frafra>or, the new partition is not mounted, my fault... ops... <jlicht>frafra: afaik, if a download is not complete, you have to retry it again :/ <jlicht>there used to be another mirror that (for me) was a bit more reliable, but I'm not sure about that nowadays. You could search the irc logs and/or the mail archive <frafra>jlicht, thank you, but I think it was because my root partition was not mounted :D now I'm trying to reinstall <yrns>Does anyone know how to configure gdm? It appears it only reads the (stock) custom.conf out of the store, and there's no command line option. <ngz>Hello. Whenever I try to compile some package, I get "Unbound variable: cmake-build", even though "#:use-module (guix build-system cmake)" is at the beginning of the module definition. Any idea about what is wrong here? <roelj>ngz: Shouldn't it be cmake-build-system? <ngz>The package itself has (build-system cmake-build-system), the whole module uses (guix build-system cmake). <ngz>I'm packaging thinkfan. <ngz>It used to build correctly. The only noticeable change introduced is a #:modules keyword in the `arguments' part of the package definition. <bavier>the cmake modules need to be included in #:modules <civodul>ngz: IIRC someone posted thinkfan a day ago <ngz>bavier: I tried to include it in #:modules, too, using ((guix build cmake-build-system) (guix build utils) ...). No luck. <ngz>civodul: It was me, indeed. <lfam>Just popping in for a minute to say I'm glad we patched the OpenSSL and wpa_supplicant bugs so quickly! <lfam>Yes, did you see my question on that thread on guix-devel? I just want to clarify the intended method of ungrafting <civodul>i think mark_weaver & you are proposing the same thing <civodul>i thought i'd let mark_weaver confirm <lfam>Okay, I wasn't sure since he seemed to contradict my suggestion but I interpreted his suggestion as being the same as mine <lfam>Also, is it normally okay to merge master into core-updates, or should I ask first? <ngz>bavier: so basically #:modules keyword resets all modules loaded using #:use-module at the beginning of the file? <frafra>is it possible to use custom cflags? <bavier>ngz: no, it overrides the default modules that are available to the package builder <ngz>bavier: what are these default modules? <bavier>ngz: look at %gn-build-system-modules and %default-modules in (guix build-system gnu) <ngz>bavier: Just to be sure I understand, if I want to use, e.g., (guix build utils) and (srfi srfi-26), I need to add both to #:modules even though %default-modules contains it. Is that correct? <civodul>sneek: later tell lfam merging master into core-updates is OK :-) <kyamashita>Where in the guix tree can I find out what each procedure does? <kyamashita>Also, more specific to this case, how would I find and replace the contents of a file in the build directory of a package? Is there a regexp-type thing that I can do? <bavier>kyamashita: look at 'substitute*' <kyamashita>bavier: Ah. This works, so I'm assuming there's something up with the build system that I'm missing. 