<lfam>catonano: I just built commit 0d7feebb622b0cf54ab435f308df347008d945b3 (latest HEAD) from scratch. From your backtrace, it seems that you are trying to use the variable 'gcc' without importing it or declaring it. <lfam>catonano: Are you building with a "clean" work tree of a Git commit from our repo? <catonano>lfam: I thought so but now I'm cloning a new copy and try with that <lfam>catonano: Something to look out for is stray *.go files. As modules come and go, they might not get deleted by `make clean-go` or `make clean` <lfam>And remember to use a '--pure' Guix environment :) <catonano>lfam: so the fresh clone should fare better <lfam>`make clean-go` should report left-over compiled Guile objects, but I know that nobody reads those messages :) <lfam>`guix environment --pure guix` <fogbugz>Hi, does anyone run X without a display manager (ie plain startx) and non-root? I'm transitioning from a systemd-based distro to guixsd and i suspect maybe the lack of logind is giving me trouble here, as I can't startx with non-root users. <lfam>fogbugz: FYI, we use elogind to replace logind <lfam>But, I don't know the answer to your question, sorry <fogbugz>lfam: ok, i didn't know that, thanks for the tip <fogbugz>browsing irc logs ive seen some guix users pointing this issue too. <lfam>It would be nice to get an answer, once and for all :) <fogbugz>well it might be just how things are, till recently most distros had the same limitation <lfam>It's actually how I like to do my graphical systems. On Debian, I boot to the console and startx if I want <lfam>I would like to learn how to make it work on GuixSD <fogbugz>as u say starting in text mode has some advantages, eg to fire mutt or gnus quickly for an email <lfam>catonano: From within that environment (with the [env] in the shell prompt), please share the results of `env` on paste.lisp.org, taking care there is no sensitive data <catonano>lfam: I had already exited from that env so I'm running it again <katco>lfam: i found sbt 0.3 which looks as if it uses scala to build. scala 2.9.2 uses ant... i might be onto something! lol <lfam>The errors about cairo and mount are expected <lfam>I'm not sure about the read-pid-file errors <roelj_>My fonts broke on GuixSD.. Any ideas on how to fix it? <lfam>roelj_: Did you recently run `guix gc`? <roelj_>lfam: Yes.. And then I did a guix system reconfigure to try to fix it. <lfam>At least do `guix build fontconfig --no-grafts` to get the missing binary back in your /gnu/store. Even better is to make sure it stays around: `ln -s $(guix build fontconfig --no-grafts) /var/guix/gcroots/fontconfig-grafting-bug` <lfam>The last element of that path is up to you, of course <lfam>We are currently working on the core-updates cycle that will deploy a fix for this issue. Please help if you want it to happen more quickly. <lfam>I recommend reading the *entire* thread of that bug. It's pretty serious <lfam>My instructions fixed the visible part of the issue for me immediately, but who knows about invisible effects <lfam>I first noticed it in my terminal emulator, and as I garbage collected and rebuilt the store item I could spawn new terminals and see the difference <lfam>Mark is the hero, but investigating that bug with skill and speed <roelj_>I don't understand the issue entirely though <roelj_>Is this only related to grafting? <roelj_>ACTION needs to restart Emacs to fix the fonts.. <lfam>roelj_: I was around as those emails starting coming in, and I found it difficult to understand at first. But I read them closely and grokked it. I can give another explanation if you want, but Mark's is really clear, IMO <lfam>I guess you have to understand what grafting *is* to see the problem <roelj_>So, a graft is a binary mutation on a package build.. but in the case of fontconfig, some things still referenced to the original fontconfig? <roelj_>So, basically, the graft was incomplete <lfam>Not only that, but garbage collection is broken too, as you noticed <lfam>The issue is that Guix and Nix scan built packages for store references such as '/gnu/store/deadbeaf...-fontconfig-1/' <roelj_>Hmm, but if the references to the original fontconfig would not be there, the garbage collection would be fine, right? <lfam>GCC sometimes breaks that string into chunks, so our scanner can't find it <lfam>Sure, but consider a program foo that refers to the library bar. If all the references to bar were chunked, the reference would not be recorded in the database at all, and bar could be garbage collected <roelj_>That complicates things quite severely <lfam>So, on core-updates we applied a GCC patch to disable this chunking optimization for strings that begin with '/gnu/store' <lfam>Commit 8033772363b287ca529461e575ceb4a69d7af942 <roelj_>Well, that's nice. Any downside to disabling this feature? <roelj_>Is this some micro-performance optimization? <lfam>Well, we only disabled it for a specific string. I guess we lose a bit of optimization in our binaries. <lfam>It can still be used for other strings <catonano>Just a small interruption: make check passed. Had I an allucination ? <lfam>We can never be sure that software builds reproducibly in all cases. We can only know that it doesn't, when it doesn't. <lfam>Maybe there's a race somewhere <lfam>Please report it if it happens again <roelj_>lfam: Thanks again for all the help. By the way, I succesfully installed GuixSD with EFI and a btrfs root. Initially, I needed a Fedora LiveUSB to do the EFI configuration, but guix system reconfigure does the right thing automatically now. I had build my own USB image of GuixSD with the latest btrfs patches in. <lfam>I usually do the same thing (build my own image) <katco>i'm stuck trying to get ant to build scala. it's complaining "Cannot run program "/gnu/store/symrs6x31i1pzlsfc8vs089mg06hqn3s-ant-1.9.6/bin/antRun" and i don't really understand why it's looking for antRun? full disclosure, not that familiar with ant <katco>will have to look at this later, but it looks like the exec task is trying to use the antRun script which for some reason isn't present in guix's version of ant <luser1>I've installed the package geoclue which provides a configuration file in ~/.guix-profile/etc/geoclue. From looking at the files permissions, I can see GuixSD telling me it doesn't want me editing this file so what is the GuixSD way of modifying this configuration file? <roelj>How can I remove a system generation in GuixSD? <jmd>roelj: I don't think it is possible (yet). <catonano>roelj: thomasd asked the same questiona few days ago and found a workaround <catonano>roelj: I don't remember whhich one thogh. You'll have to ask them <roelj>Well probably just manually remove the generation from /var/guix/profiles/system/profile :) <thomasd>well, from /var/guix/profiles, to be exact <thomasd>I actually sent a patch to add a “guix system delete-generations” command to guix-devel recently, but it didn't get a lot of attention <thomasd>also, it's a good idea to reconfigure your system after deleting a profile, to update the grub boot menu. <roelj>thomasd: Ah, when I'm settled with GuixSD, I have time to read the mailing list again :) <thomasd>I also thought: “I'll switch to GuixSD, I'll have more time to do Guix-stuff.” But then you start tweaking and tweaking, ... :) <roelj>Any idea how to start libvirtd? <thomasd>(not that my patch was particularly good, but I was hoping for some comments on how to improve the grub issue :). Anyway delete-generations is not urgent, though the fact that it's missing is kind of silly.) <catonano>roelj: I'd love to know how to deal wit libvirtd too <thomasd>catonano: did the adwaita-cursor workaround work for you? <rekado>Hi Guix, I’m at BOBKonf 2017 now. Giving a talk on Guix at about 3pm. <catonano_>thomasd: yes it did ! I wrote to the help mailing list about it ! <rekado>the slides can be found in the talks/bobkonf2017 directory in the guix-maintenance repository. <rekado>sneek: later tell lfam Thanks for pushing the fix! <rekado>sneek: you want a botsnack? Come and get it! <wingo>is epiphany in master broken for anyone else? <wingo>i get this on the console: /gnu/store/mby6449ygp4s74xf3hgbgqzwvzccx3k7-webkitgtk-2.14.5/libexec/webkit2gtk-4.0/WebKitWebProcess: symbol lookup error: /gnu/store/dgz1p150n6ffs54qq4rzyh9fx26lrsad-libx11-1.6.4/lib/libX11.so.6: undefined symbol: xcb_wait_for_reply64 <ng0>hi, I think 'guix' has a problem.. this is with the http_proxy set to "127.0.0.1:9050", just rebooted into it and tried to check my gnurl release: https://ptpb.pw/9a8K ***kelsoo1 is now known as kelsoo
<ng0>every guix * is now broken for me, I will try an older version of the system <catonano>wingo: not only that: it's exactly equal to "Web", that belongs to the Gnome desktop <wingo>catonano: cool, must be something about my older host X install on this nix system or something <wingo>yes epipany is the gnome web browser <catonano>wingo: I didn't know it before using GuixSD and I have to say thaht I'm impressed <catonano>for being a not mainstream browser it's quite solid ! <ng0>Maybe the proxy format was wrong. I'm not sure what guix wants.. or maybe socks5 has to be called differently <ng0>string for me means that (http-proxy "127.0.0.1:9050") is as correct as (http-proxy "socks5://127.0.0.1:9050"), from the documentation is see not limitation <katco>is anyone familiar with ant? guix's ant removes the antRun script which appears to be required for some exec tasks. the ant manual says "...the underlying OS's shell, either directly or through the antRun scripts, will be used", so i'm trying to figure out why it wouldn't use the native shell <braunr>katco: i'd say that ant is naturally converging to a bug-free state, but then i'd have to immediately hide somewhere dark <katco>i should have mentioned i'm trying to package scala <katco>so my build is failing because of this <osmano807>I'm getting an error when guix tries to download a package, but it downloads fine with wget <katco>it looks as though scala's ant script attempts to pull needed libraries down through a script. i'm assuming i should package these things in guix and use those instead? <mvb>osmano807: which package is it? <osmano807>mvb: any package, I tried reconfiguring the system and installing new packages <osmano807>I would suspect a network error, but downloading the url via wget works <jmd>I need to patch an entire sexp in a scheme file. is there an easy way to do that? ***kelsoo1 is now known as kelsoo
<janneke>jmd: depending on where the sexp is, something like this may be useful? <janneke>echo '(foo bar)' | guile -c "(use-modules (ice-9 match)) (display (let ((o (read))) (match o (('foo bar) (list 'FOO bar)) (_ o))))" <fogbugz>Hi, how can i know if installing a package would lead to compilation or just downloading? I tried --dry-run for both guix package -i and guix build, but I couldn't easily tell. <lfam>fogbugz: --dry-run is useful, but it doesn't take grafts into account. Currently almost everything is grafted, At the very least, you'll need to perform the grafting, which is relatively inexpensive. <sneek>Welcome back lfam, you have 1 message. <sneek>lfam, rekado says: Thanks for pushing the fix! <katco>fogbugz: fwiw i run into that too. and confusingly, --dry-run still reports things will happen even immediately after performing -u <lfam>Since Guix is basically a build-from-source system that offers substitutes as an optimization, it's hard to know if you'll have to build until you try it. You could always CTRL-C after it prints the summary of what will be done and read it, but it should be the same as --dry-run plus the grafting derivations. <lfam>Maybe there are some dark corners in how it predicts things when grafts are applied... I'm not sure because I don't know that part of the code well <fogbugz>katco: ok, that has confused me quite a lot too. For example, i'm now installing icecat, and there's a lot of compilation going on. <fogbugz>lfam: but wouldn't it be easy to know which binaries are available from authorized repos? <katco>fogbugz: it sounds like lfam is pointing us in the right direction <lfam>fogbugz: Yes, that's what happens when you see the messages about updating lists of substitutes. But like I said, grafting happens locally <lfam>I *do* think this could be improved, but I don't know the thing well enough to know how :) <fogbugz>lfam: ok! i'll post to the mailing list <snape>does guix publish support https? <davexunit_>snape: you would want to put nginx in front of it and have that do the certificate stuff <snape>davexunit_: I see, thanks. Is https necessary for a public server, or is there already a security layer doing the job? <davexunit_>using https would be because it's no one's business what binaries you are requesting from the server. <davexunit_>and for that using nginx to handle the TLS certificate and reverse proxying to the 'guix publish' server would work well. <snape>Ok. I guess Bayfront uses nginx then. <davexunit_>the cache makes it perform much better when there's a lot of traffic <lfam>Using TLS is still a good idea, even when downloading signed files, IMO, although I'm not intimately familiar with how Guix hanldes the incoming substitute data. <lfam>And like davexunit_ said, you should put nginx in front of `guix publish` anyways. My understanding is that `guix publish` is not really optimized yet <snape>I think I'll do that. I'll have a look at guix/maintenance.git <lfam>Speaking of these things, I want to write something like a letsencrypt-service that would make it possible to spawn a new GuixSD system with `disk-image` et al that starts with a working HTTPS nginx server <davexunit_>I found the nginx config for the cache to be complicated so I wasn't able to replicate the setup for myself <lfam>I could help you adapt it if you want davexunit_. I was able to make it work by adjusting a few URLs and local paths <lfam>I guess the letsencrypt-service would have to work during the first boot, during activation. But that would still be better than what is my best idea for now, which is to create the image with an HTTP server, get the cert, change the nginx config, and then reconfigure. <braunr>lfam: signatures should be enough normally <lfam>If I work on this service, I will want to use acme-client instead of certbot, which I expect will be controversial :( <davexunit_>lfam: thanks. if I ever get around to it again I will ask you. :) <davexunit_>I haven't really had any desire to write code in quite some time. <lfam>Sure, I'll send you my patch series on maintenance.git if you want <lfam>braunr: As one of the people that maintains our certbot package, I think it's a bit of a house of cards. <lfam>It feels like we are always on the edge of not being able to build it <lfam>And I don't want to rely on software like that <lfam>It depends on a large number of lightly-maintained 3rd party libraries <braunr>lfam: i mean why controversial ? <lfam>There are cycles in its dependency graph <lfam>Oh, when I packaged acme-client, several people had comments about the fact that it's written in C. <lfam>Understandable, but I am somewhat more optimistic about the OpenBSD C code than most <lfam>Than most C code from other organizations, that is <lfam>I think we'd all welcome an implementation in another language that was simpler than certbot <braunr>i didn't know the acme-client was written by openbsd people <braunr>17:19 < davexunit_> we use nginx as a cache <braunr>davexunit_: to another server i suppose ? <lfam>A cache for `guix publish` <lfam>I haven't tried it, but my understanding is that `guix publish` can't handle large numbers of concurrent users efficiently <davexunit_>reading files off of the file system, writing them out in the "nar" format, over and over <davexunit_>it's a lot cheaper to do that *once* and stash the result on disk in a cache <davexunit_>so 'guix publish' stays simple and we can just use a frontend to optimize for high traffic. <braunr>but what configuration are you talking about ? <braunr>17:25 < davexunit_> I found the nginx config for the cache to be complicated so I wasn't able to replicate the setup for myself <davexunit_>braunr: I forget where it is, but the nginx caching configuration that we use for our production servers is publicly available in a git repo somewhere <lfam>braunr: It's here: git://git.savannah.gnu.org/guix/maintenance.git <davexunit_>I just got overwhelmed by it when I looked at it. <lfam>I'm trying to figure out if I clone it over HTTPS <lfam>Specifically, the file 'hydra/nginx/mirror.conf' <braunr>ok so that cache is indeed a proxy cache <nliadm>something up with bayfront? it keeps timing out <nliadm>and subsitute apparently doesn't fall back to the second server <lfam>nliadm: It's offline due to work on the hoster's power supply yesterday. I've just sent a message to somebody near the hoster for an update <nliadm>okay, I guess I'll just restart guix-daemon so that it can talk to hydra at least <paroneayea>btw davexunit_, you were talking about desktop recording / live streaming tools <davexunit_>paroneayea: I packaged that for guix some time ago :) <adfeno>OBS seems to require really updated version of openGL, whuch most free/libre tools don't have. <davexunit_>never used an easier program for making screencasts <adfeno>Sorry, I meant "RYF computers" instead of "tools". <davexunit_>plenty of RYF computers don't have graphics acceleration at all <davexunit_>but that doesn't mean that there aren't computers where you can run a fully free OS and use OpenGL 3.3 <bavier`>a while back I was having trouble with GuixSD not being about to do reasonable 2D OpenGL acceleration, ended up switching that machine back to Trisquel where things did work <adfeno>For screen recoding I use first step: two asynchronous instances of ffmpeg, one encoding with utvideo for video to mkv container, and othe encoding flac for audio to .flac container, then second step I encode the result to webm (vp9 + opus). <bavier`>e.g. couldn't get even supertux to play at more than 5fps <davexunit_>bavier`: did it have an nvidia card? awhile ago I fixed an issue with the way we build mesa that unlocked OpenGL 3.3 for mesa <bavier`>davexunit_: yes it did. I might try it again then! <davexunit_>I run dolphin, desmume, and minetest on my aging desktop with nouveau drivers acceptably <adfeno>In the first step, two instances of ffmpeg are used otherwise it'll mostly drop frames when trying to mix audio and video. <davexunit_>I was soooo upset awhile ago when I read news that the newest AMD GPUs were compatible with fully free systems, which turned out to be completely false. <adfeno>utvideo and flac are used for lossless recording and reasonable file sizes (not so huge like most other encoders). <davexunit_>$300 mistake. got my money back sans the money spent to ship it back. <adfeno>davexunit_: I might actually need that reference. <adfeno>Saw some similar news about AMD GPU in the Diaspora federated social network. <davexunit_>what was worse is that I then went on to comment on reddit threads that claimed that new AMD GPUs were fully free now <davexunit_>only to be told that firmware doesn't matter and that I'm wrong <adfeno>It was some months ago, but back then I didn't have the necessary proof to actually counter/object. <davexunit_>adfeno: you can just point to the linux source tree. there's a firmware blob in it for these GPUs. <davexunit_>I booted my machine with linux-libre and that GPU and X fell back to a basic driver that had no hardware acceleration at all <adfeno>Aw.... That's the suffering I see when trying to run OBS and LibreOffice (latest versions). <adfeno>... all require newer versions of OpenGL it seems. <adfeno>This made me resort to Org mode and LaTeX for making documents, and that little setup I explained earlier to record videos. <davexunit_>if by newer you mean OpenGL 3.0, even that is old. <davexunit_>I just use intel integrated graphics on my thinkpad x220 and I have 3.3 support <adfeno>I wonder why LibreOffice from Guix leaves lots of screen artifacts for me, though. <adfeno>I have searched around this, and the LibreOffice bug report related to this just says that I should upgrade GPU, or some critical componente/software of my host system (Trisquel 7). <lfam>Another mistake caught by the pre-push signature verification hook :) <lfam>sneek: core-updates is fontconfig, eudev and cups-minimal FTBFS, gnutls lacks IDN support unless it uses libidn2 <lfam>I'm going to fix the GnuTLS IDN thing on core-updates. It looks like we need to rebuild everything anyways, due to fontconfig <ng0>lfam, I've sent an question about darcs, forgot your email adress but I think it was you who reviewed it back then, subject of email is just "darcs". <lfam>Right, if I remember correctly, HTTPS wasn't working <ng0>and I see it not as a blocker to let it bitrot <ng0>the issue is one level higher, curl <ng0>is there anything you fixed, or should I rebase my old branch? <ng0>we added the dependencies already, right? <ng0>I#ll take some time to cmpare it later to my version. <fogbugz>is there any plan to package iceweasel or some kind of newer unbranded firefox clone? I read about it on reddit. It'd be interesting as icecat is lagging bit behind and most firefox plugins are buggy. <fogbugz>It'd be also interesting to package common plugins, i'd maybe give it a try when im more fluent with guix. <ng0>we had a discussion about plugins and someone was working on it.. or is.. <ng0>on a system to do it I mean, to make icecat accept them <fogbugz>cool, but probably icecat is not sustainable long-term <ng0>Not 100% sure, but 'icecat plugins' or something as a search could return results <fogbugz>and most plugins follow latest firefox. E.g im now running icecat+vimperator <ng0>I noticed I don't scale. I have 2 almost finished browsers if someone wants to continue those while I'm fixing other stuff <lfam>It's built on the Firefox ESR release, so it's always going to be behind. Now, it might even be behind the ESR series, I haven't checked <lfam>One _could_ help maintain icecat :) <ng0>to me it looked as if our icecat is faster than the actual icecat in tracking esr <lfam>Yes, one of our developers is keeping up with Mozilla security fixes pretty well <fogbugz>debian dropped iceweasel recently, maybe its smart to just package firefox too, sans branding <lfam>Actually, Debian still has their own Firefox fork. The only change is that they changed the name to "Firefox" <adfeno>fogbugz: Nah, according to jxself in Trisquel forums, it seems Debian got "special" permission to package Firefox. <adfeno>.... or whas that Icedove vs. Thunderbird. <ng0>on the tails or some other lists I read that thunderbird is now back in debian <lfam>Anyways, I agree that we need more people working on browsers in Guix <ng0>I basically stopped working on palemoon.. and I didn't throw it on guix-patches yet because I know if I don't work on it, no one else will <fogbugz>i actually think things are very close now to have guix as a nice desktop <fogbugz>the only two annoyances i have encountered are icecat being a bit lagging behind firefox and startx broken, which seems to come from upstream <fogbugz>i like guix has vanilla packages, debian / ubuntu have always driven me nuts with their heavy patching policies <fogbugz>i guess tracking upstream closely like guix does is the way to go when you can easily rollback <fogbugz>and have different versions of libraries, you dont need to keep everything in sync <fogbugz>Hmm, but is it that hard? I recall compiling firefox on gentoo and it was not that complex <ng0>and it bundles the world <ng0>browser are warflagships stacked on top of tons of other ships <ng0>change one tiny thing, and the entire rainforest needs to recompile again <adfeno>The most good advantage from Guix seems to be that, for example, in the case of Trisquel, it has to deal with renaming and rebranding issues when the Ubuntu name and brand are involved. <ng0>also firefox (or google?) are very resistant against making it possible to use system libs <lfam>They patch the libraries heavily, and then bundled their patched copies <lfam>It's hard to balance their bug fixes with security updates to the libraries <adfeno>So they have make lots of specific "make-[package name]" shell scripts to remove or redo somethings. <adfeno>My last message was about Trisquel and other free/libre distros based on non-free ones. <ng0>it's an complex ecosystem you need to study and learn <ng0>and I hope esr will not catch up with upstream changes that soon because we need a working rust at some point ;) <lfam>Extended Support Release <lfam>Actually, we are already suffering rust problems. librsvg uses rust now <lfam>That's an important library <ng0>david didn't respond about the circular dependency issue and the progress, so if no one volunteers, I will get in touch with upstream, read into docs and see if I can document how to solve it.. though it would be better if someone else does it, who can focus on it 80% or so <lfam>I haven't tried it. We have that cargo-build-system <ng0>I want to try pijul.. and panopticon.. and all the other software I patiently sit on :) <ng0>well there's at the very least an circular dependency issue <nliadm>I'm waiting around for a go build system, I'd like to try my hand at writing a go importer. but also guix's go is just straight broken <ng0>sunday I'll sent some of my 0 dependency rust crates in <ng0>so I can remove them from the big branch <lfam>I don't think our Go is broken. I use it to build a working Syncthing <Amynka>Sleep_Walker: cool ! I didnt notice you ! you should ping me :) <lfam>nliadm: I expect we need a package 'go-toolchain' that is analogous to 'gcc-toolchain' <Amynka>Sleep_Walker: and yes I have guix installed :) <lfam>ACTION has a rough fix for fontconfig. will clean it up and push later <Amynka>Sleep_Walker: you are using guix too? :P <nliadm>I think the link in that bug is broken because of the 1.8 release, but the rest stands. I think it might be an issue with grafts, and the path changing? dunno <fogbugz>btw, does posting to guix-help require subscription? i did post about an hour ago but my message doesnt show in the archive yet <ng0>fogbugz: whitelisted, wil take some time until the first message appears, but they will get therough without subsc. <lfam>fogbugz: Do you mean help-guix? First time senders take a little while <nliadm>I don't have enough guix experience to dig in and understand all of ir <lfam>nliadm: You can see if it's a grafting bug by using the Go you get from `guix build go --no-grafts` <nliadm>how do I use that pacakge, then? <fogbugz>lfam: yep, sorry help-guix. ng0: ok, thanks <lfam>nliadm: You could use `guix environment --ad-hoc go --no-grafts` <lfam>You might be our Go expert, by the way :) <ng0>if you know something is broken, you are 1/3 there <nliadm>if you add '--no-grafts' those oneliners work <nliadm>is there a way to disable grafts on a per-package basis? <ng0>the other 2/3 are dedication and a blockhead with rationality. <ng0>could 25752 be another case of what I encountered recently, the grafting-produces broken files bug from last year? <nliadm>if anything cares where it's installed (and lots of things do) grafting may break them <nliadm>I agree that probably shouldn't happen, but... here we are <ng0>there's a bug open as I understand it is fixed in core-updates, see one of the 'serious' bugs opened in 2016 <nliadm>that might explain why I've had environment shells break when running 'guix gc' while they were open <rekado>(the formatting is a bit off, but that’s just because it’s just been published)