IRC channel logs


back to list of logs

<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
<koz_>I'm using Toxic.
<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.
<daviid>koz_: thanks!
<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.
<janneke>ACTION -> zZzzz
<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
<mark_weaver>I'm sorry, but I think your approach is misguided
<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.
<mark_weaver>but I don't have time to talk about it more now..
<OriansJ>mark_weaver: That is fine but Sometimes having multiple ways to the same goal might catch things the other might miss
<mark_weaver>OriansJ: you might want to look at this:
<OriansJ>Looks familiar and very much like my plan.
<OriansJ>I was actually thinking of using to eliminate having to trust any x86 Manufactor.
<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
<kyamashita>efraim: How so?
<efraim> grep for supported-systems, there's a couple of them
<kyamashita>efraim: Alright.
<kyamashita>efraim: Also, do we have packages that look for zoneinfo in /usr? I'm also trying to package orage for XFCE.
<efraim>that I don't know
<lfam>Yes, grep for zoneinfo
<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
<civodul>Hello Guix!
<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
<civodul`>so i think :-)
<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?
<Acou_Bass>guix package -i packagename
<z0d>hmm. it didn't work for the first time, only as root, but it works now.
<civodul>oh, we still don't have GCC 6.1?
<civodul>ACTION builds GCC 6.1 on master
<efraim>i believe it has a similar linking issue to 5.3
<civodul>linking issue?
<civodul>gcc 5 works fine on master
<efraim>i know, it has a patch
<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
<efraim>with libvtv
<civodul>ah ok
<civodul>we already have a libvtv-something patch, indeed
<civodul>let's see
<civodul>i first need "guix gc -F 2.5G"...
<civodul>janneke: i'm applying the CROSS_C_INCLUDE_PATH stuff (finally) \\o/
<janneke>civodul: yay!
<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>efraim: fun
<civodul>janneke: not sure, what's the system-root trickery you're talking about? :-)
<civodul>ACTION still has a backlog
<efraim>if it works i'll have to actually unbox my arm64 boards
<civodul>the eternal backlog, it seems
<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>lemme see
<civodul>bah, ENOSPC while building GCC
<civodul>i seem to always lack disk space, grrr
<rekado>same here ...
<lfam>Alarming bug in wpa_supplicant:
<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 | | videos: | bugs: | patches: | paste: | channel logged:'
<mark_weaver>better URL for that wpa-supplicant issue:
<mark_weaver>I'm on it
<civodul>great, thanks a lot mark_weaver
<civodul>arggh, ENOSPC again
<bavier>we might need to start another funding campaign to get civodul a bigger harddrive :)
<civodul>heh :-)
<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
<civodul>a lot of progress has been made :-)
***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.
<civodul>that'd be nice
<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.
<civodul>oh :-)
<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>rightfully so, IMO
<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)
<rekado>I'm really happy with GuixSD.
<civodul>a happy user! :-)
<Steap>As a vim user, I'm frightened by this analogy
<civodul>see :-)
<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.
<Steap>civodul: yes you do!
<jlicht>civodul: would it make sense then to not have the first interactive piece of media on to not be exactly the emacs analogy?
<civodul>jlicht: definitely!
<civodul>i think we should replace it with a 5mn demo
<jlicht>...ergo your call for nice screencasts, probably?
<civodul>exactly :-)
<civodul>GCC 6.1 build phase takes 46mn on a quad-core desktop machine
<bavier>not too bad
<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
<civodul>6 hours is really a lot indeed
<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 (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.
<mark_weaver>ACTION removed it from machines.scm
<paroneayea> new openssl vlunerability? I guess we should probably put out a new fix?
<mark_weaver>paroneayea: thanks
<mark_weaver>ACTION tests the openssl graft before pushing it
<davexunit>pizzaiolo: packagekit's architecture is incompatible with Guix
<davexunit>because it assumes that only the root user can install software
<pizzaiolo>davexunit: yes, someone is working on that
<frafra>hi everybody :) new user here
<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>ops, it looks like / is full
<frafra>do I need more than 2 GB of RAM?
<frafra>or maybe herd start failed?
<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?
<roelj>ngz: Which package is this?
<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
<civodul>or was is you?
<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.
<civodul>ah ok :-)
<lfam>Just popping in for a minute to say I'm glad we patched the OpenSSL and wpa_supplicant bugs so quickly!
<lfam>Thanks mark_weaver!
<civodul>and thank you for the heads-up :-)
<civodul>now we need to ungraft
<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>OK, thank you.
<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?
<bavier>ngz: 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.
<kyamashita>bavier: It's working for nethack but not orage.