<Digit>is there somewhere that shows what a user gets with GuixSD that dont get with just Guix deployed on some other distro? somewhere that shows what's gone into GuixSD above just Guix? <buenouanq>freedom, no systemd, and guile interaction everywhere~ <biovoid>I've been considering buying a Talos II, and GuixSD seems like a logical pairing. Is there an initiative for GuixSD on ppc64el? I'm interested in putting some work into it <catern>(it's equally needed in Guix as in Nix) <ng0>Digit: in the Manual <jonsger[m]>biovoid: that is actually powerpc32 (big endian) <biovoid>jonsger[m]: Well, it's a good start—thanks <jonsger[m]>biovoid: maybe you could leave a mail on the mailing list. this should increase the "outreach" :) <erudition>The "videos" link in the channel topic just points to a nonexistent #talks anchor on the guix help page. no videos are there. <buenouanq>Going to try and install GuixSD on my BeagleBoneBlack. <buenouanq>Because of the no no cross compiling disk image thing, it seems I have to first install Guix to the Debian on the BBB, then build the GuixSD image from there <davexunit>that bootstrapping issue is why I haven't tried yet <buenouanq>well, if the Guix install goes smoothly (which I've actually never done, only ever done the full GuixSD) it shouldn't be a problem. <davexunit>I may still buy a beaglebone black and use a novena to build the image <buenouanq>I've had this sitting around doing nothing for a long time now - Excited to have an excuse to play with it again. <erudition>a simple `guix package -i hello` has been going for almost an hour... is that normal? <buenouanq>I'm more excited for the EOMA68s though - Hope we can figure that one out too. <str1ngs>erudition: are you using guixsd or foreign distro? <str1ngs>erudition: did you authorize the substitute server? <erudition>Actually, I wasn't sure, so after it finally finished (failed, citing 404s for several drv including libpng) I entered the command to authorize hydra <erudition>when I tried again, it looked like it was indeed using substitutes this time... but it's still been going for like an hour again <str1ngs>erudition: it might download some bootstrap binaries etc. but an hour seems long. is it building or just downloading? <erudition>In the beginning There were definitely lines like "found valid sig for xxx" as it downloaded subtitutes <erudition>but now, the screen is a mess with gcc flags. so yeah, definitely building <str1ngs>it is not uncommon that something will need to be built from source. it's kinda rare though. <str1ngs>right you are installing hello, but guix need to setup your profile. which is one time. but pull in many depends not directly related to hello <erudition>as far as what package is being built, not sure <str1ngs>also the substitute cache could have been confused, due to hydra not be authorized when you originally tried to install <erudition>also, i get a warning on every guix command, "failed to install locale: invalid argument" <str1ngs>to fix that all you have to do is install glibc-locales <erudition>didn't get that far since it's already been so many steps <erudition>kinda wish the install commands were just in a shell script <str1ngs>export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale | <str1ngs>export GUIX_PROFILE="$HOME/.guix-profile" | <str1ngs>is the easiest way to fix your locales and setup profile <str1ngs>I'll find the docs, it should be in the install instructions <str1ngs>locales are in the application instructions <erudition>ah, I think the install intructions do that for root <str1ngs>but because you are on foreign you'll need to setup application locales. <str1ngs>you'll need to setup profile for used as well <str1ngs>binary yes, but the locale setup falls under application setup instructions <str1ngs>not all required, depends I guess what you will be using <erudition>just want to see how much of my system I can use guix for <str1ngs>the short answer everything butt the kernel and services <erudition>I was thinking the opposite, as barely any GUI programs are packaged <erudition>I use KDE, for example - as far as I know that's not yet possible <str1ngs>kde might be an exception to the rule though. most people use lighter DE's and the official guixsd desktop is GNOME <str1ngs>you might need to make a package if it does not exist <erudition>Oh I know, but I figured the first work was on the core services <str1ngs>for example I had to write a package for deluge, which was kinda fun actually <erudition>since the 27,000 or so packages in something like ubuntu main are other obscure things <erudition>I wish I could just start packaging things, but wouldn't I need to know how every language is compiled? <erudition>looks like guix is 6,725 packages, so almost a quarter <str1ngs>hard to compared ubuntu to guix. since ubuntu uses debian packages. <str1ngs>debian is long in the tooth with age :P <erudition>debian too. wish we could convert them more easily <erudition>Put it this way, i thought debian packaging was too complicated to realistically do as one-off tasks. But guix packaging seems even more complicated than that <str1ngs>most things use gnu-build-system which the hello example covers nicely <str1ngs>for other build systems there are documented interfaces <str1ngs>guix might appear complicated but they generally are not. guix atleast uses DRY <str1ngs>and the results are quite reproducible <str1ngs>guile's not bad. personally I've grown to really like it <erudition>I don't doubt it - I'm a haskell learner myself <erudition>but I'm not good at learning more than one a t a time <str1ngs>if you can learn haskell, guile should not be as strech <str1ngs>I'm fluent in bash, C, go, elisp, and getting there with guile. <str1ngs>think you have me at haskell. it never seems to click with me :P <erudition>haha yup. I'm annoyed when I have to use other languages now <str1ngs>you'll enjoy guix then, since it function based <erudition>I guess I'm just disappointed that all this packaging has to be done from scratch <str1ngs>I've been using guix for could months. most of my machines are guixsd now. and I found it will grows on you <erudition>after all, like you said, debian is old. lots of things have been packaged. why can't we benefit from that? <erudition>my favorite part about debian is how after years, I still discover cool things in the repos <str1ngs>I think guix has more in common with nix then debian. so maybe check the nix importer <erudition>problem is, now I don't want to switch to any distro with less :P <str1ngs>you don't need to switch to guixsd. guix works fine with other distro's <str1ngs>how many other package mangers can say that :P <erudition>wouldn't all these guix packages need maintainers though? <erudition>or is it package once and you're set forever? <str1ngs>guix does not have "package" maintainers per say. it does have maintainers <str1ngs>guix package are more monolithic since the packages are part of the guix repo <erudition>so guix people need to watch every package out there for updates? <str1ngs>guix has an upstream refresh mechanic <str1ngs>provided the package uses it of course <erudition>right.. which assumes the package is onboard with guix <erudition>well wouldn't they need to update e.g. the build recipe whenever it changes? <str1ngs>what I meant was if you do guix refresh bash. it will check upstream releases <str1ngs>don't run refresh unless you have a good reason though <erudition>so there's nothing the developers of a package need to do to support guix? <str1ngs>most packages use autotools, and even things like python setup tools, cmake etc are supported <str1ngs>if its not supported you can use trivial build system <erudition>guess I'm just not sure how that would work. What if the recipe changes though? <str1ngs>well most people that package something generally follow upstream. either via ML or developer lists <str1ngs>in the case that someone packages something for guix and does not maintain it. it stays packaged. and anyone can send patches <erudition>so I can't just go package a hundred things i want guix to have <erudition>not without repeating the process for every update <erudition>do I have this wrong? That link doesn't seem to talk about this aspect <str1ngs>if you would like to add packages to guix you can send patches. you are not obligated to maintain them <erudition>ok I suppose I am projecting here - I personally am not interested in packages that will not be up to date <str1ngs>if packages need updating you can provide refresh mechanic . or others will submit update paches <erudition>I guess I fear that's the path to everything lagging behind bigtime <str1ngs>I'd package it first worry about that later <erudition>best part about having multiple versions of the same package is you can have cutting-edge versions of some packages and old (more stable) versions of others <str1ngs>even if the package is old. it still maintains its functional input/outputs <str1ngs>contrary sometimes old is more stable <erudition>I've use chakra, for example. the idea is stable core, cutting edge apps <str1ngs>I guess my perspective is slightly skewed though. generally I use gnu software. which guix as in spades <g_bor>I'm trying to make java-commons-collections on java8, and I specified target to 1.7, because of an incomtability. However I get [javac] javac: invalid target release: 1.7 <g_bor>However removing the additional flags, it works fine, but does not compile beacuse of the java8 incompatibility. <g_bor>I guess something's wrong with my package definiton. <marusich>g_bor, I don't suppose the trailing whitespace might be causing problems? I have to run but at the moment that's all I can think of. <marusich>Could it be that using "1.7 " is causing something to conclude that "1.7 " is not valid, when instead it might accept "1.7" as valid? <marusich>What if you replace the lines like (string-append "-Dant.build.javac.source=" "1.7 ") with lines like "-Dant.build.javac.source=1.7" instead? <shiranaihito>is there a "roadmap" for planned major features / releases (of GuixSD)? <mb[m]1>Is anyone using avahi-service? Including it caused all kinds of weird behavior (empty derivations, etc). <fis>Hi, how do I fetch source in a package from a local git repo? <str1ngs>fis: you can use git-fetch for origin method <mb[m]1>fis: you can use "guix build --with-source", or edit the package definition with something like (source "/path/to/git/checkout"). <mb[m]1>Or use git-fetch as str1ngs mentions for a more permanent solution. <fis>Thanks, I am trying. <str1ngs>fis: if your using the permanent method. guix edit wget2 is an example of a git source <str1ngs>fis: I'm not sure cloning locally though. possible you can just use the local path <fis>I pass the url as "file:///path/to/git-repo/ <fis>But I got something like "/path/to/repo/" does not appear to be a git repository <str1ngs>sorry I miss read. fis try without file:// just use the local path <fis>This will render the repository not exists error. (I checked, the path is correct, which I copied from `pwd`) <str1ngs>I'm not sure if git-fetch handles local paths. since IIRC its using libgit2 so it's not like it calling git directly <fis>So, if I want to maintain some customized tools and libraries with guix, how do I do that? Do I have to make a tar-ball every time I make some change to the local branch? Or is there a more convenient way to integrate guix with usual development procedure? <str1ngs>fis: you could just use a local path, and manually checkout the git repository <shiranaihito>the first time i ran "herd stop postgres", herd said it stopped it <shiranaihito>now it says "could not be found", but it's still running <str1ngs>shiranaihito: sudo herd status will list the services <shiranaihito>i mean, the status command lists postgres as stopped, but it's not <str1ngs>postgres is the name of the service then? <shiranaihito>what does the "user-homes" service do btw? (and why might it be stopped without me stopping it?) <str1ngs>I believe it create home directories if they do not exist yet. don't quote me on that though <catonano>shiranaihito: whhat do you mean withh: it's not ? Is there a postgres daemon rrunning ? <shiranaihito>catonano yes :) it's still running (as shown in the paste with the process list) <catonano>shiranaihito: could you paste your conf file ? <catonano>shiranaihito: sorry, i meant the GuixSD configuration file <catonano>shiranaihito: I'd write on the mailing list about this <shiranaihito>catonano could you please do it? you've probably got the mailing list set up and so on.. i'd have to google for how to join it etc <catonano>but then the answers would be directed to me <catonano>it's not that hard to subscribe to the mailing lists. Wait a minute <catonano>shiranaihito: no I think you need to subscribe ***Exagone314 is now known as Exagone313
<snape>shiranaihito: you don't need to subscribe <shiranaihito>snape oh, ok.. but i already did :) let's see what happens <snape>shiranaihito: I don't understand why you stopped postgres while it was already stopped tough <snape>oh, ps shows it's not stopped. Right <snape>shiranaihito: it's a bug with the postgres service <shiranaihito>i'll be "away from keyboard" now though, playing Tekken :) <snape>shiranaihito: no I didn't know about it <lfam>Struggling with the pandas test suite on core-updates... <lfam>One of the tests uses all the memory until the OOM shows up <lfam>So, I just disabled that silly "test" <lfam>But there are lots of other failures <lfam>It would be nice if someone who actually uses pandas would try <shiranaihito>btw, is there a "stable" version of GuixSD (planned?) ? :) <shiranaihito>i mean.. this "'postgres' service doesn't stop" thing seems like something that shouldn't be happening, at least in a "stable" release <shiranaihito>but maybe this is the kind of stuff GuixSD not being "production ready" refers to :P <lfam>shiranaihito: There is not a "stable" version planned as far as I know <amz3>my understanding is that mainlile guix is stable, core-updates is unstable <amz3>guix is a rolling release, so there is not really a concept of stable unstable <amz3>well, gentoo has stable/unstable and is rolling release <davexunit>hey folks. I've been a ghost lately but I just wanted to mention that my guix talk proposal for LibrePlanet 2018 has been accepted. <shiranaihito>amz3 well, i suppose "stable" would generally cover being able to start and stop postgresql, so it could be argued that the mainline Guix(SD) isn't actually stable <shiranaihito>i understand that shit happens, but isn't that why a lot of projects have some kind of process in place to produce a "stable release" :) <shiranaihito>oh, and before i forget again, are there plans to run GuixSD on RISC-V? <davexunit>shiranaihito: I don't think anyone has started a port for that <lfam>amz3: core-updates is not what you'd consider an "unstable" branch like Debian's <lfam>It's just a place we dump patches for low-level updates for a few months. Later, we fix things and make it work before merging it into the master branch <davexunit>guix needs some maturing before we could commit to a stable release series <lfam>shiranaihito: I think the answer to your questions about stable branches and new architectures is basically "if somebody wants to do it" <lfam>The bugginess of some part of the system is inversely proportional to how many people are using it, I'd expect. So, the postgres service probably needs someone to really exercise and work out the bugs <lfam>I mean, to really exercise it <jonsger[m]>shiranaihito: for riscv I would say there is missing "real" hardware to port guix to... <shiranaihito>as for the postgresql-service, i sure hope someone tried starting and stopping it before it was merged to master <shiranaihito>like.. serviceable for an ordinary person's general computing needs? :) <lfam>I don't think the first iteration of a new architecture will be appropriate for an ordinary person's computer <jonsger[m]>I don't think so. Maybe some kind of developer board. I'm still unsure about the RAM <shiranaihito>RISC-V seems to be advancing fast though, which is very nice <amz3>shiranaihito: I meant to say what lfam say above, I just was too lazy to type <shiranaihito>well, i'm not sure how that makes sense in that part of the conversation <amz3>shiranaihito: basically, more user = less bugs, look at the reason why it doesn't work by yourself <amz3>and I don't know what risc-v is <amz3>I was under the impression that all RISC processors were out of business <shiranaihito>amz3 i'm an end-user - not looking to develop Guix(SD) myself :) <amz3>that's what I said too until I package a few things ;) <amz3>some programs are very simple to package, (autotools based, few or no dependencies) <amz3>and it's a great win for the community, because you don't expect such thing to be packaged in an obscure distro <vagrantc>one of the only freely licensed ip cores for a CPU ***Piece_Maker is now known as Acou_Bass
<apteryx_>Looking at the source it seems alright, so maybe something in the way I run my guix build command? <lfam>apteryx_: Are you running Guix from a Git checkout (./pre-inst-env)? <lfam>Oh yes, I see it in the paste <lfam>I experienced this recently. It went away after `make clean-go && make` <apteryx_>OK, I'm recompiling it now. Thanks for the advice. <lfam>There is no obvious way to go from reading that to reading the changes that supposedly fixed the issue <lfam>The "fixed" version is not even accessible from their package tracking system, and it doesn't show in the package changelogs <lfam>The package source is hosted in bzr <lfam>So, the bug report includes no information about how the bug was fixed or where to look for the fix, and it's possible that the code with the fix is not even available on their domains anymore. <lfam>At least Ubuntu still offers the code <lfam>It's extremely frustrating as an outsider <lfam>And the diff between the broken and fixed versions is 41000 lines <lfam>I shouldn't pick on them but this is a recurring frustration for me <lfam>Obviously their work is monumental and valuable <lfam>Thanks vagrantc, I didn't know about that URL scheme <vagrantc>that style of packaging where there's one huge diff is also at least somewhat frowned upon <lfam>I find Debian's infrastructure challenging to use. It might be fun if it was a puzzle game <vagrantc>agreed. it's hard to maintain a 25+ year old project of that scale with thousands of active and thousands more inactive contributors <vagrantc>it's evolved over time, but there's lots of legacy holdovers <vagrantc>i have enjoyed experimenting with guixsd for the last few months by comparison <lfam>We have to be careful to retire infrastructure that we can't maintain anymore <vagrantc>it's the problem of centralized vs. distributed development <vagrantc>debian is a collection 25k+ projects of individual efforts ... not a central git repository where you can rebuild the world <lfam>At some point those efforts must come together to enable the binary distribution <lfam>vagrantc, I'm curious what elements of GuixSD don't really work for you <vagrantc>lfam: the main issue is probably the rolling release workflow <vagrantc>lfam: which is also it's strength, in many respects <lfam>There are so many trade-offs between rolling release and RHEL-style <vagrantc>i'm really interested in guixsd due to the clear intention with reproducible builds <vagrantc>and i do like the free software philosophy bent <vagrantc>though nixos seems to have a stable branch that's seems closer to a balance that i'd like to strike <vagrantc>but ... nixos seems to have a less strong strance on free software... so ... back to debian for me, most likely :) <buenouanq>I don't really understand, it's as stable as you and nonrolling as you want it to be... <lfam>My main system is Debian with almost all the packages from Guix :) <vagrantc>lfam: i was definitely thinking of experimenting with that approach <vagrantc>buenouanq: how do i get security updates without rolling up to the latest and greatest everything? <lfam>vagrantc: There are a few packages that need service orchestration or system-level support for privilege escalation, and those still come from Debian <lfam>But it works okay overall <vagrantc>lfam: yeah, i've got a debian vm with guix installed <vagrantc>lfam: oh, the other thing i found alarming is guix doesn't validate the signed git commits (yet?) <lfam>Yes, that's our big hole <lfam>But I'm reassured by the huge volume of serious bugs in all other software ;) <str1ngs>signed commits does not help ensure validity. git does that by nature <vagrantc>str1ngs: sure, you can have a malicious signed commit <str1ngs>it does improve on validity. but anything a invalid sig would catch. git would generally catch anyways <lfam>str1ngs: It's a different kind of integrity we're after with the signed commits. We want to make sure the commits were authored by a trusted contributor <str1ngs>lfam: trust is another story I agree. <str1ngs>and that won't stop a repository breach on savanna <vagrantc>but right now it's just mostly blind trust, as opposed to some sort of web of trust or even trust-on-first-use <str1ngs>substitutes are sighed though right? <vagrantc>yes, and you can prove they built what they were told to build, but how do you trust what they were told to build? <lfam>It won't help if no substitute is available, though <lfam>Yes, it's a problem, vagrantc <vagrantc>or at least, ideally you can prove it, if it's reproducible <str1ngs>I still trust guix's methods then some other distro's I have seen <vagrantc>i'd probably be more willing to experiment with guix and/or guixsd if that one issue was improved upon <adfeno>someone in a libreplanet talk once said something similar to this: trust, control and power are somewhat tempting to make someone cross the line of the acceptable towards other people. <lfam>Turns out apt didn't verify signatures until ~2 years ago <vagrantc>well, didn't verify signatures perfectly <adfeno>if one goes to all lengths to make things trustworthy even so as to block untrusted stuff, thn you might have a non-free software. <lfam>Only verified them if you weren't actually under attack <vagrantc>lfam: i think what you're referring to are bugs <lfam>Our problem is by design ;) <lfam>To quote Intel, "working as designed" <vagrantc>as long as it's treated as a bug that gets fixed promptly, i'm fine with that. nothing is perfect.