<ecbrown>i have a question about channels: how does one reference a "personal branch" in guile code, esp. with regards to loading a module? <ecbrown>in the "old model" i can make e.g. gnu/packages/openblas64.scm and see it as (gnu packages openblas64) <ecbrown>but what would i do with channels? for example, i want my openmolcas to load the openblas64. (openblas64.git has a single file called openblas64.scm with a single package defining openblas64) <ecbrown>I would be inclined to think #:use-module (openblas64 openblas64) <ecbrown>perhaps more succinctly asked: how do i load a module defined in the (name 'openblas64) channel, with a (url "..../openblas64.git") where the filename containing the definition is openblas64.scm? (and how would i defined the module name) <lfam>ecbrown: You're more likely to get an answer on <help-guix@gnu.org>, since the author of 'channels' is gone for the night <ecbrown>lfam: thanks, yeah, i saw him leave as i was writing.. :-( <lfam>The rest of us may need a day or two to get up to speed :) <emacsomancer>in a guix package.scm how do I pass additional arguments to make? E.g. I want it to build with "make foobar" rather than just "make" <nckx>emacsomancer: As in 'make <the target foobar>', or 'make FOO[=bar] <all targets>'? <nckx>For the former, use #:make-flags (list "FOO=bar"), for the latter #:phases (modify-phases %standard-phases (replace 'build (lambda _ (invoke "make" "foobar")))). Both in (arguments ...). <nckx>Or other way around if you want to be all 'correct' about it. *nckx distracted as usual <emacsomancer>nckx: the former, I think. In other, if one were installing manually in the terminal, rather than typing "make", to type "make foobar" *nckx got disconnected at the best possible time š <nckx>emacsomancer: Yup, you'd replace the build phase as above. (There's no #:build-target key, if you were wondering :-) <emacsomancer>nckx: I don't think I understand guix package builds well enough yet to have been wondering about the lack of a #:build-target key <nckx>emacsomancer: Ah. I was referring to the fact that there's a #:test-target that does what you're asking, but only for tests. There's no equivalent for builds or installs. ***daviid is now known as Guest30187
***Guest30187 is now known as daviid
<ecbrown>^--- is this a familiar error message to anyone? <ecbrown>i know there was some guile-gcrypt done <mange>Yeah, I assume that would be related to guile-gcrypt being a new dependency for guix. <rekado>the bootstrap binaries for i586-gnu can no longer be built on the master branch. <rekado>I suppose we should be using glibc 2.28 anyway ***bnw01 is now known as bnw
<efraim>i heard the Hurd and Linux glibcs were converging <roptat>efraim: I tried to package emojicode at some point <roptat>I don't remember what went wrong though <efraim>I'm not sure if the package works, it was too absurd to leave alone though <roptat>I think it was an issue with include paths <rekado>efraim: yes, with glibc 2.28 most of the extra hurd patches are no longer needed AFAIK ***Piece_Maker is now known as Acou_Bass
***ChanServ sets mode: +o rekado
***rekado changes topic to 'GNU Guix | https://gnu.org/s/guix/ | 0.15.0 is out! https://gnu.org/s/guix/blog/2018/gnu-guix-and-guixsd-0.15.0-released | videos: https://gnu.org/s/guix/blog/tags/talks/ | bugs and patches: https://issues.guix.info/ | paste: https://paste.debian.net | Guix in high-performance computing: https://hpc.guixsd.org | This channel is logged: https://bayfront.guixsd.org/.well-known/logs/'
***rekado sets mode: -o rekado
<roptat>if everything goes well, I should be able to download a simple torrent by the end of the week :) <roptat>it's hard to find legal torrent with a single file and a simple tracker (I don't support any extension yet), but I found that the ubuntu iso torrent works pretty well <efraim>How are you 'feeding it'? Just the hash? <civodul>we have evaluation errors on hydra and berlin due to the guile-gcrypt switch :-/ <civodul>snape: an i right that an evaluation always gets its inputs in its load path now? <roptat>efraim: for now, I use a .torrent file <roptat>and I only get more peers from trackers, without the scrape extension <roptat>I have all the necessary low-level functions for that, but I need to work on "orchestration" (if the word makes sense) <roptat>then I plan to add encryption capabilities, better tracker management, peer exchange and the dht <roptat>but I really want to have something working quickly even if it doesn't have a lot of features for now <roptat>the plan for integration is to extend the narinfo to include the hashinfo for the torrent, and then use it with the dht to find peers having that same file <roptat>because we have reproducibility, peers don't need to cooperate with hydra (so the torrent download is not a mirror of hydra: anyone can build the torrent independently and get the same hash) <snape>civodul: only the inputs listed in 'load-path-inputs' are in the load-path. Berlin only has one input per spec, and it is listed there, so yes. <roptat>but right now it's only a dream :) <civodul>snape: so i think the evaluation error on berlin for guix-modular-master is because its load path must be kept unchanged; we must not add "guix-modular-master" there *rekado updates all R packages <snape>civodul: the error has nothing to do with guix modular <snape>the same error happens with the other specs <civodul>build-aux/hydra/guix-modular.scm is meant to use whatever Guix modules are available, any version <civodul>from that it creates a "trampoline" (the same as 'guix pull'), which in turn computes the final derivation using the latest Guix modules <civodul>it's specifically design to not rely on the current modules <civodul>thus it can "resist" changes like when a new dependency is introduced <civodul>the mistake we made was to add "guix-modular" to its load_path_inputs <civodul>conversely, gnu-system.scm uses the latest modules, which means that it now requires guile-gcrypt, which is missing <civodul>i'll update the guix package and reconfigure to address that <snape>civodul: wouldn't the 'guix package' fix fix 'guix-modular' too? <snape>"i'll update the guix package" <snape>I meant the guix package update <snape>civodul: my point is that a fix that would work only for guix-modular.scm and not for gnu-system.scm is hackish. The property you talked about (guix-modular.scm meant to use whatever Guix modules are available) isn't useful in the context of Cuirass because we need to update the modules anyway for other specifications <snape>I don't think the errors comes from the Guix package. Rather from (guix store) being primitive-evaled by bin/evaluate <snape>so maybe we need guile-gcrypt to be a dependency of Cuirass <snape>civodul: I added (gcrypt hash) as a required module of bin/evaluate.in and now it works <snape>(and I didn't change guix modular inputs) <civodul>snape: we should avoid such hacks IMO, because it can hide real issues <civodul>because if bin/evaluate pre-populates the module name space, then we can have bad surprises <civodul>snape: so i'm trying to update the 'guix' package, which 'cuirass' depends on, and so cuirass will automatically have guile-gcrypt in its environment <rekado>Iām trying to build the Hurd bootstrap tarballs with āguix build --target=i586-pc-gnu bootstrap-tarballsā ā is āi586-pc-gnuā the correct triplet? <rekado>glibc-hurd-headers-cross-i586-pc-gnu-2.23.drv fails with āHurd headers not installed or too oldā <civodul>there's apparently some Hurd breakage on master, but i think we should focus on core-updates where we have glibc 2.28 <snape>civodul: I agree, but I'm not the one who wrote the (guix store) code :-D <rekado>Iāll try fixing this on core-updates then. <snape>And I've no idea about how to clean it <civodul>snape: i'm not sure (guix store) needs "cleaning"; what makes you say so? <civodul>perhaps i miscommunicated the issue :-) <snape>I was talking about the part in Cuirass that loads (guix store), not about (guix store) itself <civodul>rekado: problem is, on core-updates, we should drop or adjust glibc/hurd to use glibc 2.28 <snape>I thought that was what you meant by "hack" <civodul>i've pushed the updated guix package so i'll reconfigure berlin to use that <snape>civodul: Also, I don't think it's good to rely on 'propagated-inputs' <rekado>civodul: yes, Iāll work on it. <snape>and I don't think it'll work, either :-) <snape>because Cuirass redifines GUILE_LOAD_PATH <snape>so the proper solution would be to add guile-gcrypt as a Cuirass input <snape>I can do it too, as you want. Don't forget to add it to the wrapper <civodul>relatedly, i just thought about this plan: eventually, we'll rewrite gnu-system.scm in terms of (guix inferior) <civodul>it'll be much faster since it won't have to auto-compile everything <civodul>plus it won't have issues when new dependencies are introduced <snape>(I realise that what I said about adding (gcrypt hash) at the top of bin/evaluate was useless) *ecbrown refreshes question about (gcrypt hash) errors in one of my channels <ecbrown>i see "no code for module (gcrypt hash)" <ecbrown>and desperately adding #:use-module (gcrypt hash) does not fix it <snape>ecbrown: the error means you *have" the #:use-module already, but you don't have the module installed <ecbrown>(also i don't know if its a channels issue, i have guix savannah and two repos that are on my gitlab. the complaint is coming from building a personal repo) <efraim>I'm getting errors on guix pull too <ecbrown>snape: i've explicitly done guix package -i guile-gcrypt <iyzsong>the 'guix-daemon' failed to configure without 'guile-gcrypt', which was cleared by its empty 'propagated-inputs'.. <efraim1>rekado: on core-updates, bootstrap-tarballs aarch64-linux -> i586-pc, patching glibc-2.23 failed in libio/iopopen.c <rekado>efraim1: yes, Iām changing the hurd libc to use 2.28 instead. <civodul>iyzsong: fixed now, sorry about that! <civodul>perhaps thi sis also what ecbrown experienced <civodul>snape: BTW the "In progress" message in Cuirass is really nice <snape>note that the 'in-progress' column will be reset 0 at Cuirass reboot <rekado>āserver message: 421 4.4.2 Message submission rate for this client has exceeded the configured limitā <rekado>I got this mid-execution of āgit send-emailā to debbugs. <civodul>were you sending a big patch series? <civodul>maybe you need to wait a little and send the remaining messages <roptat>rekado: there's a --in-reply-to option for git send-email to prevent breaking mail threads <roptat>or maybe you used it and my client is broken :) <roptat>ok, my client is broken, now it shows them in the right thread :/ <roptat>oh, that's because I didn't receive 06 yet, which is the parent for the rest of your patches *rekado did not use --in-reply-to and feels inadequate now <roptat>rekado: maybe debbugs added the correct headers then <rekado>thanks to the very advanced threading code in mumi, Iām sure ;) <rekado>we may have to revert 3ad6b8909025a8f4d3e1f1f5ea16bcd0cace557c <rekado>it upgrades ghc-tasty, but that breaks a large number of Haskell packages <rekado>besides: thereās work underway to update the default GHC; thatās almost complete. *rekado tries to fix the broken packages <janneke>civodul: just tried to build `hello' and found at least two problems building libstdc++-boot0; one fixed, looking at the other problem now :-( :-( sorry! <janneke>apparently i failed to test this, and assumed that if glibc-2.16.0 is OK for make-boot0, binutils-cross-boot0 (where glibc-2.2.5 failed), that all would be well <janneke>it turns out that libstdc++-boot0@4.9.4 does not build with the current gcc-4.7.4 + glibc-2.16.0 <civodul>rekado: sure, reverting would be fine with me in this case <rekado>another problem is the update of ghc-base-compat <rekado>that too would have to be reverted <rekado>for Haskell things itās really crucial to build out the whole thing or rather update everything together. <rekado>same reason Iām doing the R updates all at once. <civodul>ok, i was hoping there'd be a little less coupling <civodul>so we should probably state this all-at-once update policy somewhere? <civodul>so that people don't send individual package updates <rekado>the problem is really just that all of Haskell hasnāt been updated for too long. <rekado>so some individual updates seem certainly reasonable <rekado>I guess we just need to schedule all-at-once updates instead of just hoping that someoneās going to do it at some point. <civodul>samplet & you may well be a significant part of this task force :-) <janneke>now trying to downgrade libstdc++-boot0 to 4.8.5 -- but it looks like gcc-4.7.4 is not good enough...maybe we need yet another intermediate gcc-4.8 before we can build 4.9? or 4.9-core + c++ before we can build libstdc++-4.9... <snape>civodul: If you removed the 'guix-modular' input from load-path-inputs, maybe you should change the 'maintenance.git' spec so that it makes sense... But I think it's best to leave the input in load-path-inputs :-) <janneke>okay, libstdc++-4 4.8.5 "builds" but fails during install *janneke will compose an email *snape compiles guile-fibers <civodul>guile-fibers's tests take a long time for some reason <civodul>rekado, snape: i'm reconfiguring berlin to use the latest cuirass, so i've turn off cuirass there so that "guix system reconfigure" spawns the new one <civodul>it's building guile-fibers right now :-) <roptat>civodul: I think gettext doesn't interpret ~* at all, that's why msgfmt fails on refresh.scm <snape>hmmm emacs-guix doesn't build <efraim>janneke: iirc libstdc++ was put in place because we needed it to get from 4.8 to 5.x in commencement.dcm <janneke>efraim: aahh, that makes sense and certainly helps! <janneke>efraim: can i rephrase that as: libstdc++@4.9 is needed to build 5.x *and* cannot be built with gcc-4.7.4? <janneke>i'm trying to add gcc-4.8 or 4.9 as an intermediate step -- so that may work... *janneke doesn't need guarantees, just a possible direction is already very helpful <janneke>as far as we are now, i'm pretty convinced it's mainly a packaging/versioning problem -- i don't foresee any hard mes/mescc development effort needed anymore <janneke>hmm, building gcc-4.9.4 with 4.7.4 fails: <janneke>../.././gcc/system.h:205:20: fatal error: cstring: No such file or directory <janneke>hmm, same error for 4.8.5 -- so i need to really dive in :-( ***Guest39584 is now known as ocharles
<civodul>roptat: ~* is specific to Guile's (ice-9 format), though that module is inspired by similar Common Lisp modules <snape>civodul: isn't there another issue with Cuirass? <snape>the 'master' spec returns 0 jobs <civodul>snape: i think nobody committed so there hasn't been any new master spec since it was restarted ***ChanServ sets mode: +o lfam
<snape>the 0 0 0 evaluations were the one that failed before the change <nckx>Hullo all! How do I pass command-line arguments to Xorg? <ng0>hrmm.. so even though I have guile-gcrypt installed, this appears while trying to upgrade the system: guix/gcrypt.scm:33:2: error: %libgcrypt: unbound variable <ng0>this is on a very recent pull <lfam>That file 'guix/gcrypt.scm' doesn't exist anymore <ng0>a pull from HEAD shouldn't really complain unles someone made an incomplete commit <ng0>generation 26, build from 3b0153bd828f68804f7226ca655d26aaa1a0c065 <lfam>Are you seeing this error from `guix pull` or using `./pre-inst-env`? <rekado>ng0: can you show us the exact command you used? <ng0>'guix pull' .. followed by guix system build config.scmā¦ where I also have GUIX_PACKAGE_PATH prepended, but none of that conflicts with guix. <ng0>you will ask again I guessā¦ here: <ng0>guix pull; GUIX_PACKAGE_PATH="/home/user/src/guix/guix_private_work/packages/packages:/home/user/src/infotropique/infotropiqueOScore_related/ports:/home/user/src/infotropique/infotropiqueOScore_related/ports-wip:/home/user/src/goppa.io/guix/linux-channel" guix system build ~/src/systems/old_systems/guixsd/workstations/abyayala/config.scm <ng0>I deleted all symlinks and am building again.. now guile-gcrypt got pulled in. I'll test again <rekado>I was going to ask for trying it without GUIX_PACKAGE_PATH <rekado>I hope this doesnāt mean āfind / -type l | xargs rmā ;) <thorwil>shouldn't those 2 reports be linked? is there a way to subscribe to a bug? <lfam>Yes, those reports should probably be linked (assuming they are about the same issue) <ng0>i don't see how my path would affect the build when guix gcrypt is not referenced in it.fwiw my system daemon is on an older commit. if anything I'd assume this would affect it. <ng0>same without the path <ng0>and modules in the config file removed <lfam>ng0: Which commit is the daemon from? <ng0>this should be easier to select.. 0.15.0-2.8bbb79c <ng0>my second best idea right now is to pull from 7e1d229019c1924a2748e5daec2a619e7efbd7d7 <ng0>what I have now systemwide is: /gnu/store/12kzrx9g4cik1ddqaf6j0j7mdqmwvhnk-guix-0.15.0-2.8bbb79c/bin/guix-daemon <ng0>I hope to find the time this week to fix the online logs btw.. unless you moved on to the plain files. historic backlogs will be fixed, but that's outside of what I will do (it's up to grothoff) <ng0>I meant to do it all in one week, but life happened. <ng0>for this generation, fixed it. just need the jump to HEAD then when this works <ng0>I'm not sure if it was fixed yet. I'm still building towards a commit before guile-gcrypt was removed. <lfam>ng0: I think it would be nice to go back to the gnunet logs if possible <ng0>until we can do that, would it could you strip the IPs in the logs? I know irc doesn't do that by design, but it's strange tooting the horn against spyware and prefering privacy solutions, when logs are just published as-is <ng0>okay, problem remain with gcrypt. I'm out of here for a while -.- ***Guest3902 is now known as ngz
<rekado>ng0: please send a description of your problem to help-guix@gnu.org *civodul trying to get the PSU bought, fighting with a shopping phobia <efraim>I see it has 20+4 and a sata connector, I don't see information about how much power over each rail but it should be good, not sure if it'll fit in the case <rekado>ng0: I now remove all part/join/quit lines from the logs automatically. *vagrantc pines for a qtwebkit substitute <efraim>I have my replacement PSU sitting on top of the case <civodul>efraim: yeah it may not fit in the case but that doesn't matter; it's 180W AIUI <civodul>"error: r-graph: unbound variable" does that ring a bell? <roptat>ok, I can manage peer connections now :) <roptat>all that's left is actually asking for pieces and writing them to file <roptat>mh... and finding what piece peers have and don't have yet <vagrantc>how much ram do the substitute builders have? <vagrantc>building qtwebkit took about 10GB of ram+swap ... and 12GB of free disk space wasn't enough <vagrantc>but it was very nearly done when it ran out of disk space *vagrantc frees up more disk space and tries again <janneke>okay, gcc-4.9.4 almost builds now... <janneke>i'm fighting with the ld.so interpreter <janneke>when xgcc wants to build libstdc++-v3, configure bails out because the -Wl,--dynamic-linker ... isn't set <janneke>i created packages gcc-mesboot1-wrapper and gcc-mesboot-wrapper to set those, but that doesn't work for xgcc <janneke>now, how to bake-in the right dynamic-linker file-name? <janneke>hmm, gcc.scm:gcc-4.7 sets LDFLAGS and LDFLAGS_FOR_TARGET for that <janneke>yay...and another round gcc-4.7.4, gcc-4.9.4 <janneke>you won't believe how tcc can be built, or even gcc-2.95.3 <civodul>rekado: commit 50763073edb5a992220eb1aa6d33a5f1485460f6 causes the r-graph unbound variable error that we have on master when running, say, "guix package -A | wc -l"