<civodul>i think it won't use your local machine, except for #:local-build? derivation <civodul>that's because "guix offload" replies "decline" only when it has no matching machine <cbaines>Ok, that makes some sense. I guess I could add the local machine in to /etc/guix/machines.scm, but it doesn't fit very well <civodul>yeah, that'd be ridiculous (ssh and all) <civodul>on the build farm, the current behavior makes sense because you don't want to build on the front-end <jonsger>is there a command to find in which file a package is packaged? <civodul>but in other situations, it may not be what you want <cbaines>In other news, I think I've made some progress with the ISO installer today! I'm trying on a Bytemark VM again, and seeing if I can get the test to pass. <civodul>cbaines: excellent, i was about to take a look, so maybe i don't need to :-) <cbaines>I'm currently waiting on the VM to build perl for some reason, and the test is busy compiling guile modules <civodul>BTW, when testing locally, it may be enough to use 'guix' rather than 'current-guix' in the tests <cbaines>Yep, I've been doing that today, makes iteration far faster <jlicht>hmm, I am getting a backtrace on `guix package -A hello' (or any package -a command actually) <cbaines>I've got to the point now where I have some rudimentary way of running guix-register, so I'm testing with current-guix to see what effect that has. <jlicht>nvm, lfam already fixed it in current master. Guix' speed at fixing bugs sometimes exceeds all expectations <jonsger>how long will inkscape be builded... :) <civodul>cbaines: is there something wrong with guix-register? <cbaines>At this point, I don't know how to use it correctly, I tried a few things, and kept getting the following message: error: number expected <civodul>see the 'register-path' procedure in (guix store) for an example <cbaines>civodul, I do have some good news to report though, the ISO test has just failed at the parted stage! <cbaines>Error: Could not stat device /dev/vdb - No such file or directory. <civodul>that may mean we lack the proprer virtio driver no? <cbaines>Maybe, my current guess is that using the ISO means that the device addressing is different, so I'm going to try using /dev/vda <cbaines>I think I've got something working with the ISO installer... "Installation finished. No error reported."! <cbaines>I've also successfully used it to install GuixSD on a Bytemark VM :D <cbaines>with some changes I've been making today, I'll hopefully submit a patch once I've slept a bit ***OneBigMes is now known as NullConstnat
***NullConstnat is now known as NullConstant
***OneBigMes is now known as NullConstant
<efraim>mate-icon-themes doesn't even refer to itself <efraim>guix gc --references $(guix build mate-icon-themes) is blank <efraim>its been really quiet here today <efraim>i know sundays are normally quiet but this feels more than normal <cbaines>efraim, maybe those who were at the GHM last weekend are having a rest this weekend :) <ng0>hey, efraim. I read there are some issues left with the mate patches? Maybe it's easier if you could throw me the issues here. <ng0>cbaines: I think it's safe to say at this point that you mail never arrived at my postbox, or did you get a message that it couldn't be delivered? I still have hope that it's just "stuck" somewhere, but UK -> DE isn't that much of a distance <ng0>maybe the sorting "machine" picked it out for themselves <ng0>efraim: but the mate-icon-themes problems has to be older than my work, I didn't add it I think. <ng0>wre can solve it nevertheless <ng0>it is "mate-icon-theme" not -themes <efraim>I actually worked on them a bit earlier, just have to export the patches to make sure they're still good on the UI front <cbaines>ng0, that's irritating. On the bright side, I have some more sticker sheets now, as I got some more printed before the GHM. <ng0>Maybe I'll be at CCC congress (hope I can make it) or at Fosdem next year. <ng0>The sorting "machine" in-joke is a bit annoying.. you really have no way to blame the Deutsche Post when the mail gets lost on the way unless there's an insurance on it and even then you could have problems. -.- <ng0>aka person opens your mail and takes the content, people that should not work at post offices but still end up doing it.. trust.. yeah. <ng0>but 99.99% of the time I had no issues. the .1% sucks <jeyll>using this config (customised to my name only) <ng0>and what's the error? <jelly_>ice-9/boot-9.scm:1700:9: ice-9/boot.scm1700:9: In procedure scm_i_lreadparen: /mnt/etc/config.scm:62:1: end of file <ng0>you might have a paren too much <ng0>line 62? is this not everything you pasted? <efraim>i think line 12? with coreutils needs another right parenthesis <ng0>jelly_: in any case, "In procedure scm_i_lreadparen: filename.scm:line:position: end of file" usually indicates a problem with parens. <efraim>the config as posted works for me with `guix system build' <jelly_>I had some comments I didn't take out <jelly_>with them removed it is lines 52:1 <ng0>oh, :1: is not the position, sorry. I just haven't memorized what it is <ng0>are you sure you haven't added anythin else in addition to the comments? <jelly_>is there supposed to be a bracket to end the file? <ng0>thanks efraim! I'll see that I review your review after the movie is finished in about 2 hours. That's the computer that is used to display the movie and runs Mate for a while now <ng0>is there something like @file{} but for directory in Texinfo? <ng0>ah, it's still @file then <catonano>what's the situation with the Rust build system ? Soon it will be required to build Gnome <ng0>I have a link somewhere to open issues, but could be that the situation is changed in the meantime <ng0>git add gnunet-c-tutorial.texi <jelly_>would really appreciate someone looking over my scm. thanks. <jelly_>also, i fixed my internet drop out isse <ng0>you don't need mapped-devices if you have no mapped-devices <ng0>or did you remove that? <jelly_>i have removed it now, but have a new error! <jelly_>In procedure scm_i_lreadparen: /mnt/etc/config.scm:48:1: end of file <ng0>is that your first system? if so it might be easier to just start with a very basic config and then configure it from the other one <ng0>*from the configured one <jelly_>This is based off the default desktop scm <jelly_>I have only removed the LUKS lines <jelly_>ng0: do you see any errors other than the mapped-device line i have removed? <ng0>I'm sorry, I can't help you right now. You could have removed the whole line with mapped-devices in which case you have an open (file-system which needs to be closed <ng0>instead of (type "ext4") <ng0>I have to review and test something now <ng0>it helps to have some parens highlighting editor or just count the parens to see if there are too little or too many <ng0>efraim: why this change: <ng0>- `(#:configure-flags <ng0>+ '(#:configure-flags <ng0>I see nothing it would affect <efraim>I think there might be a scheme based reason that I don't remember <ng0>I think I'll comment inline in the email, it's easier. the format works better than last time, I just have to move the code around and rebase with your changes. I think there are 1 or 2 patches which are individual contributions you made/found. Would you like to add them after "mate"? <ng0>there's nothing to comment though… just the one or two patches you made which are not part of my patch set <ng0>I prefer it when people get their name as authors <efraim>I pushed a couple of the patches, I don't remember which ones would be mine though <ng0>all in all looks good so far, now I just need to shove code around and build a system on this <ng0>I know which ones are yours <ng0>but I need to doublecheck <jelly_>ng0: thanks again because I've got it working and am starting to understand the syntax <jelly_>this is a really helpful channel :) <ng0>efraim: it is difficult. it makes sense to move the "mate-themese" patch right after my mate-themese update patch for example. <ng0>although I made some changes in mate-themes <ng0>I'll justr take my time to read now <ng0>efraim: I will merge your "mate-themes" change into my 2nd patch and add a line for you <ng0>sorry. it: mate-themes <efraim>I pushed that one already. Configure.ac specifies gtk2 <ng0>will this work with the rest of Mate only-gtk3? <ng0>will you push more of them? Because I just had started rebasing.. Would be great to know if I should wait or work. <ng0>okay I see there have been some commits.. I'll adjust my way forward. <efraim>i pushed the https patch, mate-icon-themes, mate-themes, mate-desktop and libmateweather <ng0>5804c7b616a39c05280aaabf3cec753db5fc6002 is the last? <ng0>do you think we should mention the "is a fork of …" notes in the descriptions? That's just what upstream uses, and with one package that's even the only description <ng0>right now they are there, but I had mixed feelings about them <ng0>imo they are not necessary <ng0>done. Now I just need to reconfigure a system <ng0>efraim: I'll send the updated series when the build of the system is done, should still happen today. I'm off from irc now. Good night <Steap>/home/cyril/.guix-profile/lib <Steap>and both crti.o and crt1.o are in $LIBRARY_PATH <civodul>Steap: you need to install 'gcc-toolchain' as opposed to just 'gcc' <Steap>I installed gcc-toolchain, and I'm still getting the same error when trying to compile C programs :/ <rekado_>Steap: make sure to actually remove the “gcc” package or else you might still be using it instead of “gcc-toolchain” <Steap>when would one use the "gcc" package then? <Steap>my /home/cyril/.guix-profile/lib/crt1.o points to the file installed by gcc-toolchain <Steap>oh but strace show ld looks for crti.o in /gnu/store/b3z4d4zjibqix6pn58q6b1rgfhrarcaq-gcc-7.1.0-lib/ <civodul>Steap: do you still have binutils/glibc or something installed in addition to gcc-toolchain? <civodul>Steap: can you try compiling in "guix environment --ad-hoc gcc-toolchain -C"? <Steap>should all my glibc and gcc patches be removed as well? <lfam>ACTION goes crazy trying to figure out the fine points of Golang package references <lfam>They have a concept of "internal" packages that may not be referred to by packages under a different namespace. But they offer a mechanism to short-circuit that: vendoring (aka bundling). So package authors have created so-called internal packages separately from the packages that are supposed to use, presumably under the assumption that everyone will bundle them :( <sneek>Welcome back lfam, you have 1 message. <lfam>So the trick is to figure out how to set up the directory structures and "GOPATH" variable to make it all work. <lfam>Symlinking the internal package into the referring package's build tree works, but actually copying it does not work <lfam>But the whole falls apart anyways when you have to deal with these internal packages transitively <oriansj>sounds like they lost their mind lfam <lfam>Maybe. I might also be misunderstanding it <lfam>I guess I have to read the Nixpkgs code <civodul>Steap: all your glibc and gcc patches? or did you mean "packages"? <civodul>lfam: you're our hero, keep up the good work! :-) <Steap>civodul: the old derivations mostly <Steap>because ld seems to try to open crti.o from those places <lfam>Go is generally a bad fit for our way of doing things. There is no concept of "versions", and not even a strong concept of a coherent software release. It's typical to cherry-pick parts of a given Go library suite <lfam>I guess we'll see how we should adapt as we try adding more Go software <lfam>I haven't seen any top-level build scripts in these library suites; you're expected to build each module individually as needed <lfam>Also, the package names are way too long <lfam>"golang-github-com-cznic-internal-buffer" <oriansj>lfam: so treat every go program as having no libraries and only a single source pool? <lfam>Can you clarify what you mean? <oriansj>if every module is built as individually needed, simply don't seperate them into seperate things. <oriansj>statically compile the programs and the libraries into a single blob <oriansj>it'll waste disk and probably make a build issue whenever a security bug needs to be fixed but it looks like go took the java route of bad system engineering <lfam>I've considered that but it would require a substantial amount of extra logic on our side, and it's not "idiomatic" for Go. <lfam>I think I may have to go back to the original plan, which is to create a symlink union of all the Go dependencies at build-time. Since the GOPATH variable can contain multiple entries, I'd hoped to avoid that, but the multiple entry GOPATH seems to be only partially supported in practice <lfam>But that complicates code reuse later on