***Gamayun_ is now known as Gamayun
<Apteryx>why does system* accept empty args '() but invoke insists on strings? <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. <catonano>I do "guix environment guile" and then ./autogen.sh <catonano>I get: ./autogen.sh: riga 14: autoconf: comando non trovato <civodul>try "guix environment guile --ad-hoc autoconf automake libtool" <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 <catonano>clacke[m]: no, I want to work on guile itself <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 <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]>it simply explains why you needed more tools <catonano>clacke[m]: "if" I get past bootstrap ? :-) <mbakke>We still don't have a successful Shepherd build on Hydra for i686 and armhf. <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>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 git.flashner.co.il/cgit 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 <pch>just have a look at the snippet <catonano>rekado_: I just managed to install Guix on Fedora with your script. <Cthulhux>I am actually confused about the Guix distro: The package repository is awesome and still there's close to no media coverage. <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>but then I can't find your etc/gix-daemon.cil.in file ***danialbehzadi1 is now known as danialbehzadi
<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>Yep, I gave up on making a real Nick years ago <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_>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_>but it’s almost useless if you don’t have a Debian system. <ng0>yeah.. but extraction of .deb's it works <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: 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. <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: 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... <efraim>sneek: later tell ng0 I'll have to look at it again, for now I also have it mirrored at gitlab.com:Efraim/my-guix.git <efraim>sneek: later tell ng0 I do have a preliminary dpkg package, but you can also unpack debs with 'ar' <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>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 <mbakke>Unfortunately, mesa is one of those. <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? <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>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) <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 <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 <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. <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. <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: so guix is smart enough to apply patches? I just basically need to tell it what to apply? <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>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. <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 libGL.so, 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 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, efraim says: I'll have to look at it again, for now I also have it mirrored at gitlab.com:Efraim/my-guix.git <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>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 <ng0>I'll just delete it. <ng0>found the regexp out <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>when i tryed to install the addon, i got the message <quiliro>ImportError: No module named ‘numpy’ <quiliro>ImportError: No module named ‘requests’ <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>mbakke: it was just that, install python-numpy and python-requests <mbakke>From the sverchok README it seems it expects numpy and requests to be distributed with Blender. Maybe they should be propagated? <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>If you get a confirmation, please file a bug report (or patch) :) <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><Yaniel> looks like it doesn't [15:35] <quiliro>*** efxlab (~efxlab@244.178.134.77.rev.sfr.net) has quit: Quit: Textual IRC <quiliro><bzztploink> you're asking about all blenders dependencies we ship? <quiliro><Yaniel> ah, the nixos package explicitly disables numpy at build time <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>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! <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>set(NUMPY_HASH 2c3c0f4edf720c3a7b525dacc825b9ae) <quiliro>i suppose those are the ones that the binary ships with <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>they are not necessary to run blender...it 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 README.md'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 README.md, *.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 "README.md" 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 README.md conflicts. <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