<katco>and 2 of these scripts are invoking builds utilizing cgo <katco>which is bringing gcc and linux headers into the build <katco>is it acceptable to just disable these two tests? <lfam>katco: I think it's okay if GCC and the kernel headers are required for the test suite. Ideally they won't bring new run-time dependencies into Go itself. What happens when you try to run the tests with GCC and the headers? <katco>i'm slowly getting there. i _just_ got the scripts to recognize the headers <katco>each script is run in its own little sandbox, so i've had to learn this little scripting language to figure out how to inject the deps <lfam>It could definitely be useful to disable the tests for now and then see if Go works. The tests can be re-enabled later <katco>i got frustrated last night and tried that :) <lfam>Heh, it's like writing your own test ;) <katco>so the thing it's complaining about now: `ld: cannot find crt1.o: No such file or directory` <lfam>I'm sure you noticed we already disable lots of tests that simply won't apply in the Guix build container. We prefer not to disable tests for other reasons but sometimes it's worth it if making them work seems like a poor use of our time <katco>gotcha. that's good context, thanks. <lfam>katco: Hm, that particular issue is pushing the limits of my knowledge. I'm curious where it is looking... <katco>this is prior to including gcc which i think might solve this <katco>so how do i do i include a certain output of a package as input to this? i think i want gcc:lib? <katco>ah wait i think i see an example <katco>lfam: these two tests are just a pain. i've gotten to the point where they can find the headers they need, but i can't seem to point them to the glibc directory with the crt1.o files they need. which is to say i have done what should work, but they're still complaining <katco>lfam: i'm going to submit having removed these tests. but how can i communicate what i've tried in case i've missed something? <lfam>katco: You could send the patch to <guix-patches@gnu.org>. You'll get a message back with the bug ticket number, including a reply address specific to the patch. You can reply to that address to keep your notes and patch together <katco>i haven't contributed code in this style before, so everything is new. <katco>lfam: ok i think i've submitted. i hope i did all this right. no email back from guix-patches though <lfam>katco: I think the first message from an address usually takes a little while (it might be manually moderated) <katco>ah that makes sense. well, feedback welcome when it does come through. headed to bed for the time being. thanks for the help! <lfam>katco: Thanks a lot for working on this! ***jonsger1 is now known as jonsger
<thorwil>i just learned that with `guix build --log-file gimp-resynthesizer`, i get just the same result as without --log-file. it's only with `guix build --log-file /gnu/store/r0x4nyd2vfd802nzipp6q5cbssbiq4qa-gimp-resynthesizer-2.0.3.drv` taht i get the path to a logfile <thorwil>oh. build tells me "./configure: line 9047: /bin/sh: No such file or directory", but in config.log, i find: "conftest.c:27:42: fatal error: CoreFoundation/CFPreferences.h: No such file or directory" <thorwil>seems CoreFoundation is osx business. a bit odd to read "compilation terminated" several times, when that apparently wasn't the actual failure <roptat>the ocaml importer is broken with the release of opam 2.0 :/ <civodul>are you in touch with the opam devs? <roptat>it seems we simply have to change one url to use the repo for 1.2.2 <roptat>but it's not maintained anymore, so we won't get any update <roptat>in which there is one directory per version, in which there is an opam file <rekado>thorwil: this sounds like an objective C thing. We have an objc compiler, but we don’t have GNUstep. <thorwil>rekado: i'm not sure how to interpret that config.log, but those may be equivalent to failed checks for optional stuff <thorwil>the requirements listed just the classic toolchain, no word about objectiveC or GNUstep <thorwil>anyway, configure gets to "configure: creating ./config.status" <thorwil>then "./configure: line 9047: /bin/sh: No such file or directory" <thorwil>isn't /bin/sh in the responsibilty of the gnu-build-system? <civodul>we have 'patch-shebang' phases that address this <civodul>roptat: perhaps we should tell them our use case and see if they can come up with something <civodul>i suppose other distros may be interested in this as well <thorwil>civodul: ok, then what may be going that this case isn't addressed? <civodul>thorwil: it could be that some file is generated with "#!/bin/sh" after the patch-shebang phase has run or something <civodul>it's hard to tell without knowing the specifics <civodul>perhaps you could email the details to help-guix? <thorwil>i notice that the following phases happen: set-SOURCE-DATE-EPOCH, set-paths, install-locale, unpack, bootstrap <rekado>our paper on PiGx with Guix was shortlisted for an award; I’ll get to present it at ICG in Shenzhen in about a month. <rekado>(and publication fees haven been waived, yay!) <civodul>really good that your efforts are recognized <civodul>and that you'll be traveling to Shenzhen too ;-) <ng0>sneek: later tell mark_weaver: I've just discovered and read the discussion on circular dependencies in Guile and Guix. Very insightful. Thanks! <ng0>yeah, it takes a while or reading the code on the build chroot until you see that '/bin/sh' does not exist :) <mbakke>I noticed evaluations are failing for berlin and Hydra, not sure if that will fix it. <rockandska>wanna ask something before submitting an issue, is it consider as a bug to not have GUIX_LOCPATH into "/etc/profile" when using relocatable ? (example: guix pack -R -S /bin=bin -S /etc=etc hello glibc-locales) <thorwil>will any use of /bin/sh in a configure script lead to problems? (with a shebang like #!/gnu/store/rbrandv7anzjxqkr40d7fkanzssslk4b-bash-minimal-4.4.19/bin/sh) <snape>mbakke: I can't see evaluations failing on Berlin <mbakke>But presumably that issue has been fixed on master? <snape>mbakke: that was before last reconfiguration <snape>it was because an issue with (gcrypt hash) I believe <snape>mbakke: a failing evaluation would appear as "In progress..." until Cuirass is restarted. <rockandska>any comments regarding the missing GUIX_LOCPATH in the profile generated by "guix pack -R" ? <roptat>rockandska: if you don't get answers here, you can always ask on help-guix@gnu.org <rekado>I’m still having problems with obtaining a substitute. <rekado>I removed the substitute cache to be sure. <rekado>looking at the new cache I see that there’s a substitute in the cache for wayland. <rekado>yet Guix will not do this for me. <nckx>thorwil: Trying to execute /bin/sh anywhere in the script will fail. <rekado>I wonder if that might be a corrupt nar. <civodul>rekado: do you have a cached narinfo for this one? <rekado>civodul: yes. I cleared the cache, ran guix build to fetch the substitute. <civodul>rekado: so there's a cached narinfo but the nar isn't fetched? <rekado>civodul: yes, this seems to be what happens. <rekado>I also wonder if this is related to having this centralized Guix setup <rekado>I’m using my local current/bin/guix and the cache is on the server where the daemon runs. <rekado>the /var/guix directory is remote <Sleep_Walker>if I am using GUIX_PACKAGE_PATH, where are the patches searched for? <snape>Sleep_Walker: patches can be in GUIX_PACKAGE_PATH <Sleep_Walker>so I have top directory for patches and then following the convention of gnu/packages directories... <snape>Sleep_Walker: no, there is no need for any convention <snape>it doesn't need to be gnu/packages, it can be foo/bar as well <pkill9>Sleep_Walker: you can specify sub-directories to search for patches in <pkill9>i saw an example of one somewhere <pkill9>so basically just prepend a path from the root of the directory in GUIX_PACKAGE_PATH, without any leading / <pkill9>i think leading is the right word, i mean without a forward-slash at the beginning <joshuaBPMan>I'm going to try to package an ikiwiki plugin today. Wish me luck. *janneke now tries to bootstrap x86_64 too, starting from i686 <jonsger>we don't have a recursive ghc/haskell importer yet or? *janneke only has a non-helpful response: i never used a scanner since my phone does well enough... <dustyweb>sorry janneke, I agree that is not helpful ;) <dustyweb>I haven't been able to download photos from my phone either on GuixSD <dustyweb>I still have a TODO to send civodul a photo from FOSDEM 2017! <dustyweb>I am thinking I might switch my backup machine to running Debian just so I can scan things and upload phone photos <janneke>yeah, i made a scrappy adb package once -- hmm <nckx>dustyweb: Which software did you (try to) use? <dustyweb>the usb device is showing up on lsusb but I don't know how to find it in /dev/ <samplet>jonsger: I thought one was recently committed. <dustyweb>haven't looked up how to do that in guix yet <nckx>OK, I was just installing ss. <dustyweb>it does look like there is a nice udev service <janneke>meanwhile, me is building x86_64 guile-final on wip-bootstrap :-) *nckx does miss the substite server name in the new fancy 'guix package' output. <samplet>jonsger: It looks like you have to use the Stackage importer. <d1rewolf>does guix (the package manager) support other os's besides the guix system distro? <ng0>dustyweb: simple-scan works <nckx>Not without some servicey help, here, it seems. Doesn't find my USB scanner. <janneke>hey samplet, now that wip-bootstrap starts to work, gash/geesh is becoming more interesting; care to weigh in on guix-devel? <d1rewolf>samplet: thanks. Does is work like nix in those cases? (uses custom nix packages instead of the target distro's packages)? <jonsger>samplet: stackage and hackage do both have recursive importers :) thanks to rekado :) <samplet>janneke: I saw your post and am thinking about it. I need to finish a major Haskell update that I took on first, though. <d1rewolf>nckx: ok, thanks. And is there some security policies/procedures published and followed? I'm using nix currently and trying to push adoption at work, but no published policy basically makes it a non-starter <janneke>samplet: great -- there's no hurry, i'm not ready to start hacking on it...but it could be the next big thing <janneke>removing gcc,glibc,binutils from the bootstrap binaries reduced their size from 250MB to 130MB; guile is only 10MB -- the rest could potentially be replaced by gash/geesh + some work ;-) <d1rewolf>anyone running guix on ubuntu or debian here? <janneke>d1rewolf: i think most of us started that way, some collegues of mine are still doing it that way <d1rewolf>janneke: and you switched to guixsd since? <janneke>d1rewolf: about two years ago, ran guix on debian for ~4 months <d1rewolf>I'd really like to try guix, and I've found the nix interface/myriad of commands intimidating, and I'd rather lisp than nix-lang. However, I don't necessarily want the strong libre opinions of guixsd...for example, I'd like my proprietary nvidia drivers to work, and I don't mind systemd tbh <d1rewolf>wondering if guix on top of debian or ubuntu would give me the best of both worlds? <janneke>what i did, was slowly move more and more of my computing/developing needs into guix while running debian, and uninstalling packages from debian until i made the "jump" <janneke>debian+guix has not always been seamless for me, certain setup things that were difficult for me worked ootb after switching to guixsd -- but ymmv <d1rewolf>janneke: any luck with proprietary drivers like nvidia? <janneke>d1rewolf: you possibly shouldn't ask me, i'm a pretty software freedom extremist ;-) <janneke>and tbh, GuixSD really made that easier for me <janneke>a collegue of mine is constantly fighting with their nvidea setup and the projector, but they're very happy with their ubuntu+guix setup <d1rewolf>and any sort of security disclosures/procedures? <dustyweb>ng0: I guess it just can't find the device... it's probably a udev rule issue <ng0>I use a printer+scanner combo <ng0>drivers.. blob'ed drivers n firmware are "offtopic", but with enough time you can figure out most, excluding some types of them. <ng0>there are no commercial users (yet), but we have a couple of institutes working with Guix and HPC <janneke>i consult for a company that is gradually shifting to Guix and GuixSD *janneke is not sure what 'commercial' means <ng0>(i would hardly call what I do commercial, therefore the "yet".. and not sure what the commerical meant here) <janneke>RetardedOnion: laptops and a couple of 16/32 core dell blades <nand1>is it relatively easy to write a package for guix? I want to use guixsd with libtxc_dxtn, but it is proprietary <RetardedOnion>janneke: what laptops? free software pretty much only limits your choice in gpu/wifi <ng0>nand1: look into elfpatch if you can't build it from source <ng0>some of our bootstrap packages work with it <d1rewolf>ng0: janneke: commercial as in companies who make money to do things versus non-profits or hobbyists <janneke>RetardedOnion: various kinds, mostly dell and hp -- it is (was?) pretty easy to install an atheros wifi card in a laptop -- most use ubuntu+guix <ng0>d1rewolf: then I'm on both sides. <janneke>d1rewolf: well, I am a company...so i guess that's commercial use :-) <RetardedOnion>janneke: ah ok. so i guess only igpus and it runs with atheros. thanks for the info <RetardedOnion>d1rewolf: integrated gpus. meaning intel hd graphics. because amd needs blobs to run *janneke just built x86_64 hello without using any glibc,gcc,binutils binary seed! <RetardedOnion>i thought "igpu" was a term that was thrown around more often. i guess not.. <janneke>ng0: txn, yeah -- just praying that build farm results of a rsn core-updates-next won't present us with too many difficult failures...oh well <jabranham>When running guixsd to update "root" packages (i.e. not ones I've installed into my user's profile) all I need to do is "guix pull" and then "guix system reconfigure /etc/config.scm", right? <lfam>jabranham: Every user has their own profile, including root. You can update root's packages in the same way you update your user's packages. `guix system reconfigure` updates packages that are listed in config.scm, and available for all users <jabranham>lfam: so to fully update root packages (e.g. the kernel) I have to do "guix pull", "guix package -u", "guix system reconfigure /etc/config.scm"? <lfam>jabranham: No. There is a difference between root's packages (installed by root with `guix package -i`) and global packages such as the kernel (from config.scm) <lfam>To update the kernel, do `guix pull && guix system reconfigure /etc/config.scm` <lfam>To update the packages that the root user has installed for themself, do `guix pull && guix package -u` <jabranham>lfam: ah, OK I think that was the part I was misunderstanding. So as long as I've never "guix package -i" something as root then I don't have to worry about "guix package -u" as root. <ng0>you can even skip root from ever having a profile, and make updates with sudo -E <jonsger>d1rewolf: you could use openSUSE. There you can install guix with just "zypper install guix" :) <nckx>Is it considered bad style to (invoke "foo" ">bar")? <lfam>katco: There will be a review from someone soon (ideally today, I can probably do it) <katco>ah cool! for my own edification, how do people know to review things? <lfam>katco: There are a few ways people keep track of the patch queue. I just use email, some people use emacs-debbugs, there is also a new thing called 'mumi' which works with this alternative interface: https://issues.guix.info/ <samplet>nckx: IIRC, Guile does the right thing when calling “system*” with “current-output-port” set. So you could probably use “with-output-to-file”. <samplet>(As long as the output port is file-based.) <nckx>samplet: Ah, thanks. I actually looked at with-output-to-file but it didn't seem appropriate, but I didn't try it... <nckx>Glorious. Thanks again, samplet. <rekado>nckx: I wonder about the substitute output with “guix package”, too. <rekado>nckx: we now have the trace output (“Substituting…”, “Substituted…”) but it looks like the actual download indicator itself is gone. <thorwil> (substitute* "configure" (("/bin/sh") "test") should replace the substring "/bin/sh" with "test" ... or does it only work if "/bin/sh" is the entire line? <thorwil>nckx: the result should be reflected in what is left in /tmp, then? <thorwil> /tmp/guix-build-gimp-resynthesizer-2.0.3.drv-0/resynthesizer-2.0.3/configure in this case <nckx>rekado: Ah, that's not by design? I never realised I kept half an eye on that output to know a) whether my build farm is still doing its job and b) who's to blame for any slowness. <nckx>thorwil: It should. And it isn't? <thorwil>nckx: no, a grep quickly shows me there is no change <thorwil>currently using it in (add-before 'patch-shebang 'fix-sub-shells ...) <nckx>And you're sure that your phase runs before the build aborts? <thorwil>the last marked phase reported is bootstrap, but there's the line "patch-shebang: configure: changing `/bin/sh' to `/gnu/store/rbrandv7anzjxqkr40d7fkanzssslk4b-bash-minimal-4.4.19/bin/sh'" <nckx>I actually started messing with your resynth package but have some packaging of my own to finish first. <nckx>thorwil: Try (add-after 'unpack '... <thorwil>with add-before 'bootstrap, it fails, as there is no "configure" at that point <thorwil>same with add-after 'unpack, unsurprisingly <thorwil>though it does print "starting phase `fix-sub-shells'" <thorwil>of course, ./autogen.sh is not called until early bootstrap, sheesh :) <nckx>Oh duh. I meant after 'bootstrap. I was writing unpack in my own code. :-) <nckx>Point was just that it shouldn't interact with patch-shebangs. <thorwil>ok, so before bootstrap starts, configure doesn't exist. but before bootstrap ends, line 9047 of configure translates to a call to /bin/sh 0.o <thorwil>ouch, add-after will happily accept 'made-up <lfam>It would be nice to validate that, I'm sure there are some instances lurking in the packages <lfam>Great minds think alike ;) <ivegotasthma>I just downloaded the 0.15 release of guixsd and ran it inside a qemu vm. I'm running `guix package -u` and I'm getting an error about a corrupt schema. Any clue? <lfam>ivegotasthma: Can you give more details about the error message? <lfam>It would also be helpful to see your exact QEMU command-line so we can try to reproduce the problem <ivegotasthma>I downloaded the image with curl and ran it through unxz <lfam>Okay, I'm going to try reproducing it <lfam>Did you follow the introductory steps listed in your screenshot? <lfam>Maybe, although the error message is not at all helpful <jonsger>janneke: will it be still possible, after you merge your bootstrap stuff, to build guix from the "big" bootstrap binaries? <lfam>ivegotasthma: I downloaded the QEMU image from our download page, renamed it like you did, and used your QEMU invocation to launch it. I'm using QEMU 3.0.0. Once it booted, I logged in as root and did `guix package -i cowsay`. It failed but because I hadn't set up networking. Once I did that, it proceeded as normal, although I cancelled it before it was done <lfam>ivegotasthma: Are you sure the file you downloaded is not corrupt (did you validate the signature)? Which version of QEMU are you using? <jonsger>so will there be more stuff to build, when build guix from source janneke? <lfam>`ping` doesn't work when you use QEMU's user-mode networking system (-net user) <lfam>Something to note is that it might take a few seconds for the DNS resolver to start working after using `dhclient`... this always trips me up <lfam>The messages about repartitioning are probably too obscure, now that I read them more than a year later. They are really specific to the situation where you use the image on a VPS provider with console access but no advanced out-of-band storage management tools <lfam>In general, you will have better results building a fresh VM image with tools like `guix system vm` (immutable VM) and `guix system vm-image` (mutable VM) <lfam>Any QEMU experts here? I'm wondering what format our VM image actually is. `qemu-img info ...` says qcow2, but `file` says qcow3. It would be nice to keep our documentation correct <civodul>lfam: i didn't know qcow3 was a thing! <civodul>i think we explicitly pass "-f qcow2" or something like that in vm.scm <civodul>janneke: "Reduced Binary Seed bootstrap for x86_64 too." oh! <janneke>civodul: mainly g_bor's and your fault! you (both) said it would be low hanging fruit <janneke>didn't imagine i'd have to dig for it ;-D <janneke>civodul: just hoping the build farm won't say NO too often when we create core-updates-next ... <lfam>civodul: Yes, you're right! AFAICT qemu-img can't create qcow3 files anyways <rekado>janneke: do you mean that you fear it might not be able to build it all? <janneke>rekado: not really, we have guile-final, gcc-final, glibc-final -- just "afraid" of lots of unexpected work <janneke>think: cross-compilation, hurd, ... al the things i didn't test <janneke>maybe i broke ARM... that kind of thing <lfam>Then we'll need to create a cast 