<kmicu>FYI currently Qubes requires libre unfriendly hardware. <kmicu>(There’s a funded project about Qubes+NixOS but they don’t mind blobs in general so meh.) <apteryx>has anyone else experence erroneous clickboxes in the UI of Geeqie? <cehteh>.oO(sidenote: compiled emacs with the libjit stuff, looks amazing so far) <rushsteve1>Would anyone be willing to give me a hand for a minute? I'm trying to build a package from a file but using `guix build -f` is giving me an error. <rushsteve1>The error: guix build: error: #<unspecified>: not something we can build <mange>Put the name of the package variable as the last thing in the file. <mange>The -f flag evaluates the file for a value, but (define-public ...) doesn't return a value. <rushsteve1>So then I'd have to use the -e and evaluate an expression right? <mange>So if you put a new line at the end of the file with just "hugo" on it (without quotes) it doesn't work? <mange>The last form in the file is "return value" when evaluating the file, which needs to be a package object that Guix can build. <rushsteve1>Alright cool, this works for now. Thanks for your help mange! <mange>You could also remove the (define-public ...) and just have the (package ...) as the last form in the file. <bdju>I left my machine to update before bed last night. It seems espeak failed to build <rushsteve1>Wouldn't that mean the package isn't bound to a variable though? <mange>Yeah, it would. Depending on what you're doing that might be fine. <joshuaBPMan>well bummer...chickadee doesn't seem to work on my T400. <rushsteve1>In this case probably. But just putting `hugo` at the end is simple enough for debugging purposes. <joshuaBPMan>my laptop probably just has some really old GL version. <rushsteve1>Anyone familiar with the go-build-system know how to get it to change what folder it's trying to build from? <rushsteve1>Basically the tarball has the code in a src/ folder and I'm trying to move into that then build. <mange>You can modify the phases to add a (cd "src") before the build phase? <mange>Sorry, it turns out the function is chdir. Something like this: (arguments `(#:phases (modify-phases %standard-phases (add-before 'build 'change-directory (lambda _ (chdir "src") #t))))) <rushsteve1>Ah I see, that's cool. That isn't covered in the manual very well. <rushsteve1>Anyone know how to get `guix build` to resolve URLs? Specifically when using `go install`. <mange>Do you mean inside the build container? <mange>The short answer is: you can't. Guix does its best to make sure that builds are reproducible, and part of that means preventing anything during the build from accessing the network. <mange>This usually means that you need to package your dependencies as Guix packages, which you then add as inputs to your package. <rushsteve1>Yeah that makes sense. But it does pose a bit of a problem for me. <rushsteve1>I'm trying to package the Hugo static site generator. Which uses Go mod for it's package management. <rushsteve1>The go-build-system already doesn't like go mod, but I got it to at least try to build. <rushsteve1>But then it fails in trying to download the dependencies. <mange>Does it depend on things which aren't currently packaged in Guix? If it only uses "go mod" for downloading dependencies, could you just skip that step and get it to build with Guix-provided dependencies? <mange>I'm not very familiar with golang tooling, so I can only give fairly vague advice unfortunately. <rushsteve1>Packaging in Go is a complicated mess unfortunately and it looks like no one has bothered packaging most go packages. <rushsteve1>Is it possible to somehow mark the package as non-reproducible and allow network access to the build container? <rushsteve1>Is it possible to somehow mark the package as non-reproducible and allow network access to the build container? <mange>Not that I know of, no. You could build it yourself outside of the build container, but then it won't end up in the store and you won't be able to use Guix to manage installation. <rk4>not saying you should...but the least PITA might be to fork hugo and vendor its deps [go mod supports vendor/, still] <mange>If you use `guix environment -l hugo.scm` then in that subshell you should have all the necessary things from the go-build-system in your path. <rushsteve1>mange Yeah the build itself wasn't the issue, I wanted it as a guix package. <rushsteve1>But if I'm going for problematic solutions then I might as well just have a package wrapping the official binary and not even build it at all. <mange>The proper solution here is to package the dependencies. <rushsteve1>Yeah I know that would be the proper solution, but as the list rk4 posted there are 488 deps in total. <rk4>i suppose this same problem comes up in common npm based projects <mange>I don't think that's the right count. The .sum file has the same dependencies listed multiple times at multiple versions. I think the go.mod file with 67 dependencies is potentially accurate. <mange>npm projects have this same problem, but they also often have depencency cycles which cause problems for bootstrapping. <rushsteve1>The best "solution" I can see is writing an importer to do the hard work for us, like there already is for ruby gem and rust cargo. <mange>Yeah, that would be excellent! <rk4>that would make for an intersting patch, how would one vet the 67 deps? <rushsteve1>I haven't the slightest idea. I don't know nearly enough about go packaging or guix to be able to take on such a task, unfortunately. <rushsteve1>The one thing I do know is that Go keeps changing it's package management system. This is the 3 time iirc. <rk4>yeah, it's a bit of a work in progress over the last few years, and work continues [proxy.golang.org is the new shiny] <mange>The package management and dependency resolution bit shouldn't really matter much to Guix, though, because it replaces those steps. As long as the process of building golang code doesn't change, then Guix should work pretty similarly. <rushsteve1>mange It's a hurdle for writing an automated importer. Once they're imported then yeah it's easy. <rk4>that part of the hurdle looks doable <rushsteve1>I'd be willing to help if someone want's to write an importer. But I don't feel confident in leading the charge myself. <rk4>the bit that strikes me as a lot of work for this sort of task, is suppose we do create an importer, and tomorrows go/js et al project has 100 dependencies by 100 authors. how does one judge the safety of pulling in all that code, does one bother to look? <rk4>[possibly i've been involved with large npm dependency trees that then pulled in malicious code :'(] <rushsteve1>A problem with the ecosystem and package managers in general honestly. Considering Cargo and Gem both have importers already it doesn't seem to be a huge problem, or at least is a fixable, one. Though I'm not sure what that "fix" would be. <rk4>that its a general problem makes me think guix must have already confronted this question - what is the minimal due diligence to add a new lib to guix <mange>I don't think the Guix project has any policy around auditing the code of packages. The infrastructure verifies that the binary has come from the source it claims to come from, but we don't guarantee anything about what the source itself does. <mange>(I'm using "we" in a loose sense, given I don't have any official attachment to the project.) <mange>Basically that means that an audit is at least in theory possible (because you can download the source of all the programs on your system with `guix build -S`, and you have confidence that the sources correspond to the binaries you are running), but the audit itself hasn't necessarily been done. <rushsteve1>But generally yeah I don't think the code of packages are specifically audited. And as mange says it's trivially easy to audit and verify Guix packages yourself. <mange>`npm audit` doesn't stop me as a malicious package creator, though. That just makes it possible for someone to check against a database of known problems. From what I understand an npm package can even have prebuilt binaries in it, making a true audit essentially impossible. <mange>Guix doesn't make auditing trivial - it's still a *lot* of work to actually do the audit - it just makes it possible, because we can establish that the source we are auditing actually corresponds to the binaries we are running. <mange>In other systems with binary distribution this is very hard, so we may audit the source and still not have confidence that our binaries are okay. (Then there's another step for the "Ken Thompson hack", which Guix is also working towards solving.) <rk4>its not specifically auditing code as such, though that could be part of it. it's more about an assessment of risk. for instance, if something comes out of github.com/golang/, i judge it fine enough. if it has made it into Debian, likewise i judge it fine enough. if it however is a brand new npm package by an unknown author, i get a little uneasy <mange>I think Guix's policy is fairly liberal around package inclusion (within the FSDG). <hooo>please explain why guix is better than nix <pkill9>jje: I fixed the guix channel that was failing to build that you posted an error for when trying to run `guix pull` with it <jlouisgnusupport>hooo: is anywhere written it is better? It is GNU project, free software, it is not important if better or not, even people strive to make it better. <pkill9>hooo: better command line interface, nicer and better organised package definitions, and a more general purpose language used for package definitions and configuring the system, instead of a domain-specific language <jlouisgnusupport>I endorse Guix as GNU project, but not leader Ludovic Courtès, so I propose that he resigns for the sake of Guix, just as RMS did for the sake of FSF. <janneke>jlouisgnusupport: i am reading the statement entirely differently; rms is being praised and thanked, no accusations, only a call for to come together and create a stronger GNU project. but please take this to #gnu, it is not on-topic for #guix <jlouisgnusupport>janneke: if you have some facts to support the statements you have got a chance to tell me. Otherwise it is unfounded. <kmicu>Hi hooo: Guix is not generally better but different. Guix can be better for someone if that folk prefers Guix design choices. For example if you prefer proprietary software like e.g. Skype or Steam than Nix is better for you cuz Nix supports those out‑of‑the‑box. All depens on what you really need and search for. <kmicu>Hi jlouisgnusupport: current logging infra is an ad‑hoc system and is often offline. There’s no need to directly jump into conspiracy theories. <kmicu>(and if you are quiliro then you should know that logs are often broken and Ricardo asked for help with that) <roptat>kmicu, no need to jump to conspiracy theories either :p <shrdlu68>Hello #guix, finally got my system to boot. It seems I needed ata_piix. How have you guys configured terminfo? <jlouisgnusupport>can Guix maintainers keep their opinions and defamation, or other illegal crimes outside of the GNU.ORG domain please? <rekado>jlouisgnusupport: please stop the accusations here <rekado>I know this is hard for you to understand, but here I say it again: there are no comments on the static blog at guix.gnu.org/blog; it’s not “disallowed”, it just doesn’t exist. <jlouisgnusupport>I have no accusations. I never had. I am asking Guix to if possible stick to Guix code of conduct. <jlouisgnusupport>you seem to be willing to allow comments, so can you allow comments and make sure they are published? <jlouisgnusupport>that I value now more, as finally you speak out of your heart, and stopped pretending that you would allow comments when you do not allow comments. THANK YOU FOR TRUTHFUL ANSWER! <rekado>yes, I’m not interested in publishing comments on the blog. <jlouisgnusupport>sure, could you now please retract your statement that I accused you that you are not allowing comments? <rekado>that’s not what I wrote, so there’s nothing to retract. <rekado>we are discussing with other GNU maintainers in the common channels that happen to be private mailing lists. It is no wonder that you haven’t seen any discussions prior to the publication of the statement. I assume that you are not a GNU maintainer. <jlouisgnusupport>rekado: alright, that fits exactly into the term "conspiracy". It is thus not a theory but proven conspiracy against RMS. <jlouisgnusupport>conspiracy - a plot to carry out some harmful or illegal act (especially a political plot)) -- which in fact you are doing, as defamation is criminal in many countries, including France, but you enjoy RMS's kindness to never sue you. <rekado>erm, rms is *on* these private GNU lists. <kmicu>Thank you rekado Logs are back. <rekado>kmicu: you’re welcome! I guess I can’t even do censorship right :( <shrdlu68>Isn't it strange that the default initrd doesn't include ata_piix but it included virtio? <rekado>shrdlu68: you can add modules to the initrd <rekado>I guess virtio is there because we often build virtual machines <g_bor>I have a bit of a problem. I managed to fix the git related tests, however it seems that now the tests which need abs_top_srcdir fail. <g_bor>I guess I am setting the AM_TESTS_ENVIROMENT somehow bad, but can't find out what's wrong with it. <roptat>g_bor, have you tried to run ./bootstrap and ./configure again maybe? <g_bor>roptat: yes, but it looks like that there is some envrionment iterference. <g_bor>roptat: it looks like the problem was that I followed the advice on the documentation... It said to make the variable work protably it should end in a semicolon, but it looks like this is not the case. ***Noctambulist is now known as Sleep_Walker
<olivuser>my computer regularly crashes when I 'guix upgrade'. By now, I've tried several --cores options (ranging from no cores option to --cores=1), but it regularly crashes <olivuser>is anyone else experiencing this and might be able to help, please? <Gamayun>Only ever experienced hanging when compiling on too many cores. <olivuser>hm. thing is, my computer is not even THAT old (2012-ish), with a quadcore and 4gb ram. I wouldnt expect that one to crash, even when compiling something such as icecat, with only one core <olivuser>is this a problem that can be resolved with a reconfigure? <Gamayun>Is it compiling anything specific when it crashes? <olivuser>well it has crashed several times when compiling icecat <olivuser>but I believe it is not only when compiling icecat <olivuser>some minutes ago I believe it was crashing over ocaml <roptat>icecat might be too big for your 4 GB of RAM, but OCaml shouldn't be too hard <olivuser>roptat, and this even though I'm compiling at just one core? <roptat>I'm not sure, but I think it really needs a lot of memory <olivuser>roptat, but does that mean that, on an older computer, I can not install such programs - even though they might be able to run? <shrdlu68>Is there a package that offers $TERMINFO for different emulators? <brendyyn>olivuser: you can install them via substitutes, however, the subsitutes server isn't powerful enough to compile everything all the time and have the latest updates available. Maybe if the project received large donations, that could improve ;) <olivuser>brendyyn, I understand. so when there is currently no substitute for me to use, my computer builds it locally, right? does it rebuild every package instance anew when a user such as I types "guix upgrade"? <nckx>olivuser: It's almost always possible, but can be practically impossible: there's little point in compiling icecat in swap if it takes a year, many test suites rely on timeouts with little to no thought put into them, … <brendyyn>olivuser: icecat is a large program that takes a long time to compile and depends on many things. just yesterday, the core-updates branch was merged, so almost every package has to be updated <olivuser>nckx, but it would be a different matter if the compilation would abort and report an error. but my computer literally always crashed in the last two weeks when I tried to update <nckx>olivuser: Also, your computer is unstable, not old. 😛 <nckx>Yeah, that's not normal, computers shouldn't crash just because you dump a workload on them that's too modern (barring new instructions which is extremely unlikely). They crash because they were badly designed thermally or have gotten clogged with dust or… <nckx>Not because they have too few cores. <olivuser>brendyyn, it hangs. I cant use the mouse, keystrokes are not recognised - I sometimes left my computer on for many many hours in order to upgrade (like 8 hours). The only thing I can do is restart, at that point <nckx>olivuser: It's possible you ran out of memory. <brendyyn>olivuser: that sounds like running out of ram. thats very normal for compiling icecat <olivuser>nckx, well, I could try the dust thing :D In what sense, running out of memory? ram? <nckx>olivuser: Is adding RAM an option? <brendyyn>in that case id just wait patiently until a substitute is available <olivuser>yeah why not. I mean my computer is so old that a new one would not hurt, but how expensive can mega oldschool ram be :D <nckx>olivuser: You don't have to buy a new computer if you don't want to (and your current one was reasonably well-designed). I have a 2012 machine that came with 4 GiB of RAM, but upgraded it to 16. <olivuser>nckx, thanks for the advice. getting more ram is cheaper than getting a new pc I guess ;-) <brendyyn>can someone run guix build ruby-sass-spec and tell me if it fails or not please. <zimoun>I would like to know how many user do not use ./configure --localstatedir=/var? Because /var should be the default. What do you thinK? <nckx>olivuser: It was RAM I had lying around anyway, I don't really know the prices. I'd mail you a stick of 8 if I still had any. <nckx>zimoun: Probably 0 on purpose ;-) I don't think anyone would deny that. The discussions in the past (see some guix ML) were more about deviating from the GNU coding standards, or nnot. <nckx>olivuser: 2x8 GiB of DDR3 RAM would have cost me €80, so I'm very glad I had some in a box, but it's not unreasonable. <shrdlu68>Howdo y'all get your terminfo? I tried installing kitty to get its terminfo but that didn't work. <olivuser>nckx, is there any brand you can recommend? <nckx>shrdlu68: I've never had terminfo problems. I happen to have ncurses (which defines a TERMINFO_DIRS search path) installed to my profile for bin/reset, maybe that's why? Doesn't seem likely that Guix ships with broken terminfo out of the box, though. <nckx>olivuser: Not really. People give me their old laptops (as tends to happen once you get known as the computer fellow), so I have a big box of random RAM. Shove some into different laptops once in a while, never had a problem. That said I'd probably avoid obscure Good Price SuperBudget® TurboBrands™ if I ever found any. <nckx>olivuser: Even good brands make crap. Just make sure there's a warranty and run memtest (in Guix!) for a night or more. <kmicu>Hi olivuser before buying anything check if your motherboard/BIOS supports more RAM. E.g. my ~2012 Core2Duo laptop is limited to 4GB. <olivuser>nckx, do you have any experience with memory from different brands? now I have a GEiL one and would buy another brand... <ng0>hey, quick offtopic question for anyone who happens to be on gnu infra team or knows it anyway: is the libreplanet-discuss list still hosted _on_ gnu.org? <nckx>olivuser: Depends (see the description), one needs to be booted stand-alone so you can't use your computer (but it can test *all* RAM), the other can run in the background of a running system (so it only tests *almost* all RAM). <kmicu>olivuser: Even the same brand and the same model comes from different production batches so it’s a lottery in the end. <nckx>☝ this. There are only a few companies that actually make RAM (dunno which, see Web), all the rest just sell their stuff. If they sell it too cheaply, it's the stuff that didn't pass some test. <ng0>basically, who is the responsible structur behind it is all (for reasons I can't disclose I don't want to ask in their irc channel if there is any) <nckx>olivuser: A lottery indeed. A laptop refused to boot once after I put in 2 sticks that claimed to be identical from different brands, but I've had success with such Frankenboxes too. Buying 2 (if relevant) of the same brand is slightly safer. <olivuser>nckx, thanks so much for your help (kmicu, brendyyn and Gamayun too) <zimoun>nckx: thank you for the pointers. Does it make sense to re-open the discussions? <nckx>zimoun: As one who wasn't convinced by the ‘standards’ argument (but also didn't care much either way), I'd say so. <nckx>It keeps coming up regularly here. Some new user (or newly power user) wonders why Guix broke, it turns out to be localstatedir related, someone has to explain the mess. Rather pointless. <zimoun>nckx: I often need to browse notes because I always forget; and the manual does not mention this /var <zimoun>maybe I wrongly read, but "$(localstatedir) should normally be /usr/local/var, but write it as $(prefix)/var." does not seem strong 'standards' <nckx>zimoun: It's quite possible! All good points to raise in favour of saner defaults. ***jonsger1 is now known as jonsger
<jayspeer>so I run guix pull and guix package -u. Now running "which guix" points to store item, rather than to "/usr/local/bin/guix". I don't have guix package in my profile. What's going on? <roptat>jayspeer, it should point to ~/.config/guix/current/bin/guix (which itself is a symlink to a store item) <roptat>maybe sure ~/.config/guix/current/bin is first in your $PATH <roptat>when running "guix pull", you install the newest version of the guix repo in that directory, which contains the new set of packages, as well as the newest version of guix itself <jayspeer>yes, it points to it. However this produces some sideeffects, such as GUIX_LOCPATH being undefined <jayspeer>when did it change? installation still suggest creating simlink in /usr/local/bin/guix to root's guix <jayspeer>I'm asking because I'm worried about creating inconsistencies in my system <roptat>it didn't change, but if you run guix pull as user, it updates ~/.config/guix/current <roptat>whereas as root, it updates /root/.config/guix/current, which points to the same location as /usr/local/bin/guix <roptat>so when you guix pull as root, it should automatically update the guix used by other users on the system, unless they guix pull themselves <jayspeer>so I should not run guix pull as a regural user? <roptat>it depends on what you want to do <olivuser>where can I see the current configuration file of guix? I would like to alter and then reconfigure <roptat>olivuser, it's not copied when you init / reconfigure <jayspeer>roptat: I'm trying to update guix installation and then all packages on my system. "guix --version" and "/usr/local/gin/guix --version" return different hashes <roptat>there's a trick in the vm template to install the file in the configured system <olivuser>roptat, and when I update the file and reconfigure, said /etc/config.scm is overwritten <olivuser>like, I copy the file to a user-local folder, change it, reconfigure <roptat>olivuser, when you update the file, it's overwritten by you <roptat>guix will not change the file by itself, unless you tell it so <roptat>/etc/config.scm is not managed by guix, but it's generated by the installer <roptat>jayspeer, try to run "hash guix" (no output) <jayspeer>roptat: tried, no change. I tried it before <roptat>/usr/local/bin/guix is root's guix, while guix alone is probably the user's guix that you've just pulled <roptat>if you want both to be the same thing, remove ~/.config/guix/current and what it points to (/var/guix/profiles/per-user/your-user/current-*-link), then run guix pull as root ***janneke_ is now known as janneke`
***Tazy_ is now known as Tazy
***janneke` is now known as janneke
***nckx sets mode: +b jmarciano!*@*
***__shymega__ is now known as shymega
***Forza_ is now known as Forza
***drot_ is now known as drot
<dongcarl>Do people have a feeling about when master will be frozen (roughly) for a release? Just wanna make sure I get my patches in beforehand. <sebboh>hey guix. Sorry, I haven't been keeping up to date on this channel.. Do we have a way to export a config.scm from a running system these days? <sebboh>Apparently I edited my config.scm into a non-viable state and left it there for some weeks. Now, I'm not sure what I changed. <apteryx>sebboh: I keep mine in a local git repo; it's good to treat it as code. <sebboh>I wrote my config.scm by hand in emacs in the guix system installer environment back when it was called guixsd. I didn't have network interfaces working yet.. <sebboh>but that's just an excuse, of course you're right that I shouldn't lose my config.scm. <roptat>if you know what you want, you can start from scratch too <nckx>sebboh: If such a thing were to exist, I think it should be separate from Guix. It would just be a script that guesses some easy-to-guess things about a running system to get you started. Probably useless to compare its output to an older hand-written configuration. <nckx>Automatic back-ups linked to each generation as r.optat suggests are a better avenue. <sebboh>totally disagree, I'd rather hand edit what the system actually uses, arcane though it may be.. The DSL currently employed by the example configs in the guix manual are extremely opaque to people that haven't been using guix for a long time. <nckx>I don't think that applies to what I said. At least I fail to combine the two into something that makes sense to me. <sebboh>I think I can export something that represents the generation I am running. It wouldn't be the same collection of forms I initially used to define the system, but it *would* be something I could edit to add a service. :) <sebboh>nckx: Sorry, I responded to what I suddenly figured out when I read what you wrote, instead of responding to what you wrote. What I figured out is that I have been asking the wrong question. ;) <bavier>I seem to remember someone who included a service in their config.scm that would copy the current config.scm into the store, sorta like a backup <nckx>bavier: Yup, you can do something like etc-service-type with (local-file (assoc-ref (current-source-location) 'filename))). <sebboh>The correct question is, what does `guix system switch-generation` do under the hood? Just like, broadly.. <nckx>bavier: If there's a way to wrap up more complicated (multi-module) configurations, not just a single file, I'm very interested in seeing it. I never got that to work reliably. <nckx>roptat: Cool that it's done in the template 🙂 Do you know if it's done by the installer, for example? <sebboh>hm, I think guix system switch-generation doesn't do as much as I thought it did. <nckx>Ugh. Packages that use -Wall -Wextra -Werror -pedantic in 2019 need to be cancelled. <nckx>‘Here's a lint warning to break your production workflow tee hee’. <nckx>Ugh. I hate maintaining things. <truby>nckx: I've been having a bit of trouble with these flags since the core-updates merge :-) I was trying to dig down towards a solution but I can't reproduce the original problem with CPLUS_INCLUDE_PATH instead of CPATH <truby>(a project I work on does ask for these flags and I use a guix environment to install gcc-toolchain which now won't build the project :-( ) *bavier not entirely surprised to see most of the comments in lobste.rs re guix-reduced-bootstrap-see to be about CL vs Scheme <nckx>apteryx: It's my own fault for proclaiming ‘core-updates is dandy!’ after testing on all my machines… except the stinky old machine serving stinky old PHP sites I can't get rid of. Oops. ***w2gz is now known as w1gz
<nckx>apteryx: Oh, right, you're you 🙂 Sorry, I thought it was a sarcastic dig. <bavier>so core-updates only broken on stinky machines? :) <nckx>bavier: & close all bug reports with ‘invalid (stinky machine)’ & proclaim Guix is bug-free. <nckx>Hm, the package (fcgiwrap) is actually in worse shape than I knew, maybe a good thing it came to attention. <nckx>Last release: 2013 (so I was wrong about ‘2019’ above), so we're missing fun commits like ‘fix use after free’. <nckx>Always nice to see that in Web stuff. 👍 ***roptat_ is now known as roptat
<apteryx>nckx: ha, no dig intended, of course. Whas is the matter? The newer GCC is causing many packages to fail that make use of those flags? <nckx>apteryx: That's what it looks like: error: this statement may fall through [-Werror=implicit-fallthrough=] <apteryx>I guess the affected projects should be notified (bug report?) that they don't build wih GCC 7+ <nckx>Now I'm slightly more worried about using network-facing (albeit behind nginx) software released in 2013 by an upstream last active in 2015. <nckx>(‘Is this project actually alive?’ ‘Well, I'm using it on Debian’ made me lol.) <olivuser>when installing a desktop environment, i.e. mate, and have the "wildcard" %desktop-services in the end of the (services-form, does the system actually install all of the packages belonging to mate? <truby>apteryx: it's not that the projects don't build with gcc-7 necessarily, part of the issue is that warnings in system headers now trigger -Werror because of the C_INCLUDE_PATH -> CPATH change <nckx>olivuser: s/wildcard/list of defaults/, which might help you understand what it does. How are you ‘installing’ mate? The result of operating-system does not change based on outside factors, it is self-contained. <truby>(at least, this holds for my project) <nckx>truby: True, but this is an error in fcgiwrap.c (and not dependent on headers), so it seems some new/stricter warning checks are to blame. <truby>nckx: sorry yes now that I've read your message again that is actually obvious :-) -Wimplicit-fallthrough is on by default as of gcc 7 <olivuser>nckx, I have it listed in my operating system configuration as a mate-desktop-service-type, not "installed". I was wondering if all the packages associated with mate ('guix package -A | grep mate-') are automatically loaded or have to be installed (as package) separately, or specified within the configuration file when specifying the mate-desktop-service-type <nckx>olivuser: (I avoid the word ‘installed’ in Guix for that reason, even when talking about ‘guix install’, it's too confusing for me.) <truby>(the easy fix is to just add -Wno-implicit-fallthrough to configure-flags) <nckx>olivuser: I'm not familiar with -desktop-services, I'm afraid. Is ‘just giving it a try’ an option? 🙂 <nckx>truby: I guess that would work. I removed -Werror entirely out of spite but also principle, I really don't see the point of upstreams that do it. <nckx>Now I'm not sure what's best. <olivuser>nckx, yeah, will do ;-) It's just that I'm very new to (trying to) "program" stuff in(to) guix, that's why I was asking for help <truby>my personal preference is to have it in debug builds but not in release builds. But the reason upstreams do it is to enforce that every patch you're given was tested with -Wall -Wextra and that warnings weren't ignored I guess <nckx>olivuser: As a rule, ‘services’ don't affect or provide appz on the command line (or desktop). The only reason I'm not sure is that -desktop… services partly exist to, well, provide appz. At least enough to show a desktop. <olivuser>also, when I want to attempt to help at packaging, I do first follow the steps specified in "running guix before it is installed", right? <olivuser>not that I was trying to kickstart the process, but some first steps should not hurt. <apteryx>olivuser: yes, that should give you a working Guix you can then extend and easily play with <apteryx>nckx: I think vinagre fails for a similar reason [-Wdeprecated-declarations] <nckx>apteryx: Thanks, I'll take a look. <truby>at some point in the future Wdeprecated-declarations is likely to be on by default even without -Wall -Wextra, so in that case removing Werror is likely the correct choice :-) <bavier>I was wondering whether the Guix Data Service would be a reasonable place to upload build-elapased-time stats <bavier>they could be used to "train" a model that could showed expected build time to users <apteryx>yes, Kei bumped to 3.7 and we have substitutes, so we're all good. *nckx ^Cs because we're not building webkitgtk today thanks. <nckx>bavier: Required network connectivity, derp lernin'… Are you trying to trigger me ;-) <nckx>(It would probably be the place, yes, if just by default.) *truby wishes there was a CI that was based on guix instead of containers <nckx>truby: -Wno-implicit-fallthrough worked to, but I think I will stick with !-Werror. <truby>nckx: For packaging things I think -Wno-error is definitely sensible, developer warnings aren't your problem :-) <bdju>been hitting issue after issue trying to update since core-updates was pushed, but I think I'm getting closer to success <nckx>bavier: I'm a bit worried that all clients uploading build stats is trivial to spoof. The consequences would be trivial too, of course, but it would be annoying and that could be enough for trollz. <nckx>bavier: mm, not really the place. <nckx>bavier: Sorry, I didn't want to kill a new idea (probably the only sensible thing Jobs ever said). Just immediately occurred to me. <bavier>nckx: sorry, didn't even think before sharing, thanks for op'ing <bavier>and just meant "hadn't really thought through all the details yet" <nckx>bavier: :) (and recent events probably have something to do with said immediate occurrence.) ***ng0_ is now known as ng0
<bavier>nckx: np, and I appreciate your recent efforts too :) <zimoun>nckx, bavier: sorry I miss the point "The consequences would be trivial too, of course, but it would be annoying and that could be enough for trollz." Could you elaborate? <zimoun>because expected build time should be a good feature the Guix Data Service and it is easy regression (no deep learning :-) <nckx>zimoun: It's trivial to upload bogus stats (I built webkitgtk in 5 minutes!) with relatively little effort (and I don't consider IP jumping or getting the hash of a build as proof of work effort, here). <bavier>zimoun: e.g. if no authentication, trollz could upload bogus data that throws the regression off and renders the intended results useless <nckx>We can apply ‘sanity checks’ but, eh, that gets ugly fast and is itself easily manipulated (the outliers might be the only legitimate reports). <nckx>zimoun, bavier: I also wonder how much value such aggregation would have. I assume the modelling would be to suss out CPU/RAM/other requirements from a single number. But maybe a rough number from a trusted build farm(s) is ‘good enough’ here. We can still apply precious ML to filter out system load &c. 🙂 <nckx>Aggregating times-elapsed would really only make sense if we gather other data too (I might be wrong about that, though) like cores, CPU generation, RAM, … Boom, fingerprint central. <bavier>a build farm number might be good enough, yes. Some experimentation would be needed, I think, to see what parameters are necessary to get a good enough mapping from the build server to a users machine. *jonsger finds this Jean Louis on guix-devel a little annoying <olivuser>when I guix system reconfigure, do I want to be root or not? <olivuser>(I especially want to change the available desktop environments) <nckx>jonsger: They have been sending personal messages too, and filing bogus bugs. <zimoun>nckx, bavier: thank you for explanations. I see <nckx>‘Worse and worser’ correctly describes their pattern of behaviour. <nckx>I can only encourage not responding to their non-questions. <jonsger>if I would be a GNU maintainer, I would sign directly. But I'm only an openSUSE maintainer :P <nckx>jonsger: It's still valuable that others speak out to counter the ‘minority (but somehow also mob, hm) attack on poor RMS’ narrative. Even if just by noting it here. So thanks 🙂 ***ChanServ sets mode: +o nckx
***nckx sets mode: +b jlouisgnusupport!*@*
<nckx>(They were ban-evading.) ***ChanServ sets mode: -o nckx
<shrdlu68>nckx: Thanks, installing ncurses helped. <nckx>shrdlu68: Cool! I wonder if it's reasonable to require that, though. If you'd want to file a bug, I'd understand. If not, all good too. <nckx>shrdlu68: Love your nick, by the way. <sebboh>ok, for those of you following along.. I fixed my existing config.scm. And did a reconfigure! Time to reboot and see what's up.. :) <sebboh>But before I reboot... the last line of the reconfigure output was: shepherd: Evaluating user expression (let* ((services (map primitive-load (?))) # ?) ?). <nckx>sebboh: Nope, it's confusing, but harmless. <apteryx>nckx: --disable-werror at configure should work? <nckx>apteryx: I didn't see any code that would indicate that (configure.ac just unconditionally sticks some flags onto CFLAGS), but I'll try it anyway. <nckx>I wasn't looking either. <shrdlu68>Just to be safe, how many times is the "Why not common lisp?" question raised here? <nckx>apteryx: Nope. Too naive. <nckx>apteryx: (The script, I mean.) <nckx>shrdlu68: I've never seen it here. I think ‘it's a GNU project, and the last GCL release was in 2014’ might be enough of an answer to that question, but you'd have to ask civodul. <reepca>so far vinagre and wesnoth have both failed to build since the merge of core-updates <nckx>I don't know if they were maintaining Guile back then. <apteryx>reepca: yes, I'm looking at vinagre right now <nckx>reepca: OK, both things I use (just not since switching to c-u), I'll take a look. <apteryx>but so far hitting this error building my guix tree: no binding `zip' to hide in module (gnu packages compression) <nckx>shrdlu68: Actually Guix is about that old, or even older, so the 2014 thing was merely lucky in hindsight. OTOH, I've heard it said by people who could know that Guix really kickstarted a new wave in Guile development. <nckx>apteryx: make clean-go? It's definitely something local. <shrdlu68>In that case I would not be bringing up a tired old argument :) Anyway I do wish it were CL, it's a big community and both communities would have benefited immensely thereby. *nckx doesn't actually have an informed opinion on CL. <shrdlu68>nckx: Interesting (not having an informed opinion on CL). <shrdlu68>nckx: Vice versa for me, and I have the impression that CL has more users. <davexunit>can we put a blanket ban on *@gnu.support on our mailing lists? <nckx>davexunit: I guess we'd have to ask GNU? (ping bandali) <nckx>Debbugs is even more important. <apteryx>nckx: rm -rf ~/.cache/guile did it. I have a branch that modified the file system record, and it seems to corrupt the cached .go or something. <nckx>apteryx: I've had some cross-worktree contamination weirdness before that required a similar hammer. <nckx>shrdlu68: I'm sure civodul won't mind answering that question, and they're really the only person who can. <shrdlu68>nckx: rms also has an aversion to CL - hence GNU endorsing Guile. Anyway, I would do many things if I had a magic wand. <reepca>next up on the fail-list is lmms this time. Perhaps I just have an abnormally large profile? <truby>mbakke: it doesn't use Qt4 upstream, so if the package does it probably shouldn't <truby>mbakke: I would love to, and I've got a few patches for clang, but I have to wait for approval from the legal department at work :-\ <truby>(because I wrote the patches for llvm.scm for us to use internally) <shrdlu68>How do I define a custom file for the base system? (operating-system declaration) <truby>we're getting some new self-approval process soon(tm) which should really make things easier :-) because I've been looking to contribute to guix recently as I enjoy using it so much! <apteryx>shrdlu68: you can use the extra-special-file service <shrdlu68>apteryx: That only seems to create a symlink. <sebboh>I'm troubleshooting ssh-daemon not starting up after a reboot. It starts normally if I manually start it at a console. What log should I look in? If I recall correctly, shepard tries to start ssh-daemon but it doesn't work--yet.. but I can't seem to locate the log that shows that today. <apteryx>OK, I have a fix for vinagre: s/GNOME_COMPILE_WARNINGS([maximum])/GNOME_COMPILE_WARNINGS([minimum])/ <sebboh>that's odd, I can't find any shepard log at all. <sebboh>nevermind; found all the logs. user error. <apteryx>nckx: this works: "--enable-compile-warnings=minimum" as cflags for vinagre :-) <Formbi>I'm getting this when I run «guix system reconfigure /etc/config.scm»: <Formbi>guix/ui.scm:1692:12: In procedure run-guix-command: <Formbi>Throw to key `encoding-error' with args `("scm_to_stringn" "cannot convert wide string to output locale" 84 #f #f)'. <nckx>Formbi: Could you paste /etc/config.scm somewhere (‘guix install wgetpaste’, paste.debian.net, …)? <nckx>shrdlu68: What do you mean by ‘custom file for the base system’? <nckx>You can pass any file to ‘guix system reconfigure’ (I use /etc/guix/system.scm). If that's what you mean. /etc/config.scm isn't hard-coded anywhere (thank gods). <apteryx>shrdlu68: you can use Gexp procedures to define anything as the target <nckx>Formbi: This is weird. I was expecting an obviously bogus UUID, or an exotic character, but no. And ‘guix system build <that file>‘ is happily building something. <nckx>Maybe it is a ‘legit’ locale error. <nckx>And locales hurt my brain. <nckx>Formbi: Does ‘LANG=C LC_ALL=C guix system …’ work any better? <nckx>(I know one of those vars is probably redundant, please all mail in to tell me that, I can just never remember which one.) <nckx>apteryx: Great! I assume you'{ve,ll} push it. That'll save me some time next time I need to fix a frozen VPS. Thank you. <nckx>Formbi: Well damn. It's building a kernel here. I assume this error happens to you before anything starts building? Are you working from git? I'm afraid I'm stumped. <Formbi>I started it with --fallback now and it seems to be going <apteryx>nckx: yes, I'll briefly test it runs and push <nckx>Formbi: Guix is *very* picky about what it gets back from the network, but I don't see how that would relate to your error message above unless something networky got snipped. <nckx>My fault for not asking for the complete error message. <Formbi>I thought that it doesn't have anything to do with it so I didn't <nckx>I would have done the same thing as you: think it can't have anything to do with it & try it anyway 🙂 Glad you got around it. <nckx>sebboh: The ‘loopback’ there sounds to me like a deliberate decision not to pull in all of ‘networking’. Perhaps there's a valid use case without it? <nckx>If so, a comment saying so would indeed be nice & take the guessing out of it. <sebboh>Maybe, nckx. How can I change it locally? I tried adding (requirement '(networking)), but.. I think I'm putting the form in the wrong spot. <nckx>sebboh: I see that ‘loopback’ was only added (in 363c946b36) to fix a start-up error. What exactly are you trying to do? It might not be what you think it is. <nckx>(Unfortunately, I have to leave v/soon…) <sebboh>openssh fails to start after reboot and it starts successfully when I manually invoke kerd <sebboh>*herd ssh-daemon start or whatnot. <nckx>sebboh: Ah, yeah, see, I don't think what you're trying to do would fix that. <nckx>Let me search the bug jar… <nckx>Problem is, I don't know how whoever posted that actually disabled IPv6… :-/ <nckx>I hope that's enough to help you on your search, or that someone else can help you further. I've got to go. <sebboh>(To be fair to myself, FYI everybody, I also want to learn how to do the thing I'm trying to do even if it won't solve my problem. I understand "the X Y problem", but I am a self-taught hacker. Trying a few wrong things never hurt me...) <sebboh>I've read that bug about ssh-daemon vs ipv6. I decided to leave ipv6 enabled (not only because I don't know how to disable it in guix). It's 2019.. Disabling ipv6 can't be the solution to every problem anymore, right? :) <bgardner>Good afternoon guix; after a 'guix pull && guix system reconfigure ...' today my web server is complaining about 'locale for en_US is not found', any advice? Doesn't seem to be fatal, but it's all over the place. <truby>bgardner: it went away for me after guix install glibc-utf8-locales-2.28 but I only got to that after trial and error and have no idea why it worked :-) <nckx>So my ride still hasn't shown up… 🙂 sebboh: I completely understand (I'd describe myself as such, too), I just knew I wouldn't have much time. bgardner: This is a sign that ‘guix pull --news’ isn't well known/publicised enough ☹ <bgardner>truby: No luck, still errors all over the place, but thanks for the tip anyway. <nckx>sebboh: Agreed that it's not an acceptable solution, but, well, isn't every work-around? ;-) <truby>bgardner: I guess you might need glibc-locales-2.28 as well? *nckx goes to wait in the rain again. <bgardner>truby: I'm game to try it, reconfigure running now... <truby>bgardner: unfortunately I have no idea how locales work so I can't really contribute further than what worked for me :-( <bgardner>truby: I understand, I'll muddle through and keep an eye out. Thanks for trying. <bgardner>truby: Well, I can switch the web server to en_GB and all my errors go away. I'm not in Great Britain, but whatever. I'll look another day. <truby>bgardner: incidentally en_GB.utf8 is the only locale I personally have used :-) <bgardner>truby: Interesting. I've done little with locales so not sure what's up, but I suspect this is a good clue. <truby>not that I've ever noticed any difference between en_GB and en_US to be honest <truby>except that en_GB is obviously the real language ;-)