IRC channel logs


back to list of logs

***Gamayun_ is now known as Gamayun
<Apteryx>why does system* accept empty args '() but invoke insists on strings?
<Apteryx>hmm, maybe that's not true.
<noobly>dumbo question, but GuixSD should work fine on ANY system, no matter how freedom-restricting, so long as it's in a VM, correct?
<ZombieChicken>I was wondering how much the system init file has changed since ~0.11
<ZombieChicken>Uh, doesn't Guix have LVM support? The online docs says it doesn't, but I seem to recall someone implemented that a while back...
<ZombieChicken>nvm. I'll give guix another try in maybe 6 more versions in hopes I can get it to install without having to dive through source code and trying to decypher error messages that make no sense.
<civodul>Hello Guix!
<catonano>I do "guix environment guile" and then ./
<catonano>I get: ./ riga 14: autoconf: comando non trovato
<catonano>autoconf: command not found
<civodul>catonano: that's expected
<civodul>try "guix environment guile --ad-hoc autoconf automake libtool"
<catonano>civodul: thanks
<civodul>yw :-)
<catonano>also flex is missing. Is that expected too ?
<clacke[m]>catonano: don't do guix environment guile, that creates the environment necessary to compile guile
<clacke[m]>you want guix environment guix
<catonano>clacke[m]: no, I want to work on guile itself
<catonano>not guix
<civodul>ah yes, you need to add flex as well
<catonano>specifically, I'd like to prod the Texinfo parsing machinery in a REPL
<clacke[m]>oops that'll teach me to jump into the conversation
<catonano>clacke[m]: it's ok :-)
<clacke[m]>civodul: why is guix environment guile insufficient to get flex, autotools etc?
<catonano>it's "bootstrapping" now. Admittedly I'm a bit worried. What can I expect ?
<clacke[m]>ah, because the package builds on the release tarball
<clacke[m]>and presuably catonano is working off git
<catonano>clacke[m]: I am
<catonano>isn't that adviceable ?
<clacke[m]>it simply explains why you needed more tools
<clacke[m]>if you get past bootstrap you're all good
<catonano>clacke[m]: "if" I get past bootstrap ? :-)
<mbakke>We still don't have a successful Shepherd build on Hydra for i686 and armhf.
<mbakke>(on core-updates)
<civodul>mbakke: we almost do, though :-)
<civodul>it's a non-deterministic issue for which i pushed a fix in Shepherd proper
<mbakke>I tried restarting them again, once they complete I'll try the "restart all dependency failed builds" button.
<mbakke>Also python-enum34 is failing with 1111 dependents, working on that now.
<mbakke>Oh nvm, only the python3 variant is failing. I suspect we can remove it.
<efraim>python-enum34 fails on aarch64-linux on core-updates also
<rekado_>ACTION starts processing the Guix mini conference videos
<rekado_>does anyone have a package for the Ada compiler? I’ll need that to build coreboot.
<efraim>Ada depends on Ada
<efraim>I can send you my debootstrap package, then you can use a debian chroot and use their Ada
<pch>Hello Guix, i am able to download the file, but as a next step need to match the hash of the file downloaded, with the hash which I specified.
<pch>How to do it and generate an error, in case of an error?
<rekado_>efraim: a debootstrap package sounds very useful.
<rekado_>efraim: when you wrote “Ada”: did you mean a particular compiler? I’d like to get GNAT installed.
<rekado_>pch: after downloading the source file (e.g. with wget) you can run “guix hash” on the file.
<efraim>I can't get the link easily from links, but its at in my-guix in dfsg/main/debootstrap.scm
<efraim>Debootstrapping itself needs gnupg, Perl and coreutils also iirc
<pch>rekado_: i mean i want to do it as part of the .scm file
<pch>rekado_: as part of package installation my file was downloaded into my ~/.guix-profile/bin/ with a hash
<rekado_>pch: I don’t understand.
<rekado_>maybe I’m just missing context.
<pch>just have a look at the snippet
<rekado_>can’t view it with eww :-/
<catonano>rekado_: I just managed to install Guix on Fedora with your script.
<catonano>rekado_: yuppiihii !
<Cthulhux>I am actually confused about the Guix distro: The package repository is awesome and still there's close to no media coverage.
<Cthulhux>I consider giving it a try.
<efraim>guix system init ~/pine64.scm /mnt finished, I'll have to wait a bit before testing it :(
<rekado_>catonano: nice! (Credit goes to sharlatan who wrote the script that I adapted.)
<rekado_>catonano: how about SELinux, though? Did you disable it or have you tried the policy I wrote?
<catonano>rekado_: I didn't try your policy yet
<catonano>I applied the patch to a guix checkout
<catonano>but then I can't find your etc/ file
<catonano>maybe I'm tired
<catonano>ah the patch wasn't applied
<catonano>gotta go to lunch now. Hear you later
***danialbehzadi1 is now known as danialbehzadi
<jlicht>hi guix!
<catonano>Hi jlicht !!
<catonano>ok, make guile ended successfully
<civodul>efraim: pine64, sounds cool!
<mbakke>efraim: I have a debootstrap package too, but I have to run it twice. Can you send it to me too? Let's try to get it in Guix proper :)
<efraim> I haven't decided about wrapping or propagating the runtime dependancies, I think gnupg, Perl and coreutils
<clacke[m]>efraim: ah! so you're that efraim. :-)
<efraim>Yep, I gave up on making a real Nick years ago
<civodul>heya roelj!
<roelj>Hello civodul
<roelj>If one uses GUIX_DAEMON_SOCKET, does one then also need to do something special when one uses (derivation->script ...)?
<roelj>Because I now get: srfi-34: #<condition &nix-protocol-error [message: "regular file expected" status: 1] 2ddee70>.
<rekado_>ugh, the sound in the video recordings is terrible… :(
<rekado_>(the recordings of our mini conference)
<rekado_>the receiver jack didn’t fit tightly in the socket of the camera, so it is in a constant battle between being disconnected and connected.
<rekado_>this makes everyone sound really weird as the frequency of switching is in the audible range.
<rekado_>it’s like low-frequency ring modulation.
<rekado_>and sometimes it’s just muted :(
<rekado_>eelco sounds like a storm trooper.
<rekado_>that’s just because my adapter broke on that day :(
<mbakke>rekado: Did you try updating numpy, pandas and friends? Otherwise I'll start on that now.
<mbakke>python-flake8 propagates a non-existent "python-enum" package. Why does Guile not warn about this variable being unbound?
<rekado_>mbakke: no, I haven’t touched these packages yet.
<mbakke>rekado: Ok, I'll try updating the whole shebang. Fixed some of the leaf packages now.
<ng0>efraim: I can't really connect to your cgit, but: if you have debootstrap, do you have a dpkg packaged? I've been working on that for a while, my only application is extraction deb files, which should already work.. maybe you have it too and we could compare them
<rekado_>I have dpkg.
<rekado_>but it’s almost useless if you don’t have a Debian system.
<ng0>yeah.. but extraction of .deb's it works
<ng0>*but for
<ng0>about what I wrote on the mailinglist a couple of days ago wrt RISC-V: I've read a bit into how Fedora and Debian have done the bootstrap, good source
<ng0>I seem to remember dkpg being an optional dependency for some applications
<ng0>or mabye memory serves me wrong
<mbakke>numpy will stop supporting python 2.7 by the end of 2018.
<ng0>okay, memory served me wrong. there was a failure with librpm that I stil need to look into in our libextractor
<rekado_>mbakke: finally.
<rekado_>mbakke: but it doesn’t change the fact that even in 2018 new software is written that targets Python 2.7 only — and that has dependencies on the scientific python stack.
<rekado_>(e.g. nanopore support tools)
<mbakke>Yes, 2019 can get messy on the Python side (what else is new...).
<ng0>it seems unrealstici that python2 will be "gone" by 2020.. it will still be used and there will still be legacy software with it
<rekado_>sneek: later tell catonano The SELinux policy is now part of the repository.
<rekado_>sneek: two botsnacks.
<rekado_>sneek: do you prefer just one botsnack?
<rekado_>I guess I have a thing or two to learn from sneek.
<rekado_>ACTION goes to the kitchen to feed on Belgian chocolate
<pch>Hello guix, how can i specify source->uri using "local-file"?
<ng0>efraim: how do I clone from the git? standard git-protocol port is timing out, standard cgit url over port 80 is timing out, webview of cgit too
<rekado_>roelj: you don’t need to do anything special when using GUIX_DAEMON_SOCKET, in my experience.
<roelj>Right, in that case.. Any ideas what could cause guix-daemon do throw the error with message: "regular file expected"?
<mbakke>Argh, the flake8 enum34 fix apparently rebuilds mesa... I think we'll have to take that hit :/
<roptat>pch: from my backlog: (source (local-file "/path/to/file"))
<roptat>but then there is no check for the hash...
<bavier`>hello guix
<efraim>sneek: later tell ng0 I'll have to look at it again, for now I also have it mirrored at
<sneek>Will do.
<efraim>sneek: botsnack
<efraim>sneek: later tell ng0 I do have a preliminary dpkg package, but you can also unpack debs with 'ar'
<sneek>Got it.
<efraim>sneek: botsnack
<mbakke>python2-flake8 has a whopping 1111 dependents. Ugh.
<mbakke>The alternative is changing a lot of the python2 variants to the "package-with-python2" style and add the delay property to their parents.
<civodul>mbakke: you mean there are python2-* packages not defined using 'package-with-python2'?
<mbakke>civodul: Sorry, I meant the (strip-python2-variant ...) syntax that's necessary to override inputs.
<civodul>hmm, ok
<civodul>is there a problem on core-updates with python2-flake8?
<mbakke>Many python2 packages that uses flake8 could not find enum34 until recently, but the fix ( 01af1e11a67466d5f6338bdb207ff99ef5cf094e ) triggers a rebuild of 1111 packages.
<mbakke>I did not notice until I tried building matplotlib and others..
<mbakke>Considering reverting it, but then we'll have to manually add enum34 to a lot of packages that requires flake8.
<civodul>right, maybe what you did was the right thing, after all
<civodul>these should be small packages, no?
<mbakke>Unfortunately, mesa is one of those.
<civodul>so yeah... maybe we need to revert
<civodul>i guess it's a matter of how tedious it would be to add enum34 everywhere it's needed
<civodul>are we talking about 10, 100, 1000 packages?
<civodul>i guess we don't know exactly?
<mbakke>Not a lot, probably <20. I'll revert it and add enum34 to those I know are affected.
<mbakke>I'm going away for a few days tomorrow, so will send an email about it to guix-devel.
<civodul>sounds good!
<civodul>in other news i *think* i have a workaround for the offload/select bug
<civodul>when we have that, hopefully berlin can work full-speed
<janneke>where does our kernel config file live?
<civodul>in gnu/packages/aux-files/linux-libre
<janneke>i fear that i'm lacking a setting/module for old hardware and want to check (and then possibly modify/enable)
<janneke>civodul: thanks!
<civodul>janneke: BTW rekado_ gave use an executive summary of the bootstrapping effort in the Guix workshop :-)
<dieggsy>huh, is "guix pull" not working at this time. i have a FAIL on dist.scm
<civodul>dieggsy: could you paste the command and its output?
<janneke>civodul: that's great, i heard you had some nice suggestions to start integrating #bootstrappable into guix
<civodul>yeah i think we can do a bit of "top-down" improvements at the same time as others think about the "bottom-up" approach
<civodul>eventually both will converge :-)
<janneke>rekado_ (and i) started already something in wip-boostrap, but still bottom-up; not top-down
<janneke>i like the top-down idea and meeting eachother halfway
<janneke>that's kind of what OriansJ and i have been doing with stage0 and mes too :-)
<dieggsy>civodul: huh, ran it a third time, seems to be fine now.
<janneke>hmm, everything disk seems to be enabled
<janneke>grub sees my hard disk as hd0, and ubuntu 13.04 sees it as sda (ubuntu 14.04 installer does not boot); guix 0.14 does not see /dev/sda -- hmm
<civodul>janneke: you mean the installation image doesn't see it?
<mbakke>civodul: shepherd has failed 16 times now on Hydra, any chance you could add the fixes to core-updates? :/
<efraim>U-boot worked, couldn't find grub
<janneke>civodul: i haven't succeeded yet in booting a guix installation image, i ran guix system init from within ubuntu 13.04, then i booted guix
<janneke>it cannot boot from usb, and i haven't succeeded in creating a dvd that it recognises
<DoublePlusGood23>How would a custom kernel with patches work under GuixSD?
<rekado_>DoublePlusGood23: it would work fine.
<DoublePlusGood23>rekado_: how would I go about it? Just hack around with the regular kernel expression?
<rekado_>DoublePlusGood23: you can create your own kernel package by inheriting from the existing linux-libre packages, and apply your patches there. Then in your GuixSD operating-system configuration you need to override the kernel field.
<DoublePlusGood23>rekado_: interesting. Are you aware of anyone who has done it prior?
<mbakke>dpg: There is a discussion here:
<mbakke>It doesn't include patches, but the approach is similar to any other package.
<mbakke>So along the lines of (source (inherit (package-source linux-libre) (patches "my-patches")))...
<rekado_>DoublePlusGood23: I’ve done this before to use a kernel with the realtime patches. It’s pretty straight-forward.
<DoublePlusGood23>mbakke: exactly what I was thinking of, thanks!
<DoublePlusGood23>rekado_: I figured guix would be up to the challenge :-)
<adamvy>this is my kernel package which adds a custom patch i needed to the standard linux-libre one
<adamvy>There's a bunch of extra #:use-module lines at the top, you don't need all of them, but I didn't want to share broken code :)
<adamvy>The patch file needs to be in the root of your $GUIX_PACKAGE_PATH directory
<DoublePlusGood23>adamvy: Thank you! That's much appreciated!
<DoublePlusGood23>adamvy: so guix is smart enough to apply patches? I just basically need to tell it what to apply?
<DoublePlusGood23>Yup, I can see how it works, lisp is great.
<DoublePlusGood23>I'll be attempting to get bcachefs to work if anyone else is interested let me know :-)
<pkill9>what's the best way to modify a package description in the modules that guix provides, in order to add a `replacement` field to one of the existing ones?"
<rekado_>pkill9: what’s the goal here? The replacement field is for grafts.
<pkill9>yeah for grafts
<pkill9>to replace mesa with proprietary nvidia drivers, not on GuixSD though
<rekado_>if you need to modify the sources of Guix itself it’s best to work on the sources and use your modified version of Guix.
<pkill9>so basically fork guix
<rekado_>that’s not a use-case for grafts.
<pkill9>what do you mean?
<rekado_>grafts are only for rewriting references in binaries. They are not meant to override packages with different features.
<rekado_>also, to replace a package with a variant throughout the package graph you can use “--with-input”, but either way you’ll end up building a lot of stuff.
<pkill9>the proprietary nvidia driver functions as a drop-in replacement of, and ideally i'd like to have all software that uses mesa to instead use the nvidia proprietary driver
<pkill9>without rebuilding it ofcourse, so is it not possible to just make all software reference the nvidia driver's libraries instead of mesa's?
<rekado_>I can’t help you with proprietary software. But it really seems like for that you wouldn’t use grafts but something crude like LD_PRELOAD or similar.
<pkill9>i do that curerntly
<pkill9>i was hoping i could do it without a wrapper tho
<rekado_>as I wrote, we can’t help you with problems you get from overriding binaries with LD_PRELOAD or LD_LIBRARY_PATH; especially when it’s proprietary software.
<pkill9>yes i know, and i'm not expecting anyone here to help me with problems resulting from overriding binaries, i was just asking how I could do that for myself
<ng0>the week has been not very good.. but taking breaks on work bc of life is sometimes good. I made a tiny step forwards with the vim-build-system. It almost builds now
<sneek>ng0, you have 2 messages.
<sneek>ng0, efraim says: I'll have to look at it again, for now I also have it mirrored at
<sneek>ng0, efraim says: I do have a preliminary dpkg package, but you can also unpack debs with 'ar'
<ng0>ah, didn't know about ar.
<ng0>I can't link to my dpkg definition here I think.. not sure which repository it's in, my guess is I put it in one of the nonfree ones.
<ng0>I've checked yours out and yours is much shorter than mine
<ng0>oh, it's in packages.. well that's okay here.
<ng0>very WIP
<ng0>nice. I think I can send something functional for vim tonight. t least for an rfc
<janneke>yay, i'm past initial ramdisk; added pata_via, pata_acpi, sata_via to initrd
<janneke>yay, got /etc juggling sorted out; now installed working guixsd in-place over ubuntu
<ng0>if I want .gitignore to be matched by an regexp, and "^[^/]*\\\\.gitignore$" or "^\\\\.gitignore$" doesn't work out, how do I match it then? just "^\\\\.gitignore$"?
<ng0>"to the repl mobile" I guess
<vagrantc>janneke: heya. curious how the progress with DDC compiler bootstrapping was going
<janneke>vagrantc: hey! gabor has made quite some progress, about a week ago he managed to create a gcc-4.7.4 package built with gcc and one with clang that are identical iirc
<janneke>indeed, great work
<ng0>I'll just delete it.
<ng0>one regexp less
<ng0>found the regexp out
<quiliro>how's everyone?
<quiliro>incredible that blender works well in guix with just a core2duo
<quiliro>i am trying to install an addon, checked its license: GPLv3
<quiliro>what else should i do to verify freedom?
<quiliro>sverchok is the name
<quiliro>when i tryed to install the addon, i got the message
<quiliro>ImportError: No module named ‘numpy’
<quiliro>so i installed numpy
<quiliro>and then i got error
<quiliro>ImportError: No module named ‘requests’
<quiliro>what to do?
<bavier`>quiliro: sounds like there are some dependencies you'll need to work through
<mbakke>quiliro: try installing python-requests?
<mbakke>Or even better, package the addon for guix :)
<quiliro>mbakke: i have been trying to fix openmolar package and cannot do it yet...i do not have enough knowledge...i can help with what i am told to do though
<quiliro>in the packaging of sverchok
<quiliro>mbakke: it was just that, install python-numpy and python-requests
<quiliro>it recognized sverchok
<mbakke>From the sverchok README it seems it expects numpy and requests to be distributed with Blender. Maybe they should be propagated?
<quiliro>mbakke: what does propagated mean?
<mbakke>quiliro: many Python packages have a field in their package definitions called (propagated-inputs ...). In practice it means those inputs are installed to your profile along with the package.
<mbakke>We generally try to avoid those, but don't have a better solution for Python.
<quiliro>mbakke: maybe it would be best to ask blender people if it is vital to include those 2 in blender always
<mbakke>quiliro: that would be great.
<mbakke>If you get a confirmation, please file a bug report (or patch) :)
<quiliro>mbakke: in #blender they say:
<quiliro>mbakke: <Yaniel> fwiw it works fine on nixos :3
<quiliro>mbakke: <bzztploink> official distro ships idna, chardet, urllib3, certifi, requests and numpy
<quiliro><Yaniel> especially on a distro with a readonly system
<quiliro><Yaniel> which isolates applications from each other
<mbakke>quiliro: I'm not in front of a "real" computer atm, but it sounds like propagating those may be good to propagate those. Can you file a bug report?
<mbakke>Uhm. Reundant sentence is redundant.
<mbakke>Maybe I should not be working with Guix from a pub in Prague.
<quiliro> right?
<mbakke>quiliro: correct.
<quiliro><Yaniel> looks like it doesn't [15:35]
<quiliro>*** efxlab ( has quit: Quit: Textual IRC
<quiliro> Client:
<quiliro><bzztploink> you're asking about all blenders dependencies we ship?
<quiliro><Yaniel> ah, the nixos package explicitly disables numpy at build time
<quiliro>will paste to the bug report
<mbakke>Oh, interesting.
<quiliro>subject should be: sverchok plugin for blender?
<mbakke>That will work. Or something along the lines of "additional inputs required for Blender plugins".
<mbakke>It would be great to have upstream documentation for this though.
<mbakke>As in hyperlinks.
<quiliro>mbakke: i am asking for them now
<mbakke>quiliro: But it would be best to package these addons for Guix. If you feel like a challenge :)
<mbakke>Then we can keep the main blender package minimal.
<quiliro>please tell me what to read in order to understand packaging because i have read some stuff but still do not understand...i get the idea but not the feel!
<quiliro>mbakke: the case sounds fairly simple....but i would like an easy example to copy!
<quiliro>i think i could pull it
<quiliro>or push it, in this case ;-)
<mbakke>quiliro: I don't know any better approach other than reading the manual and a lot of package definitions.
<quiliro>mbakke: would you please suggest a very simple package definition to start with?
<mbakke>quiliro: "hello" is the canonical example.
<mbakke>Blender plugins may be a little more involved. But don't worry, we can help you out in this channel :)
<quiliro>mbakke: cool!
<quiliro>that is the link i was given
<quiliro>it reports versions of
<quiliro>numpy, requests and others
<quiliro>set(REQUESTS_VERSION 2.18.4)
<quiliro>set(NUMPY_VERSION v1.13.1)
<quiliro>set(NUMPY_SHORT_VERSION 1.13)
<quiliro>set(NUMPY_HASH 2c3c0f4edf720c3a7b525dacc825b9ae)
<quiliro>i suppose those are the ones that the binary ships with
<mbakke>quiliro: I see. For some reason they are not required for building the Guix package:
<mbakke>I don't know enough about Blender to give a good suggestion. But I guess it's better to just package these plugins separately rather than propagating these (large) packages for every Blender user.
<mbakke>Please file a bug report, let's see what others say :)
<quiliro>mbakke: ok
<quiliro>they are not necessary to run is just that their binary ship with those plugins and their dependencies by default...we need not do the same...only include them when user asks
<ng0>so what do we do about's etc..? I seem to recall the emacs-build-system copies some unwanted files aswell, and I seem to be unable (for now) to exclude, *.md, etc and predict whatever unwanted file an even larger set of vim extensions could contain
<ng0>the vim-build-system, because Makefiles are rare there and an exception, copies all files into place
<ng0>I can't just say "copy all folders containing only .vim" because vim extensions use more than just .vim
<ng0>and I have no list of that either, can be .vader, .template, .yml, etc
<ng0>so for now I recursively delete .git and .gitignore in the folders and _try_ to exclude other files from install (it works moderately crappy)
<ng0>we'd get file collisions for "" etc in '/share/vim/vimfiles/' but I guess that's okay.
<ng0>I'm making a FIXME note in the build-system and will send it soon
<mbakke>ng0: could we automatically make a subfolder corresponding to the package nsme?
<ng0>and that would help us how?
<quiliro>sverchok addon dependency reported on bug-guix
<ng0>in vim as a vendor you get to throw whatever the extension gives you into /share/vim/vimfiles (or some other location) and then you add that to the vimpath (not an env var..)
<mbakke>ng0: it would alleviate all those conflicts.
<ng0>won't work
<ng0>as the folders are standard
<ng0>it's not just "mess of files" but folders with files in them that are expected
<ng0>(build one of the extensions, or look at vim.scm)
<ng0>unless you mean something else and I don't get you
<ng0>for a first version of a vim-build-system it's okay. it's a start.
<ng0>I'm adding some commits on top of it to give a proof of work