<brendyn>OrangeShark: I've made a profile that's borked my underlying os a fair big xD. I tried just using environment to get everything required to build guix but It didn't work <janneke>do we have some sort of clone-package or clone-record thing? <janneke>to make a copy while overriding some fields <janneke>it seems that set-fields also works! <janneke>ehh, if you enter (use-modules (srfi srfi-9 gnu)) it in guile, it doesn't work in irc <brendyn>janneke: python packages use this funny drop procedure I've never used before to may python2 varians <janneke>is that to add a second source to the package? <janneke>no, probably -- Scheme Procedure: drop lst i <janneke> Return a list containing all but the first I elements of LST. <janneke>anyway, thanks brendyn! it's waaay too late here <brendyn>Right, that's why my geiser can't find it <brendyn>ACTION twiddles his thumbs until someone reviews his contribution ***lostcoff` is now known as lostcoffee
***lostcoff` is now known as lostcoffee
<paroneayea>I can't figure out why angband can't find ncurses <lostcoffee>is there a preference for .desktop files specifying a path to an executable (i.e. Exec=/gnu/store/.../bin/thing) versus .desktop files specifying an executable name (i.e. Exec=thing)? <davexunit>lostcoffee: always use an absolute file name <lostcoffee>could you maybe weigh in on the mailing list to that effect? <paroneayea>how have I never used the debbugs package sooner? <lfam>Too busy trying to figure out how to use the web page ;) <efraim>Wow, just read the opensuse build server config file for building EFL, more than 1200 lines <efraim>Including copyright headers ours is an order of magnitude smaller <efraim>Last night I grepped through my store for Cython, later today I'll start going through and make a list of packages that might need adjusting <efraim>Preliminary results from last night show numpy, pybedtools and python3 :/ <civodul>efraim: what's the problem with cython? <efraim>I'm just making sure we don't have "cythonized" sources <efraim>Python3 definitely a false alarm <efraim>Numpy and scikit-learn have a cythonize.py but I can't find evidence of it being used <civodul>do you mean that packages have a tendency to bundle cython? <civodul>(maybe i just missed something on the ML?) <efraim>I don't think they bundle cython, its more of they use cython to generate code <efraim>Borg had some, python-efl uses it a lot <civodul>ok, but it's not very different from flex/bison <efraim>If I understand it correctly it translates between python and C <civodul>so yes, bundling the generated C code is problematic <rekado>is anyone using wicd successfully to connect to 802.1x networks? <jmd>rekado: I'm not familiar the the terminology. 802.1x is a normal wifi protocol? <quigonjinn>I'm trying to build gcc for arm bare metal. The build process stops with an error, and after investigating with --keep-failed in /tmp , this error stops the build process: http://paste.lisp.org/display/325933 . I have set the environment-variable that guix outputs. <rekado>quigonjinn: yes. This can happen when the build process tries to write somewhere outside its own output directory. <rekado>quigonjinn: in that case you’d have to check that the target directories are all correct. <rekado>I just built a first working version of Extempore (a musical Scheme) <quigonjinn>target directory is gcc-drv-1/build/gcc/build. -o build/denmddeps is a relative path anyway. Is there a chance this is not the same error why my build process fails? because I reproduce this in /tmp <jmd>rekado: Anyway wicd works for me. <civodul>rekado: what problems do you have with wicd? <rekado>civodul: I cannot connect to the campus wireless network. I get this error: <rekado>deauthenticated from ca:fe:ba:be:e7:61 (Reason: 23=IEEE8021X_FAILED) <rekado>wicd works for me on all other networks, but with 802.1x it fails <rekado>civodul: I tried eduroam, but I’m not sure how to make this work. I don’t have any cert file that I could use. <rekado>but it’s good to know it should work. Will check with IT. <rekado>I have *never* used eduroam before. <rekado>I think that via eduroam I cannot get access to the intranet here. <brendyn>My settings are PEAP with GTC, and my user name is my email address, not just my username <brendyn>How can I make Emacs' M-q keep two spaces after .? <efraim>i made a package for x265 but i'm not happy with it <rekado>brendyn: it does for me. Did you override “sentence-end-double-space”? <civodul>rekado: eduroam has the advantage of being available in all the academic institutes in Europe, maybe elsewhere too <rekado>civodul: yes, but I really need to be able to access the servers here :) <efraim>re x265: at compile time it sees the cpu capabilities, so it seems like it should be built locally <efraim>according to debian, its an input for ffmpeg, vlc, gst-plugins-bad and handbrake <civodul>rekado: one case where i had to resort to raw wpa_supplicant is for a network that uses: proto=WPA key_mgmt=WPA-PSK pairwise=CCMP TKIP <civodul>i think wicd doesn't have a template for that one <janneke>civodul: re hyda: i got it to run, but not succeed/build hydra/gnu-system.scm <janneke>i'll send a new patch set...but i'm now looking at/working on cuirass and would like to stop giving attention to hydra for now <civodul>janneke: apologies if i sent the wrong message! <civodul>i think longer term Cuirass is the better approach, but it's not quite ready either <janneke>civodul: i'm not sure you did, but i'm happy to have seen something about hydra and am all the more inspired to help Cuirass ;-) <efraim>if I want to make sure something is only built on the machine it's going to be run on, is #:substitutable? #f enough? <efraim>or will that still allow offloading <dvc>efraim: Are you looking for guix build --no-build-hook? <efraim>no, for inside a package definition <efraim>i have substitutable? #f, but I thought there was a second option to toggle also <dvc>I think there is something called prefer-local or similar <dvc>it's set in gexp->derivation <dvc>don't know if packages can make use of it <efraim>perhaps, but it may only be substitutable <efraim>Atlas in maths.scm is similar in tuning to the host's CPU and it only has substitutable <dvc>efraim: Can you disable the cpu tuning? I don't think that packages should do that, and if someone uses offloading the binary will end up optimized for the wrong cpu <dvc>efraim: I don't think that cpu optimization works, since it probably uses /proc/cpuinfo right? Is that available in a container? <efraim>I can search the code, don't know what other distros do since they package it <efraim>We do have our minimum target for architectures so I could try to hardwire that <adfeno>Does any of you know if our python2-twisted recipe includes the "tls" extra? <adfeno>I'm trying to make some Guix recipes, but some of them require Python Twisted's "tls" extra. <adfeno>Don't worry... I was just trying to get the information without having to dive into the package definitions. :D ***piyo` is now known as piyo
<adfeno>What is our standard if a project's name has an underscore instead of an hifen? <brendyn>Delete the project and rewrite it in guile <adfeno>I.e.: there is Python PyPI package called "service_identity", so we must use "python-service-identity"? <adfeno>brendyn: That's the best option. :D <davexunit>we adhere to our standards pretty well around here <adfeno>If we need to convert underscores to hifens, then I guess we have to fix u-boot-vexpress_ca9x4 <brendyn>What about python-backports.functools_lru_cache <adfeno>davexunit: Oh... sorry, I mistyped. <adfeno>I didn't mean to sound offensive. <davexunit>'guix import pypi' says 'python-backports.functools-lru-cache' <davexunit>generally we don't want a mix of underscores and hyphens in names <adfeno>Yup... Available in all keyboard layouts. <davexunit>and hyphens instead of underscores is a long established lisp convention <adfeno>Also, what is your recomendation on indentation style? Should package recipes use tabs, one space, or two spaces? <davexunit>how many spaces depends on the pretty printing rules <davexunit>and we have extra files that emacs reads to learn about indentation rules for special forms that guix adds <dvc>adfeno: first too lazy to read package definitions and then complaining about my code? =P <adfeno>I'm sorry, but I can't understand your last message. <dvc>the u-boot package underscore... <adfeno>I wasn't complaining (that is: complaining offensively), it was just a suggestion. :D <civodul>we have a tradition of nitpicking so we ended up writing everything down :-) <civodul>normally 'guix import pypi' implements the Right Rules <quigonjinn>Is (#:parallel-build? #f) supposed to make gnu-build-system use -j1 instead of -jX when invoking make? <lfam>quigonjinn: I don't know the mechanism, but that is the intended effect <lfam>Similarly for #:parallel-tests? <lfam>Hm, I'm testing Danny's ldc patch from guix-devel. I used --dry-run to see what would happen, and it appears that 5 different copies of the source code will be downloaded. 4 gzip, 1 xz. And two different version number styles. <civodul>technically, #:parallel-build? #f replaces "-jN" with nothing, not with "-j1" <lfam>Perhaps they won't all be downloaded, but they will at least be built <quigonjinn>I'm trying to find the correct way to change only that variable, from an inherited package definition, but failing so far. I'm trying something like: http://paste.lisp.org/+6ZIA . There's probably some horrible mistake there :) <lfam>I see, there are different files with the same name <lfam>The URLs are differentiated further "up" the path <lfam>We should give them descriptive file-names <lfam>Well, I will do that in a follow-up commit <civodul>quigonjinn: should be "#f" instead of "`(list #f)" <quigonjinn>I changed that, but still, while the package is building, a make -j12 ... appears in htop (from a guixbuild user) <civodul>note that it's easier to run "guix build something --cores=1" <civodul>and the advantage is that this doesn't change the output hash <civodul>i think that's what you want to use here :-) <dvc>civodul: I'm doubting that make-linux-libre-source was such a good idea... Do you think it's better to leave it as it is and pass the hash? <lfam>quigonjinn: Following on what civodul said about the mechanism behind #:parallel-builds?, I guess the package's build scripts are setting the -j value. <lfam>You could try patching it out if it causes build failures, but if you just want to keep your machine running smoothly, passing --cores=1 to `guix build` is best <lfam>And, you can pass --cores is a "common build option", so you can pass it to any Guix command that builds stuff. See the manual for more about common build options <lfam>Forget that first "you can pass" :p <quigonjinn>lfam: I'm trying that at the moment. I should note that if I pass --fallback, and then enter the build directory, in a guix environment for that package and run: "make distclean", and then "configure" with the flags my guix package imposes, and "make" with no flags, the package builds. <lfam>1/662 Test #1: build-druntime-ldc-unittest ................. Passed 46.97 sec <lfam>I guess this will take a while... <quigonjinn>An update on arm-none-eabi-gcc. A second error was found, because flex was a needed build-time dependency. I seems to build now with --cores=1, I'll try without it if it succeeds. <ng0>an update on ghc 8: i will punch it in the face. on a more serious note, I need to inhale search engines currently to figure out the ncurses5/6 problem with it. <lfam>3/662 Test #3: build-phobos2-ldc-unittest .................. Passed 769.73 sec <lfam>Yay, only 659 more to go! <ng0>what are you building? the tower of babel? <janneke>i'm wondering...would it be possible/sensible to have guix system reconfigure update /etc/config.scm so that it always has the current definition? <ng0>isn't that the reverse of what's now? you update config.scm or whatever you chose to call it and then run system reconfigure <lfam>janneke: What do you mean? Update config.scm to the current version of what? <janneke>the manual tells us to put config.scm in /mnt/etc/config.scm <janneke>although i have a copy in a git archive, i fail to keep track of which config matches which generation <janneke>and i noticed that my /etc/config.scm is a very old one <janneke>i'm wondering how you all feel about your old, initial /etc/config.scm <lfam>I think that location is just a suggestion. You can put the file anywhere, really <lfam>I actually reconfigure straight from my Git repo <janneke>lfam: me too...so my /etc/config.scm just sits there <lfam>I think you can delete that file :) <janneke>maybe we should /not/ suggest to put it there <lfam>I tried to use Git branches to provide different types of systems but with the same lfam-specific changes across the types. For example, a console branch, a graphical branch, etc <ng0>where else wolod you document to put it? <lfam>In practice it hasn't worked that well. <lfam>Too much work rebase my "me" stuff on top of the different branches <lfam>But, I still have hope that I can figure out how to do it properly :) <janneke>ng0: i'm not sure, but if you follow the manual, you'll have a stale /etc/config.cm file...that's kinda silly too? <janneke>having it there suggests to me that it is updated automagically <lfam>janneke: This is the first time I've seen somebody ask this question. I think that if we didn't suggest a location, we would be asked where the put the file, constantly :) <ng0>you are free to edit it afterwards.. which is what I do. the documentation can be improved. <OrangeShark>the manual can maybe say you can store the config anywhere, but /etc/config.scm being the easiest place when starting out? <lfam>OrangeShark offers a good compromise, in my opinion <janneke>i just stumbled across it when working on rottlog and writing in /etc <davexunit>I have it in a git repo in my home directory <lfam>Heh, you don't even have to put the file anywhere on the new system. You might be annoyed later on, but it's not necessary :) <lfam>I learned that the hard way! <OrangeShark>davexunit: but in the initial install there is no home directory <davexunit>OrangeShark: that's a different story, yeah. <janneke>yes, for the initial install it's quite nice to be able to lift it from /etc/config.scm into git <lfam>Or `git clone` from a remote machine <davexunit>the initial install should just be a barebones system anyway <lfam>Or from a USB storage, etc <davexunit>or just stuff the config in /etc on the new partition <lfam>Yes, the initial install should be the simplest thing that could work. But everybody seems to want to do a full triple DE system right off the bat <janneke>i just sort of like the idea that when you revert to a previous generation (possbly because the latest is broken), you know for sure what the config.scm was <lfam>Well, we get it because we have some experience. New users don't get why it's better to start bare-bones <davexunit>janneke: but the config.scm is only a small piece of the puzzle <janneke>even if you have been sloppy with git <janneke>davexunit: ah...it's also the guix commit of course <lfam>New users don't think about the possibility of network failures, package build failures, hash mismatches on a mirror, etc <davexunit>OS config -> installed OS is a *one way* transformation <davexunit>lfam: I think we should change the manual to strongly encourage using a pre-made, simple config and make minimal changes like the hostname and stuff <lfam>And I hate to recommend to a new user who is having trouble with their desktop system installation "Why don't you try re-writing your OS config?" <davexunit>once you've bootstrapped yourself, experimentation is dirt cheap <davexunit>you just need to get past that first install <lfam>davexunit: That, or identify and mitigate common failures in system initialization <lfam>Your suggestion is easier <davexunit>people make too many mistakes that we could never catch <ng0>microcom... is that related to the old COM? <lfam>I think it could be improved! Some of the failures are not the users' fault <davexunit>of course, we should fix whatever bugs are there <davexunit>but I think recommending that new users just use something pre-made as a bootstrapping step will be useful regardless <lfam>I suspect we still have the nscd bug in the installer image, but I haven't tried reproducing it for a while <lfam>Yes, I agree we should edit the manual to suggest users start with the bare-bones system <davexunit>I want to do things like remote guixsd installations on bare metal <lfam>I see in the Git log "gnu: Add u-boot-beagle-bone-black." <ng0>I/we want to deliver a range of live-system with pre-configured guix/nix and our applications..I excuse in advance (though it's some time until we get there) for users reporting in who have not read the details. <lfam>ng0: A flood of users who have not read the manual is a "good problem" :) <lfam>I think it would be cool to have a VPS service where users can upload a config.scm and a Guix Git commit, and get a virtual server <ng0>beaglebone black.. yesterday i thought about how things like ulisp could be packaged if at all necessary. <lfam>I think my idea would need some implementation of a shared store between the virtual machines <lfam>janneke: I don't understand why perl-net-statsd should go in (gnu packages ci) <janneke>lfam: it's part of `resurrect hydra' -- noone else needs it <ng0>but it's a perl module.. some day someone might need it. <janneke>likewise libpgxx could go into `databases.scm' -- but it seems obsolete <dvc>Is anyone against moving module-init-tools and libnfsidmap from the kernel section to the end of the file? I think it disturbs the flow of reading the linux-libre packages. Does this have to be two separate commits even if they are adjacent to each other? <janneke>sure, i'm quite open for suggestion, i also had doubts. <efraim>grep define-public gnu/packages/*scm makes me want to tear python.scm into many many pieces <lfam>janneke: The lazy choice (that is, what I would have done) would be to use (gnu packages perl) <ng0>working on reddit+searx+kallithea and everytime i need to add something python i feel the same. <lfam>Moving packages around is really a pain. You have to move all the copyright statements (or duplicate them, depending), fix all the module imports, etc <dvc>inside the same file... so none of that <janneke>i was just thinking: when we declare hydra obsolete, we can simply junk them all together <dvc>the module-init-tools is deprecated <dvc>and libnfsidmap should have never been placed in the *kernel section* of the file (30 August) <lfam>I was thinking of the idea of breaking up python.scm. I don't think we should do it. <efraim>dvc: I looked again at debian's x265, they just don't use yasm at all, so no hardware enablement but still makes x265 available <ng0>but why make the perl module obsolete which might still be considered useful by someone who writes scripts in perl? shouldn't it be just hydra then? <efraim>nix uses yasm, don't know how they make it machine-specific though <janneke>ng0: i'm a big fan of dropping garbage...and possibly i'm too extreme in that <janneke>having something around because 'it might be useful some day' makes you slow <efraim>it doesn't come up that often that something that was removed gets re-added <ng0> i don't think so.. people who need it, update it. it's awful if you have to repeat work because you deleted it 5 years ago and then you run into something where you need the package again. <janneke>ng0: yes, i can imagine. i never experienced that, though. i experience people carrying garbage around every day. <ng0>there's lots of modules in python i just need to add because i want to add 3 applications. <janneke>i had to add 318 npm packages just because we depended on 40 <janneke>makes me really want to drop node and move to guile even more <rekado>I’m surprised to see that the GSM modem in my Thinkpad actually works with Linux libre. <ng0>systems get attractive by having a variety of applications available. we should have some kind of drop policy then.. for me it would be serious security issues which are unlikely to get patched and no package depends on it <rekado>it’s a little inconvenient to set up. <efraim>on the other hand, if no one uses it then it matters less that it doesn't get updated, more that it continually gets built in the build farm <rekado>before “ip link set … up” I need to run ppp’s “chat” to bring the SIM card into an active state. I wonder if this could be automated with a service. <lfam>ng0: I agree. The old packages can always be found in the Git log if somebody really wants them <janneke>ng0: yes, i agree with that. one of the big selling points of debian, it has/had amost everything <rekado>lfam: I’m also of the opinion that python.scm should not be broken apart. <efraim>on debian I'd go with cron's @reboot <efraim>or a systemd.unitfile with a depends on networking <efraim>so there must be something similar you can do with a service <dvc>efraim: so are you adding yasm as an input? if not adding it solves the problem... <dvc>or isn't there a problem? <dvc>didn't quite understand what you were trying to say... <efraim>x265 uses yasm to determine your cpu's capabilities <efraim>so if I just leave it out with a note then it just won't find anything <efraim>I'll probably add ffmpeg-custom to my GUIX_PACKAGE_PATH built with x265 with yasm <lfam>efraim: Does it make a really big difference in performance? <efraim>i'm not sure, but my computer could use just about any boost I can get <efraim>it makes me also want to check out libx264 and see if it has the same thing <lfam>Do we have any packages that we don't substitute for this reason? <lfam>I recently fixed this issue in ImageMagick <efraim>we do substitute packages that depend on it <efraim>not sure how ffmpeg built with x265 with yasm would fare on a different machine <lfam>I asked about x265 performance because, if it makes a big difference, maybe we should make it build on the user's machine instead of substituting it <lfam>Is the x265 compilation really heavy? <lfam>Why... why... does Hydra depend on a Perl binding for ImageMagick? <lfam>Is our Hydra installation using an updated ImageMagick? <lfam>Is there any method for a user to upload an image file to hydra.gnu.org? <ng0>I can't really break the system profile when I don't break the bootmanager right. i feel like the gnunet-service is functional but I getting a vm which is growable takes time.. system is faster. <lfam>janneke: I will also move libpqxx to databases.scm <efraim>our libx264 doesn't produce an x264 binary? <lfam>efraim: I'm not familiar with this stuff, but wouldn't a library be all that is needed? <efraim>for inclusion in ffmpeg a library is all thats needed, but it can be called on its own <janneke>lfam: re ImageMagick: I haven't verified if it's (still) needed, or if it should or should not be updated... <lfam>ImageMagick is up to date in our package tree, but I'm wondering about the software running on hydra.gnu.org, and if it's possible for someone to actually run ImageMagick code on hydra.gnu.org from the internet. A bit unsettling... <lfam>I don't know Hydra very well yet, but I haven't noticed many pictures on the site <janneke>i'm afraid hydra.gnu.org might not be all that up to date, should ask civodul <lfam>Well, I'm building your Hydra patches now. I will look around once its built <davexunit>exciting. I'm hoping this could unlock a whole new generation of hardware for libreboot. <lfam>Who knows, it could turn out to be nothing. But if not it would be the newest common CPU without that garbage <efraim>actually, about x265, if its ok to substitute packages that use atlas as an input it should be ok for x265 also <efraim>the hardware specific stuff should just be in the x265 binary <lfam>efraim: Interesting, not in the library? <lfam>davexunit: Yes! But we still need hardware that we don't have to fight with for years just to fully control :) <efraim>i'll have to look, but i don't think it should affect the library <davexunit>but being able to use hardware that already exists is a nice bonus <lfam>Yes. Plus, the x230 is a nice machine in general, and not very expensive at this point. <davexunit>I'd like to be able to run libreboot on my x220 some day <lfam>Yeah, that machine will last forever! <lfam>Hm, I bet the reason there are test failures in perl-image-magick is that it wants an older version of ImageMagick. <lfam>The 6.8.9 series is still maintained. I'll try that <davexunit>ah, so this is why thinkpads have intel wifi chips and won't let you replace them <lfam>Oh, I'm wrong. The 6.8.9 series is not maintained. I mistook the recently timestamped signatures for release tarbals <lfam>davexunit: What I don't understand is, does it need a wifi network that doesn't require a password? <davexunit>lfam: if the running OS connects with a password, can it inject packets at that point? <davexunit>I'm afraid I'm completely ignorant about this stuff <lfam>If I knew how it worked, I'd leak the signing keys ;) <davexunit>I can't believe that key hasn't leaked, honestly <davexunit>dvd, blu ray encryption keys have leaked, and many other master keys <lfam>My neighbour moved away to work for Intel on photolithography. I tried to convince him to do that :) <lfam>But, "different department" <ng0>related to bluray: bluray backups with the tools available for GNU system was difficult 3 years ago.. I used what was available on doom9 for windows. <davexunit>ACTION sees the Ring patch set on guix-devel <davexunit>but I sure hope it gets cleaned up and makes it in <lfam>I don't archive patch emails until they have been dealt with <bavier1>looked at the first patch just now; a lot going on there <davexunit>yeah it's not a trivial patch series that's for sure <ng0>is someone really impatient waiting for ghc 8? I could then publish the latest build log in addition to the branch which can be seen on my gitlab project. I'll figure the problem out eventually, but maybe someone encountered this before with the previous haskell generation and has *the idea* how to beat it? <quigonjinn>What's the elegant way to export an anvironmental variable before a build phase in a package definition? <quigonjinn>ng0: so I should add a hook before that phase with that, right? <ng0>typing takes me to long you could grep for setenv, which returns among other results some in gnunet.scm for package (gnunet). <lfam>Yes, you can learn a lot with grep :) <ng0>just finding non-obvious stuff is hard with grep <quigonjinn>thanks, in fact i grepped before you answered, shouldn't have asked in the first place <ng0> /me builds rust to review :) good to see progress i don't need to make myself <lfam>No worries, we're happy to help :) But you will learn faster if you try for a few minutes before asking <lfam>Should the phase 'bootstrap-gen-and-test' put the (zero? ...) and the (install-file ...) in (and)? <lfam>I'm wondering how to make it fail if zero? fails <lfam>Or, if it will do that as-is <ng0>oh.. i think this should be rewritten that way.. i forget to use (and) <lfam>ng0: I'm not totally sure, as a new Schemer... <lfam>ng0: The only change I was thinking of is to make 'patch-makefile' return #t, since substitute* does not specify a return value <lfam>I mean, the only other change <lfam>Also, using #:tests? #f instead of (delete 'check). Okay, a few changes :) <lfam>Could you look into it and send a new patch if necessary? I must go AFK soon <ng0>wei... right there is #:tests? #f ... i think there are many packages which just do delete and I just use it everytime. i'll fix it. thanksfor looking into it. <ng0>s/everytime/ocasionally <ng0>eh.. i should've build this changed patch <lfam>ng0: This is funny: "Just to give you a rough idea" in the perl-net-psyc Makefile <ng0>well the makefile is only used to generate documentation at this point.. there used to be one, now this is just used for this. I will improve the system in the future. <ng0>femtolisp works. didn't see that you pushed the lispf4 patch, so sorry for pushing that appended. <dvc>has anyone else had problems with openldap? or was I just imagining that? <lfam>dvc: I saw people complaining in the IRC logs, but we have substitutes for all our architectures <lfam>Are you having a problem with it? <dvc>when running guix environment guix I got a build failure for openldap <dvc>as ludo pointed out openldap isn't a dependency of guix <dvc>so I'm trying to reproduce it again... <dvc>a test failure I think - but it was late ***abbe is now known as Guest22211
<dvc>ng0: rustc is missing llvm as a dependency --llvm-root should be passed <dvc>but I think the issue is (gcc (assoc-ref inputs "gcc")) should be toolchain <dvc>lfam: I'm trying again, it'll take a while - I'm building libarchive now - but there seems to be a substitute for that too <lfam>dvc: I don't think you should need to build libarchive... <dvc>oh, that's not a dependency either <lfam>I would restart with --dry-run to see what Guix plans to do :) <lfam>Are you sure you don't have some change to a core package in your source tree? <dvc>just checking that - checked out the new master <dvc>environment variable `GUIX_LOCPATH' set to `/gnu/store/1a20mvkkfqzix7ssim7gky4p8x2072lc-glibc-utf8-locales-2.22/lib/locale' <dvc>find-files: /gnu/store/g03wn5fzfwrln53llpbspq7l7qq1y9dr-libarchive-3.1.2.tar.xz/xml: Not a directory <dvc>find-files: /gnu/store/ikv4qncg040bf0zrm4vbjh1paa2bw8sz-tar-1.28/xml: No such file or directory <dvc>find-files: /gnu/store/1j8abqrx0kjj0rm7p18r84zd9spldhpi-gzip-1.6/xml: No such file or directory <dvc>find-files: /gnu/store/brcrwvzlrjn2ryvp4bkayk4w9plbcq6p-bzip2-1.0.6/xml: No such file or directory <dvc>find-files: /gnu/store/n1y6mhr78nxrglq1x7cvcd08gqvvvlik-xz-5.2.2/xml: No such file or directory <dvc>when I run guix environment guix --dry-run it immediately starts building libarchive <lfam>--dry-run implies --no-grafts now <lfam>Could be an old build, who knows? <lfam>dvc: What command gives you those find-files errors? <lfam>The environment command? <dvc>yes, just before building libarchive <civodul>are these warnings about xml/ directories? <lfam>Is your `guix` linked to your source tree, or is from `guix pull`? <efraim> ?: 0 [#f "x86_64" #:variant "4.7"] <efraim>i'll make-clean and see if that fixes it <dvc>oh, that doesn't look good <dvc>but I just build a kernel, it must be a typo <dvc>efraim: what did you do to get the error? <efraim>./pre-inst-env guix system build guix-testvm.scm <dvc>ah that could be an untested codepath <lfam>dvc: Is it really 0.10.0? We might not have substitutes anymore <dvc>ah no don't get the error <dvc>ah I meant to efraim <dvc>I'm updating the guix on bbb <dvc>you are only doing build not vm, don't need qemu <dvc>i don't get the error <dvc>must be some sort of caching <dvc>efraim: do you still get it after make clean? <dvc>do you use the linux-libre package or a different one? <lfam>Old .go files can hang around if the module they represented was renamed or removed. <efraim>sorry, I think it was with ./pre-inst-env guix package -A pyqt <ng0>should I send an updated patch for femtolisp again? i see it has been applied while I worked on a fix.. <dvc>i installed hello and did --check hello to compile from source - no error <lfam>ng0: I didn't realize it needed another fix. Go ahead and send your changes if it needs more work <efraim>i'll make clean-go and make sure I don't have any .go files around <ng0>well ricardo commented on it. <lfam>I did `make clean-go && rm gnu/packages/*.go` the other day. There were ~1 dozen modules left <efraim>gnu/system/linux.go i'm sure was the problem this time :) <lfam>ng0: Okay, better listen to him :) <dvc>efraim: good, I "nervous" when someone tells me my commits broke something =P <ng0>also, why is is commited with let and not let* ?I thought let* is for multiple items. <efraim>i've broken a bunch of stuff before too :) <davexunit>ng0: both let and let* handle multiple items <ng0>okay, I will read up on it then <davexunit>let* allows you to reference names defined in the forms above <davexunit>let binds all the names at once, let* binds sequentially <ng0>ah. thanks for the explanation <davexunit>one way to implement let* is by nesting lets <davexunit>and indeed that's a good way to think about what is happening <davexunit>and you can think of (let ((x 1) (y 2)) (+ x y)) as shorthand for this equivalent lambda expression ((lambda (x y) (+ x y)) 1 2) <davexunit>the lambda expression should make it clear why the definition of 'y' can't refer to the value of 'x' <efraim>dvc: i'm still getting the backtrace with guix package -A foo <dvc>looking into it, just broke my install using make clean - no daemon... <janneke>is there a function to print a package as an sexp? <janneke>hmm, emacs/guix-main.scm has package->sexp <dvc>efraim: I still can't reproduce the issue :/ <dvc>is someone else having this problem? <efraim>do the arm kernel configs need a configuration-file? <dvc>I reverted my make-linux-libre-source <dvc>I still need an if clause there <dvc>efraim: Is fixed - thanks! guix package -A seems like a nice safety check... <dvc>ng0: did the toolchain thing fix the rustc build issue? <ng0>i don't know, haven't looked at the emails. <dvc>I wrote on IRC not per email <dvc>replace "gcc" with "gcc-toolchain" basically <ng0>'t see it when people write me PMs <dvc>can you write PMs? I just wrote it on this channel <dvc>need to read the IRC handbook =P <ng0>I don't monitor the irc channel closely either. <ng0>seems like you can't use gcc-toolchain this way. <ng0>sneek: later tell dvc: I thought when you wrote about the toolchain, that there was a reference I did not see.