<dvn>vlc is failing to build now <dvn>i'm running the build again - i'll paste this time <lfam>reepca-laptop: Google says xpdf and poppler <reepca-laptop>... out of curiosity, what did you search to find that? I put in "guix pdftotext" and didn't find anything along those lines at a glance <lfam>I just searched for 'pdftotext' and looked at the wikipedia article that popped up <lfam>So, I'm guessing our packages provide it ;) <lfam>dvn: I just tested an upgrade of VLC to 3.0.4. It worked for me so I pushed it. I recommend stopping your build and trying again with the new version ***jonsger1 is now known as jonsger
<wingo>after a guix upgrade, my bash completion stopped working <wingo>does that ring a bell for anyone? <wingo>doing a manual source /run/current-system/profile/etc/profile.d/bash_completion.sh fixed it <civodul>wingo: it works for me, though "guix build TAB" doesn't, weird <ng0>somewhere close to the top of the file <ng0>rekado_: NO_COLOR disables the colors. and what baout the silenced build output, how do I get that back into display by default? I Must have missed the point where you wrote this <ng0>it is the --verbose switch and there is no way to make this default. great. <wingo>no need for the caustic tone :/ <ng0>i disagree with this opt-out choice. <ng0>if you want a fancy view, write a Qt interface <ng0>colors, hidden build log, everything should be opt-in <ng0>the build log is what I am interested in. the only thing <ng0>i don't really want to discuss about this, I'll work on a fix for myself since apparently a majority of 4 people or so has agreed that hiding this by default is a good choice. <nckx>If you want output on success, don't use *nix. <nckx>Please be reasonable. 4 people isn't a majority, but neither is 'I like x' a sane argument. <nckx>Also, how is everybody silencing their build output? I'm fully up-to-date and still get spammed silly. <roptat>my English->French dictionnary doesn't know that word <nckx>(Not a fan, but then I was parsing the @ output in bash. So tickle me I guess :-/ ) <nckx>roptat: It's just 'pretty' with a very *bad* fake Southern-US accent. <nckx>Now I'm sorry for teaching you that. <dvn>i also think that quieting the build output should be a flag - similar to how portage has --quiet (-q) <dvn>it's annoying to have to run the build again if there is a problem and you need to get more context <dvn>that's not really an issue the other way around <roptat>did a recent commit change that? I think I still get the full output <dvn>idk when, last couple of days <nckx>So do I, but I suspect it might change after restarting the (updated) daemon. <dvn>one way to set it as default for users is if we had something like ~/.guix/rc.conf where you could set "GUIX_QUIET = 1" <roptat>ah maybe my deamon isn't updated ***rekado_ is now known as rekado
<rekado>nckx: build output is hidden only when “guix package” is used. <ng0>okay, let's try this again. sorry, I am more used to the frontal approach which is typical German. I like the patch, really. I just don't like some choices it takes away from me. <nckx>We should use this pressure to improve our log handling/interface, *then* revert to showing all output ;-) <ng0>and guix package can lead to guix build <ng0>where the output continues to be hidden, which is the actual problem for me <nckx>Aaah. Thanks rekado. I never really use that. <ng0>so let's say I run guix package -u. Then package might build some packages from source, which is essentially guix build. <ng0>if a build fails there, I need to do the extra step to --verbose with guix build that failed package *rekado feels unhappy about the tone and is close to just taking an extended period of time off Guix :-/ <nckx>rekado: Um... I just meant 'pressure' in a motivational scratch-the-itch sense, not social. <ng0>sneek: later tell rekardo: I'm sorry. Lately I'm under lots of pressure in personal life and I try very hard not to make this show in how I write. <g_bor>I've just recently returned after a longer time off. Can someone get me in the picture about the next Outreachy round? I've seen no proposals yet. <nckx>g_bor: I'm afraid I think there aren't any yet. <ng0>sneek: later tell rekado: I'm sorry. Lately I'm under lots of pressure in personal life and I try very hard not to make this show in how I write. <ng0>sneek: later tell rekado: I had no knowledge of the email about the same subject btw, so now I understand. <ng0>(and with this I'm off to do stuff) <Gamayun>That's still the bad thing about online interactions, not knowing how people are doing or seeing how they react. <Gamayun>ng0: Hope the pressure eases for you.. :) <civodul>ng0: the harsh tone is really uncalled for <civodul>you might be unhappy with the change but there are other ways to resolve that <dvn>civodul: ng0 literally just apologized... ? <civodul>actually there were ways to resolve that before: we all had a chance to chime in when the patch was submitted *civodul is scrolling through the backlog <civodul>anyway, just to say i'm sure we can find a way forward without getting people to feel bad *nckx agreed with ng0's point if not style, but now thinks that making guix *package* quiet is likely TRT, so will also evacuate this unfortunate scene. Bye. <civodul>yeah we discussed it several times over the years, and it seemed best to have silent output by default for 'guix package' <civodul>this is all subjective of course, so the question is really about the default <civodul>i think silenced output for 'guix package' by default is a wise choice <roptat>that combined with a policy that "master" should never break a working build ;) <roptat>then there's no failing build with guix package -u so no need to run a build twice <civodul>roptat: you never need to run a build twice since build logs are kept around <civodul>but maybe we should display a hint about this <civodul>we could also arrange to display the last 10 lines of the build log upon failure, something like that <roptat>10 lines might not be enough though (especially for java packages) <roptat>because the last error is usually the consequence of previous errors <roptat>but really if we print the path to the log, it's probably enough <roptat>something like "please report this failure to ... and attach the following file: ..." <thorwil>hi! azr-3 failes to build, but the error states only that fact, nothing else <thorwil>how do i get guix to be more verbose? <crashcrash>Hello everyone! I have problems using guix. Previously, my pc freezed while installing locales. Now, doing it from tty, it just fails. Could anyone please help me? I can share more info (i logged the process), just ask. <dvn>civodul: what do you mean build logs are kept around? where can i find them? <civodul>you can run "guix build --log-file /gnu/store/...foo.drv" <civodul>or "guix build --log-file coreutils" <civodul>to me that suggests we need to display a hint or something :-) <dvn>ok but thsat means you must run it again <dvn>if you do "guix package -u" and it fails, then you must run again with "guix build ...", no? <civodul>"guix build --log-file" displays the file name of the build log *thorwil got his info via guix package --verbose ... <ng0>dvn: you might need --no-grafts --no-substitutes and something like that in case you get the logfile of a grafted build <dvn>ok for instance i run this on vlc and it begins to download git <dvn>it doesn't show anything about a log file <crashcrash>Hello everyone! Installing locales fails for. PC is odroid xu3 lite (xu4, arm processor), OS is armbian. Please, help! <g_bor>crashcrash: Would you share some information about how it fails? I might not be able to help, but more info is welcome. <nckx>dvn: Did you already 'guix build' (or equivalent) the same vlc? That shouldn't happen then... <nckx>(...unless we now transparently fetch logs via git :-) <dvn>ok you're right - different vlc <g_bor>civodul: istm Danny is also on the opinion to display a hint on how to get to thee failed log file. <crashcrash>g_bor: Yes, of course! I logged the process as I was told yesterday. Log file is 6.8 megabytes. Where can I put it? Paste.Debian ? <nckx>Yeah. Having the correct log command easily middle-mousable would be a nice touch. Bonus points if it can always point to the ungrafted item. <nckx>crashcrash: Maybe just start with the tail -n <whatever you or p.d.o deem reasonable>. <crashcrash>in the end there are several lines about dependencies that could not be built <crashcrash>for example cannot build derivation `/gnu/store/qvizas3638ymhy0vff0wiwk4mn4jr12r-glibc-2.27.drv': 1 dependencies couldn't be built <crashcrash>As I see the most important lines are: "builder for `/gnu/store/98kk1yy5wmb2g0h5mrkfhggjasp31vr6-gcc-cross-boot0-5.5.0.drv' failed with exit code 1 cannot build derivation `/gnu/store/p7gam79m29cvvry4k6b4qb1gfr22axax-gcc-cross-boot0-wrapped-5.5.0.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/store/qvizas3638ymhy0vff0wiwk4mn4jr12r-glibc-2.27.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/ <crashcrash>"builder for `/gnu/store/98kk1yy5wmb2g0h5mrkfhggjasp31vr6-gcc-cross-boot0-5.5.0.drv' failed with exit code 1 cannot build derivation `/gnu/store/p7gam79m29cvvry4k6b4qb1gfr22axax-gcc-cross-boot0-wrapped-5.5.0.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/store/qvizas3638ymhy0vff0wiwk4mn4jr12r-glibc-2.27.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/store/d0d8cy2br4r2vw551z8wqm9b73fyhp15- <crashcrash>"cannot build derivation `/gnu/store/p7gam79m29cvvry4k6b4qb1gfr22axax-gcc-cross-boot0-wrapped-5.5.0.drv': 1 dependencies couldn't be built" <crashcrash>"cannot build derivation `/gnu/store/qvizas3638ymhy0vff0wiwk4mn4jr12r-glibc-2.27.drv': 1 dependencies couldn't be built" <crashcrash>"cannot build derivation `/gnu/store/d0d8cy2br4r2vw551z8wqm9b73fyhp15-perl-5.26.1.drv': 1 dependencies couldn't be built" <crashcrash>"guix package: error: build failed: build of `/gnu/store/d0d8cy2br4r2vw551z8wqm9b73fyhp15-perl-5.26.1.drv' failed" <nckx>crashcrash: That's just the last few dominoes falling. Could you pastebin the last few 100 lines or so? That's more what I meant. <nckx>No problem. Take your time. This might be mailing list material; not so many people here know ARM that well. *nckx apologises in advance for using the genericised term 'pastebin' ;-) <crashcrash>"[14:12] * nckx apologises in advance for using the genericised term 'pastebin' ;-)" Oh, you know, i'm just new to irc chats =))) <nckx>crashcrash: So the real problem is 'make[2]: *** [Makefile:2156: s-attrtab] Killed'. That's almost always an out-of-memory (OOM) issue. Does your dmesg or /var/log/messages have any OOM messages from that time? <nckx>crashcrash: Nah, my bad. I meant 'pastebin it on p.d.o.' but that was unclear. Pastebin.com is freedom-hostile. Not your fault. <nckx>crashcrash: How much RAM do you have? Do you know whether you're using multiple --max-jobs and/or --cores to build? <crashcrash>nckx: ok. 1. I don't have /var/log/messages file. 2. I cannot dmesg it as it was yesterday and i reset my pc recently. 3. I have only 2GB of RAM 4. I just used the most common command to install locales. I mean that all my settings are default. Maybe I should change something? <roptat>crashcrash: what does "guix -v" tell you? <roptat>ok, nice, that's the latest version <roptat>I was afraid you were running on an old version <roptat>did you add hydra to the list of substitute servers? <roptat>so, you can run "guix archive --authorize < ~root/.guix-profile/share/guix/hydra.gnu.org.pub <crashcrash>I've done just the minimum of configuration that was adviced in manual <roptat>then you will get substitutes which will help you a lot <nckx>crashcrash: Good suggestion by roptat. Otherwise I'd suggest trying again with ~2 GiB of swap. Good luck! <crashcrash>roptat: you know, the point is I would like to compile everything on my pc, but thank you in case everything else doesn't help i'll do <roptat>then nckx's suggestion: add more swap <crashcrash>And actually i'm rather short of memory. I have only 15GB sdcard and 1GB of swap. Could you tell me, how can i increase the swap? <crashcrash>I just have more 9 GB of free space, so it might be possible <roptat>you can add a swap file like so: first dd if=/dev/zero of=swapfile bs=1M count=2000 then: mkswap swapfile and finally: swapon swapfile <roptat>that should give you an additional 2GB of swap <HiPhish>Hello everyone, I am trying to port a new package to Guix: <HiPhish>The issue is that it uses the usual `./configure && make && make install` routine, but the configure script is hand-written. <HiPhish>On the mailing list people have suggested to replace the `configure` phase. <roptat>I see this in the configure script: PATH="$(getconf PATH 2>/dev/null || echo /usr/bin:/bin)" <roptat>if they overwrite our PATH, no wonder they can't find expr or cat ;) <crashcrash>roptat: So, thank you so much, I will try and come back if it fails. Bye! <HiPhish>roptat: So I would have to patch the configure script first? <roptat>I think you can try adding (string-append "PATH=" (getenv "PATH")) to your apply invoke <roptat>it seems they allow you to pass environment variables that way <roptat>hm... do you know how getconf works? <roptat>ok, then your best option now is to patch that configure script <roptat>I'd just remove any line that starts with PATH <roptat>or maybe only that first line "PATH="$(getconf PATH 2>/dev/null || echo /usr/bin:/bin)"" <crashcrash>roptat: Oh, by the way. Is there any way to force guix to use less resources? Just in case I don't have space for swap for example and if I don't want my pc be too busy to do something at the same time, in parallel? <roptat>HiPhish: and report that as an issue, maybe they can fix it? <HiPhish>roptat: I don't know how to patch the file (than doing it manually of course). I don't think the author will respond to an issue, there has not been any activity for years. <civodul>g_bor: cool, i'll try to come up with a patch <civodul>actually i hadn't tried "guix package -u" yet, and i like it! <HiPhish>I don't understand why `PATH="$(getconf PATH 2>/dev/null || echo /usr/bin:/bin)"` would mess up the path, it only changes the value if PATH is not yet defined. <civodul>HiPhish: "getconf PATH" isn't useful on Guix as you say, though i'm not sure whether/how we could make it any more useful <roptat>`getconf PATH` is not the same as `echo $PATH` <roptat>you can add a phase with something like (substitute* "configure" (("getconf PATH") "echo $PATH")) <HiPhish>Ah, now I see. `getconf PATH` will not pick up on the modified $PATH that Guix has set up. <civodul>roptat: "getconf PATH" returns libc's idea of the default $PATH <civodul>it's a static value that meaningless in our case <HiPhish>Where would I put that `(substitute ...`? <crashcrash>roptat: Well I tried just now and the result is the same =)) Maybe some more ideas?)) <roptat>HiPhish: you need to define a new phase, like so: (add-before 'configure 'fix-configure (lambda _ (substitute ...))) <roptat>crashcrash: same "Killed" message? <crashcrash>roptat: I see completely the same ending, but can't find "Killed" in 'less' programme with search <roptat>can you paste the last 100 lines of log somewhere? <HiPhish>roptat: What is the signature of the lambda? Or rather, what part of the manual is this described in, so I don't have to pester you? <roptat>HiPhish: that lambda only has optional arguments (the #:key and #:allow-other-keys) <roptat>by saying (lambda _ ...) it means you don't care about the arguments <roptat>the arguments are the rest of the options in `arguments` <roptat>crashcrash: well... you need more space :p <roptat>if you have a running guixsd on another machine, you can offload the builds to a virtual machine <roptat>so it doesn't need to be an arm device <HiPhish>roptat: OK, now I got past the configure phase to the build phase. <HiPhish>I now get `make: -ec: Command not found` <HiPhish>Is there a place where I can see the generated makefile? <roptat>HiPhish: this `-ec` is probably an argument to some command, but the command is the value of an empty variable <crashcrash>roptat: Thank you for your advice. But the idea is that i want a complete development environment on my ARM pc. So i don't fell like compiling on another pc =) Well, just... Is there any way to run guix from usb drive <roptat>with guix build -K, the build directory of failed builds is kept in /tmp/guix-build-* <roptat>crashcrash: is your /tmp a tmpfs? <roptat>also, some arm devices don't support booting on usb <roptat>you could mount your usb drive to /tmp or point TMPDIR to your usb drive <roptat>(it needs to be defined for the guix daemon) <roptat>I don't think flash memory likes being constantly written to, though... <HiPhish>There is no `-ec` anywhere in the build directory. I think I have had enough for now, I'll give it a shot sometime later. Or find another shell script testing framework. <roptat>HiPhish: -ec is not a program I think, just an argument <crashcrash>roptat: Hmm... Just mount and.. that's it? What do you mean by "defined for the guix daemon". I'm sorry, i'm not very good at computing, system administration etc =) <HiPhish>roptat: I know, I was using ack to search the entire directory for "-ec" and that sequence of characters does not occur anywhere, not even as part of a word. <HiPhish>The closest match is "ec" as part of "echo" <roptat>mh... that will need more work... <roptat>crashcrash: if you mount your drive on /tmp, your tempdir will be as big as your usb device <roptat>if you define TMPDIR to be something else, you'll have as much space as what's available there <nckx>HiPhish: A guess: -ec sound suspiciously like common (ba)sh arguments, like $SHELL (or equivalent) is empty. <roptat>TMPDIR must be defined in the environment of the daemon, not your environment (usually in /etc/systemd/system or someting) <roptat>the simplest thing is to mount your drive on /tmp though <nckx>crashcrash: You can also not mount /tmp at all, so it's backed by /, if your / is big enough. That's what I do. <HiPhish>There is the line `reconf SHELL "$SH"` <nckx>HiPhish: No idea what reconf is (what I've seen so far makes me fear the answer), but you can try setting SH[ELL] to (which "bash") like you did for PATH. <nckx>Most packages are not this much work, by the way :-) <crashcrash>roptat: Thank you, I'll try mounting not the whole drive on /tmp but just some dir of it. <crashcrash>nckx: thank you) but it's better to me to use usb drive =) <HiPhish>Is this a safe thing to do? I don't know which other arguments one has to pass to make to work well for Guix. <nckx>HiPhish: It's not make, it's this package. <HiPhish>nckx: What is not make? I mean the arguments I am passing to the make invocation in the `build` and `install` phases. (line 30 and 36) <nckx>HiPhish: Looks good. Bonus Internet points if you can now move SHELL= to #:make-flags. <crashcrash>roptat: I have a new problem =) "umount: /tmp: target is busy" What can i do?) <nckx>HiPhish: I meant that 'make' itself 'work[s] well for Guix', but this package does not-ideal things. I think my previous line should answer your question nicely! <nckx>And removes the need for custom phases. <HiPhish>nckx: Yes, I think I can take it from here on. Thank you. <crashcrash>ncxk: Maybe you know what to do with "umount: /tmp: target is busy" =)) <roptat>crashcrash: maybe just mount over /tmp without unmounting first? <roptat>(it may break some things though) <roptat>otherwise, change /etc/fstab and reboot <roptat>(or maybe /etc/systemd/system/tmp.mount or something similar) <nckx>crashcrash: I'd overmount cuz I'm gangsta like that but you can use fuser or lsof to find and kill the culprit if you're curious. <nckx>(crashcrash: Many IRC clients tab-complete nicks, by the way.) <crashcrash>Guys do you know can i mount a dir on /tmp? It fails cause /some/path/tmp is not a block device <civodul>doesn't "mount -t TYPE /dev/something /tmp" work? <civodul>normally there's nothing special with 'mount' on GuixSD <crashcrash>nckx: thank you, but do you know why i can't see that it's mounted in "df" output? <nckx>crashcrash: I see... df just doesn't seem to consider bind mounts its purview. I can understand that. <nckx>'df''s purpose isn't to show mounts; use 'mount' for that. <mbakke>crashcrash: Any reason in particular you don't want to use binary substitutes? Building all of Guix on armhf will take a looong time...at regular intervals. <g_bor>crashcrash: A bind mount is equivalent to the original, df can even choose the name it displays. <crashcrash>mbakke: Hello! Actually there's no serious reason. The only reason is just to get some "freedom", you know =) <mbakke>crashcrash: That's a fine reason :-) <mbakke>crashcrash: I would recommend getting an external hard drive and point guix-daemons TMPDIR that way. Otherwise you'll tear out the internal storage rather quickly. <crashcrash>g_bor: HI! Didn't understand what do you mean exactly. It is equivalent to the original what? Just maybe you use some different words =) <crashcrash>mbakke: oh, yeah, thank you =) But is it somewhere in the manual where i can find how i can do it? <mbakke>crashcrash: If you are on a foreign distribution (not GuixSD), you can edit the guix-daemon startup file to set the TMPDIR environment variable. <mbakke>E.g. for systemd: `Environment=TMPDIR=/mnt/external` <nly>guix pull: error: Git error: the SSL certificate is invalid, why? <ecbrown>nly: you probably have to set GIT_SSL_CAINFO <crashcrash>mbakke: you know, i'm just not sure how to do this, maybe i ll try to find out by myself first =) <nckx>crashcrash: Which file system + mount options did you use for your hard drive? <roptat>what command did you run before trying running guix once more? <nckx>We're a diverse bunch over here. <ecbrown>that form of "people" is caustic, better imo to omit it <crashcrash>nckx: file system of my usb drive is ntfs and only options are -o bind <mbakke>crashcrash: The exact way to do it depends on your distribution. But don't be afraid to ask specific questions :-) <nckx>crashcrash: You'll need a Unix fs. <nly>ecbrown what should I set GIT_SSL_CAINFO to? I Can't seem to find it in the manual. <mbakke>crashcrash: Are you able to format the hard drive with a different file system? <crashcrash>mbakke: i'm afraid. no =) I store there my personal info =) <crashcrash>Well, i'm just thinking about any other options....=) <nckx>Or somebody can teach you how to loopback (it's pretty easy, but I too must AFK again). <roptat>ok, it seems that loopback is a thing I don't know about :) <nckx>roptat: -o loop is short for loopback, no? BRB... <roptat>mh... not sure about how to do that... <roptat>dd if=/dev/zero of=<some file> bs=1M count=10000 && mkfs -t ext2 <some file> && mount -o loop <some file> /tmp <roptat>that will give you a 10GB filesystem stored in a file <roptat>that file can be stored on your harddrive <roptat>nckx: that's what I call a loop device (loopback is associated to the lo network interface in my head) <ecbrown>hmm... ghostscript is not compiling. i noticed there was a big change <mbakke>ecbrown: Oh no. Which .drv is failing? <ecbrown>/gnu/store/gspa79qdaaihgxhs27iv2kk1d5qw3gab-ghostscript-9.24.drv <mbakke>ecbrown: That's odd.. What hardware are you on? <ecbrown>checking whether we are cross compiling... configure: error: in `/tmp/guix-build-ghostscript-9.24.drv-0/ghostscript-9.24': <ecbrown>i have messed around with --target=i686-linux on the commnad line, i don't know if that introduced something <mbakke>ecbrown: So you get that error simply by running `guix build ghostscript`? <mbakke>ecbrown: --target takes a triplet such as "i686-unknown-linux-gnu" and creates a cross-compiling toolchain. Apparently our ghostscript does not support cross-compiling. <nckx>...back. roptat: Mmm. Pet peeve. Lots of pedantry on the subject (not from you) but it never holds up to the slightest scrutiny. I can accept that 'loopback' is ambiguous, but it's never wrong. Anyway, OT. :-) <mbakke>ecbrown: But you probably want to use --system=i686-linux instead <mbakke>Which creates "native" i686 binaries, instead of cross-compiled. <ecbrown>mbakke: do i have clean them out? i think i've probably mistyped that before <mbakke>ecbrown: I see. I should have noticed from the .drv. I don't know what may be the issue then. <mbakke>ecbrown: Do you have $GUIX_BUILD_OPTIONS set by any chance? <mbakke>Hmm, no that would create a different .drv too. *nckx kind of raged into that subject. Ignore it. Any luck, crashcrash? <mbakke>ecbrown: Can you upload the config.log to paste.debian.net ? <ecbrown>mbakke: one sec, now i have something building if i specify --no-build-hook <ecbrown>damn i falling apart here. it is still compiling on my laptop. let me slow down and get that config.log file <ecbrown>mbakke: i think it's a false alarm -- i had converted my /tmp into a tmpfs, undoing that everything is working <mbakke>ecbrown: Oh. Perhaps you didn't have enough memory or something? <mbakke>TMPDIR on tmpfs is definitely supported. <ecbrown>pjotr prins had mentioned something about ghostscript now working on th bugs list. may or may not be unrelated *janneke is looking to build binutils-2.30 real early on, to create reproducible archives <janneke>ld needs a c++ preprocessor, really? <civodul>janneke: there's no "C++ preprocessor", is there? it's the same thing as the C preprocessor, no? <janneke>i think so, but configure verifies it can process conftest.cpp and tcc -E chokes on that <janneke>although, configure listenes to CXXCPP... *janneke tries patching ld/configure <janneke>okay, we can build binutils-2.30 real early on, using tcc and binutils-2.20 -- i guess that's what we want <janneke>i've been looking at updating gcc to 3.0 and 3.4 again..but i'll leave that to later <janneke>now that the bootstrap starts to work, let's see if we can make it reproducible maybe <janneke>ugh, we can build binutils-2.30 real early on, but we cannot build glibc-2.2.5 with that version <roptat>janneke: I think glibc, gcc and binutils versions are somewhat coupled together, no? <roptat>like you can't use any version of one of them with any version of another one <janneke>roptat: yes and no -- using contemporary versions 'always works' <janneke>it's just so terribly frustrating that binutils and gcc seem not to follow the GNU standards of an INSTALL file that lists requirements <janneke>binutils-2.30 build fine with tcc and mes c library, but seem not to build with gcc-2.95.3 and glibc-2.2.5 <bavier`>is that a standard? afaik the INSTALL file of many projects is just the template from autoconf <janneke>or at least, as a developer i don't find that very helpful :-) <janneke>okay, i'm giving up -- i'll have a look a backporting the reproducible patch to binutils-2.20 <g_bor>is there a chance to build a later one? <janneke>g_bor: sure, binutils-final is just like it's supposed to be <janneke>possibly that's good enough for now? <janneke>in fact, i think binutils-cross-boot0 is already 2.30 <janneke>i was just seeing if i could do something useful :) <jonsger>civodul: libreoffice should build fine, at least on x86_64 <g_bor>I mean would that be possible to jump to a later glibc that builds with the new binutils? <g_bor>can I have a look at the work in progress somewhere? <janneke>g_bor: all i really have is in wip-bootstrap right now <janneke>my wild experiments from today all failed -- but we may not need them <janneke>iwbn if we can find real work that needs to be done on wip-bootstrap before it can be merged <janneke>so, if you can build it, that's already nice <g_bor>ok, this morning I managed to get my guixsd into shape again, so i am back to the circle... <janneke>you may want to start simple, try: ./pre-inst-env guix build mes-boot; ./pre-inst-env guix build gcc-mesboot; (that's already the biggest hurdle) <janneke>and after that, be bold and try building `hello' or walk down commencement.scm <janneke>g_bor: please be sure to nag me with any questions <joehillen>there seems to be a formatting issue with `man guix-system` <g_bor>my network keeps going down. <nckx>joehillen: I don't see anything obviously borken. What am I looking for? <nckx>joehillen: You're right. Same here. It was just far less obvious at my terminal width. Would you mind filing a bug report? <nckx>Our man is not in the best of shapes. <bavier`>we use help2man, so it might be an issue there <georges-duperon>Is there something like apt-file to know which package provides a command? <nckx>ls /gnu/store/*/*bin/foo on your CI box ;-) <nckx>That only works if you already have the package installed, which isn't usually the main use case for apt-file. For me, anyway. <georges-duperon>Not quite enough for stuff that's not installed yet, but now I know that halt is provided by shepherd :D <joehillen>how do y'all hack on a local guix clone on GuixSD? <joehillen>is this on the right track? guix environment guix ; ./bootstrap ; ./configure --localstatedir=/var <pkill9_>joehillen: you do a git clone of it and then configure and make, then use the 'pre-inst-env' script it generates <pkill9_>it says in the manual somewhere i think <nckx>joehillen: I throw in a --sysconfdir=/etc too. Maybe that's no longer needed(?). <joehillen>it's building now, so I guess we'll find out <nckx>It might look in /usr/local/etc otherwise. <roptat>I think it's irrelevant as long as the daemon has the correct config <roptat>but I use it too just in case ^^ <nckx>roptat: Does 'guix archive --authorize' &c. go through the daemon too? <roptat>but they need root previledges, so I wouldn't use a checkout for that *nckx has never guix pulled as root. And only as me by accident... <nonzen>Hello, what can I do about this error: "guix pull: error: Git error: the SSL certificate is invalid" <nonzen>joehillen: no, just trying out Guix on Fedora <g_bor>reconfigure competed without errors... :) <nonzen>pkill9_: That worked. Thank you! <g_bor>istm we don't have irc logs. is that correct? *g_bor trying to build the bootstrap <georges-duperon>g_bor: there's also another website that has logs with a web interface instead of downloading .txts, but I can't find it anymore. <ng0>georges-duperon: that one is in move <ng0>meaning, I have to find time this month to set it up on the new server and after that old logs will be made available eventually depending on factors outside of my control. <ng0>that's what I mean. bot crashed. move's not finished, which is why no new email and blog post has been written about this <ng0>basically gnunet-historian is logging for a while now since the old bot crashed <g_bor>Oh, sorry to hear that. And I was also sorry to hear about your personal problems. I hope you can get these resolve. <ng0>on the frontpage, there's this: https://gnunet.org/node/2669 this outage was the final nail for us, we're mid-way in moving infrastructures, website, server, etc <ng0>Drupal IRC Bot? Totally not recommended. <nixd>Hello, is it possible to have a display-manager-less login, and start x manually? Startx returns that it cannot find the xserver. I do have xorg-server and xinit installed. The manual also states that there is no xserver service and that x is started through a display manager, which I don't want. Any ideas? <cacatoes>nixd: [not sure at all] tried running xinit directly? <nixd>cacatoes Yes, same result as with running startx <nckx>nixd: I remember this exact topic on one of the guix-{devel,help} mailing lists very recently. Search the archives for startx. <thorwil>hi! new system, new attempt at testing changes to packages with a local source tree <thorwil>now `./configure --localstatedir=/var` failes with "No Guile development packages were found." within a `guix environment guix` <thorwil>wasn't the point of the guix environmnet offering everything required? <g_bor>trying to build wip bootstrap, I got a consistent failure downloading gcc-4.9.4.tar.bz2, TLS error error in the pull function. Anyone else noticing this? <rekado>thorwil: if you’re doing this on a foreign distro maybe try “guix environment --pure guix” instead. <sneek>rekado, you have 2 messages. <sneek>rekado, ng0 says: I'm sorry. Lately I'm under lots of pressure in personal life and I try very hard not to make this show in how I write. <sneek>rekado, ng0 says: I had no knowledge of the email about the same subject btw, so now I understand. <thorwil>rekado: foreign distro, yes. `guix environment --pure guix` has the same result: "No Guile development packages were found." <rekado>thorwil: could you show us the configure output? <rekado>what does “which guile” say within that environment? <thorwil>rekado: in `guix environment --pure guix`: Command 'which' is available in the following places * /bin/which * /usr/bin/which <thorwil>The command could not be located because '/bin:/usr/bin' is not included in the PATH environment variable. <thorwil>if i drop --pure: which guile -> /gnu/store/2w5kxhmkq4zkamsgx1b40vr3ii1z4dxb-profile/bin/guile <rekado>could you please paste config.log then? <rekado>maybe PKG_CONFIG_PATH is incorrect. Could you please also share the output of “env”? <janneke>downloading 4.9.4 means you've built already quite a lot! <thorwil>rekado: which includes: PKG_CONFIG_PATH=/usr/local/lib64/pkgconfig:/usr/local/lib/pkgconfig:/usr/lib64/pkgconfig:/usr/lib/pkgconfig <rekado>something must be overwriting whatever Guix is setting. <rekado>this could be the result of setting things in ~/.bashrc instead of ~/.bash_profile, for example. <efraim>looks like my quaasel server took a nose dive *thorwil reads up on .bashrc vs .bash_profile <ngz>rekado: You suggest to export variables in .bash_profile? For some reason I thought .profile was better. <rekado>ngz: either way is fine; .profile is for all shells IIUC. <rekado>the point is just not to add things to .bashrc that “guix environment” may want to set. <rekado>.bashrc is evaluated for every shell, including the subshell that “guix environment” spawns. <thorwil>i moved setting PKG_CONFIG_PATH from .bashrc to an up tot this day non-existent .bash_profile <thorwil>new terminal and now `./configure --localstatedir=/var` is happy <thorwil>well, happy except the "ERROR: ld.so: object 'libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored." i get to see all over the place, though that is likely an issue specific to ubuntu 18.04 Unity Edition :} <rekado>thorwil: you probably should not set LD_PRELOAD at all. <rekado>it would be weird if that was the default on Ubuntu <thorwil>oh, it's: LD_PRELOAD=libgtk3-nocsd.so.0 <thorwil>the origin seems to be /etc/X11/Xsession.d/51gtk3-nocsd-detect <g_bor>mes-0.17.1.tar.gz 404-s on alpha.gnu.org... <rekado>there’s something weird going on with hash mismatch error messages <rekado>the lines that come from the daemon include “\n” <rekado>I’ve just fixed the filtering for “guix package” locally, but for “guix build” it’s still wrong. <rekado>(this has been the case for a long time) <rekado>I can’t see if the parentheses match, but yeah, that’s what I meant. <janneke>g_bor:oops, mes-0.17.1 only lives on ftp.gnu.org <thorwil>rekado: good. i still get the same exact error on trying to build azr3, though <janneke>oh, that's also broken on master...crap <g_bor>janneke: fine, thanks. I guess we could fix the download url in the definition, can't we? <janneke>yes, sure! patching on master in gnu/packages/mes.scm now <janneke>and cherry-picked on wip-bootstrap too <janneke>(we'll rebase later again onto master) <janneke>in a way i like such silly bugs ... sorry though! <janneke>i made the initial 0.17 release on alpha.gnu.org, or at least i tried that -- but I was strongly encouraged to put it on ftp.gn.org <thorwil>rekado: actually testing that has to wait until tomorrow :/ <lfam>That's with `guix build` <rekado>you see the message twice because that’s what nix/libstore/build.cc says should be done when tracing is enabled. <rekado>(that gives us the “@ build-failed” line, which we turn to “Build failed: …”) <lfam>The second time it's printed, the "expected" hash is blank <rekado>but I think it’s related to how the daemon chunks the error message. <rekado>that “@ build-failed” line should really be just one line <rekado>but it is not because in build.cc we generate an error message that spans more than one line. <rekado>I see that the first instance of the error message arrives in one big chunk at the soft port, including newline characters. <rekado>the tracer line, on the other hand, is split up <rekado>I can fix this in the “guix build” case by not attempting to process that line at all. <lfam>Hm, looks like the OpenSSL build process changed significantly in 1.1.1. There are no Makefiles... <myglc2>Hello guix ... what would cause "Build failed: /gnu/store/jrzyg48zm6pb6m0av3876a8vd57335ql-glib-schemas.drv"? <lfam>myglc2: Can you provide more context? <myglc2>Thanks lfam. I am building a manifest using the latest guix built from guix. <jonsger>is there another way to check for a build other then the hydra.gnu.org webinterface? <rekado>myglc2: this looks like a profile hook. In any case you should be able to do “guix build --log-file /gnu/store/jrzyg48zm6pb6m0av3876a8vd57335ql-glib-schemas.drv” to get the log file for that failed build. <myglc2>rekado: Thanks. It shows me 'no code for module (guix build utils)' <rekado>are you perhaps using a very old version of Guix or the daemon? <myglc2>rekado: The guix is freshly built and run from ./pre-inst-env but I am using a vm-image from July 29. <myglc2>rekado: So is it time to make a new vm-image? <myglc2>rekado: The daemon was built from the Jul 17 commit 86da991f4 <rekado>what version of Guile do you use? <rekado>lfam: the hash mismatch output problems should have disappeared now. <rekado>myglc2: could you write to help-guix with all that info please? I need to leave now. <lfam>Cool, thanks a lot rekado <ng0>lfam: huh. apparently generated by ./config now <lfam>ng0: Yeah, and I missed the real error which was that ./config failed but the phase succeeded <lfam>Should be fixed in the update patch I sent to guix-patches a few minutes ago <noobly>does guix(SD) have an equivelant to gentoo's use flags? <vagrantc>you could probably build from a tweaked version of guix, but then you'd end up rebuilding everything ... probably even more often than with gentoo, as i understand it <noobly>so there's no equivelant global config system that accomplishes the same thing? <noobly>same thing being like the ability to build packages depending on my custom use flag configurations (i.e build x without support for y) <lfam>noobly: Currently it's not supported out-of-the-box like in Gentoo. There are some related tools, but nothing comprehensive <lfam>Also, there is a thing called 'package-input-rewriting' that you'd use when defining packages <noobly>lfam: ok, thanks for the info. I've heard some say it's even easier with guix, while others saying it does not exist so I wanted to clarify for myself. At any rate, I'm on old hardware so optimizing is very helpful, but I'm still going to be trying guixsd on this machine - I didn't buy an etheros wfi card for nuthin' after all :-) <lfam>But, none of these really apply for full-system configuration as with GuixSD <lfam>With Guix it's certainly possible to implement these features, not least because it's built with Guile Scheme, so you have a full language at your disposal. <lfam>How it would look in practice, I don't know, especially because I've never used Gentoo <lfam>And of course, it would be impractical, maybe impossible, to offer pre-built "substitute" for these transformed packages. For some people that's important, others don't mind building lots of stuff 