<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.
<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.
<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.
<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).
<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
<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.
<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.
<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.
<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…
<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>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.
<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.
<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. ;)
<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.
<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.
<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)
<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
<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: 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>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.
<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 :-)
<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? ;-)