<oriansj>simply use the go compiler's dependency resolution to sort through a pile of source files and produce a binary around the standard main <lfam>That's what I'm doing now, if I understand you correctly. The GOPATH is a long list of all the inputs, and the compiler looks for things in that list <lfam>If I made a union of all the inputs and set GOPATH to '.', that would be more idiomatic for sure <oriansj>I was thinking just a flat directory full of files with the sha256sum hash of the contents <lfam>Also, you can't have a flat directory in Go. They are super-picky about directory structures <lfam>Everything has to be laid out Just So <lfam>I think my current approach could work if I carefully controlled the order of the entries in GOPATH, but that really feels like the wrong thing <lfam>So Nix takes the union approach, assuming I'm reading their code correctly (big assumption) <oriansj>sometimes it takes a wrong thing to undo another wrong thing. <lfam>But in this case, building Syncthing in Guix is the right thing :) <lfam>I mean, having a generically useful go-build-system is the right thing <lfam>If I make to many hacks that feel wrong just to build syncthing, we might have to undo them all for the next Go package <civodul>you'll suffer a bit, but it's for the public good :-) <lfam>It's more than a bit. At least a byte <lfam>It's not expensive to change the go-build-system though. Rebuilding ~50 packages takes only ~30 seconds for me <lfam>For me, the tricky thing about the union approach is handling the host / build-side stuff properly. I guess I'd have to pass a list of go-packages into the build side and create the union there. Because I don't think I can figure out which inputs use the go-build-system from the build side <lfam>I don't have a strong enough sense of Guix internals to know if that stinks or not <lfam>Hence, at least a byte ;) <lfam>It also explains the comically long package names <oriansj>the most important part about guix is at its core, human written/useful code which is able to be understood and fixed. <oriansj>The second we forget that, is when long term issues start to fester. <lfam>Yes, but for the build-systems, you also need language-specific knowledge to understand things <lfam>It's not enough to understand Guix and Guile to also understand the build-systems <lfam>Sort of an annoying barrier to progress <oriansj>why expose bulid system specifics? it doesn't help either the developers or the users <oriansj>developers think in terms of what does their programs need to work (largely other programs required for the build) <oriansj>The users generally don't care about how a program is made, as long as they have it <lfam>Right, but somebody (in this case, me) has to understand both Go and Guix / Guile in order to achieve that goal <lfam>And of course the Golang people think we are crazy for wanting to create a generic abstraction of the build mechanisms <lfam>But their offering is insufficient in my opinion. All the big complicated Go programs have written their own dependency handling mechanisms <lfam>And those programs' authors grumble too <oriansj>lfam: and I am guessing those program's authors refuse to do any work to make their programs build work with nix or guix <lfam>Those programs use the standard Go mechanisms, which is fine. I don't think they could help any more except by not using 3rd-party dependencies, which is not really reasonable <lfam>They use the standard Go mechanisms for building that is. The dependency management is totally ad-hoc <lfam>I've talked to some authors of notable Go programs. They agree the situation is pretty bad right now <lfam>Maybe not worse than anything else... but with less time to paper over the problems with 3rd-party tools <oriansj>lfam: could we pitch guix being the 3rd party tool to solve their build problems? <lfam>If we can make a go-build-system that works generically in most cases, I think people would find it interesting, at least. But I think that in order to make it attractive enough for Go developers to start using it, we'd need to offer something more sophisticated than "one Guix package per Go library", since that's not how they work. Maybe a 'go-package' procedure that lets them stay closer to their workflow. This "vendor manifest" file <lfam>Since there are no Go library versions, every program that uses a Go library probably uses a different Git revision. This sort of thing is currently very cumbersome in Guix <lfam>I think you'd want to be able to specify the revision *in* the list of inputs <oriansj>lfam: why not treat git commit ids as versions? <lfam>So you'd have some sort of foo-library prototype, and you'd specify the revision when you use the prototype <lfam>Sure, but you might end up with dozens of package variants, and that seems cumbersome and also inefficient. Remember that we currently can't use very large package modules due to RAM exhaustion <oriansj>lfam: dozens of package variants simply means wasted space, the same if you needed multiple versions of a library like glibc <lfam>The paradigm in Go is very different from the one in the world of C packaging that we are used to <lfam>Like I said, there are no releases or versions <lfam>It's closer to how C libraries are deployed in embedded devices. If it works, ship it, and never support or use another version <oriansj>lfam, git commit ids are the same thing as version numbers if treated correctly <oriansj>simply think of the first commit as version 0.0.0.0.0.0 and each commit as incrementing the last digit <lfam>I think we are talking past each other <oriansj>I am attempting to express the idea of that go packages by using git implicitly have version numbers <lfam>My point is that Go developers won't want to use Guix if they have to make a package for every one of their dependencies, especially as their comes to be multiple versions of those packages. We'd need a better abstraction <lfam>Yeah, but nobody in Go pays attention to the commit ID / version number, AFAICT. If the latest one works, they use it. The next time they release their program, they try `git pull` for their dependencies and bundle the updated copy if it works <lfam>Anyways, I'm not trying for that now. For now, I want to offer Syncthing in Guix. After that, Boulder. <lfam>Hopefully we get IPFS too. And then we see what happens <oriansj>so, provide an abstraction like "LATEST" for the depency version <lfam>But their programs often don't work with latest. They work with whatever commit they tested with :) <oriansj>what if we simply walked back the dependency graph chronologically until the build works again and simply report what last combination worked? <lfam>I'd rather just use the commits they use, to be sure. <oriansj>lfam: I trust your judgement as you know far more about this problem than I do <lfam>I appreciate the conversation and suggestions :) It's much better than thinking about it by myself <oriansj>lfam: sometimes the solution we need comes from places we least expect <lfam>I have to assume we'll have a Syncthing package before FOSDEM (!), so I'm hoping to talk to this stuff with the Syncthing people then <lfam>I think that is a reasonable timeframe ;) <lfam>Hey, how is stage0 and mes? <lfam>Is replacing our bootstrap something that is on the horizon? <oriansj>rain1 found that tcc can build gcc and mescc is making progress towards building tcc. <oriansj>stage0 is slowly approaching bootstrapping mescc via mes <oriansj>stage0 broke off a piece called mescc-tools (currently in guix :D) <lfam>So, we need to finish stage0 -> mescc -> tcc? <oriansj>which aims to be bootstrapped from a tiny elf binary (there was a wonderful talk about it at GHM) <lfam>Or, stage0 -> mes -> mescc -> tcc? <lfam>Ah, I hope that talk is available <oriansj>lfam: actually the order doesn't matter as we are making a general solution to bootstrapping <oriansj>once mescc-tools is done, the mes bootstrap is done as far as guix is concerned <oriansj>(2 couple hundred byte binaries) hex0 and exec_enable, will simply bootstrap a macro assembler and build mes <oriansj>mes will run mescc (as it is a lisp interpreter) and mescc being a C compiler written in lisp will then compile the next step written in C <oriansj>thus far mescc-tools in guix is a pair of C programs (the M1 macro assembler and the hex2 linker) with a weird set of tests <oriansj>The tests actually are the pieces required to bootstrap the C programs in M1 Macro assembly <oriansj>stage0 has become a universal virtual build process, which always produces identical binaries regardless of the host platform. <oriansj>thus far stage0 has gained a garbage collected compacting lisp (6 months of work and counting) and a rather impressive FORTH (thank you reepca) <lfam>I hope there will be another presentation that I can attend <oriansj>janneke, rain1 and reepca do wonderful work. <lfam>It's really interesting work and I hope we can use it to bootstrap Guix <qwe123>x starts too late after doing guix system reconfigure with many "no protocol specified" on the console. <qwe123>i took about 3 minutes and i found new x-org-server started because i noticed new pid with new x-org-server. <efraim>woah, our weechat has gnutls and openssl as inputs <efraim>i'm switching it over to cmake now, its a cleaner build <rekado>./pre-inst-env guix environment --pure guix --ad-hoc guile-git <rekado>but guile tells me it cannot load the git module. <rekado>sneek: later tell lfam The comment about bash/texlive is incorrect in the current version. I have WIP that makes it correct. <efraim>I noticed that we build Qt with mysql, and our default mysql service uses mariadb <Steap>I know I've been away for a long time, but you're not nice, Guix! <Steap>I'm running "# ~root/.guix-profile/bin/guix-daemon --build-users-group=guixbuild" <Steap>and from the Guix git directory: <Steap>$ ./pre-inst-env guix package -i hello <Steap>guix package: error: failed to connect to `/usr/local/var/guix/daemon-socket/socket': Connection refused <Steap>(it works as expected without "./pre-inst-env") <Steap>what might I be doing wrong? <civodul>Steap: most likely you're using a different localstatedir <civodul>that is, guix-daemon listens on /var/guix/daemon-socket/socket (localstatedir=/var) <civodul>but your client tries to talk to /usr/local/var/guix/daemon-socket/socket (localstatedir=/usr/local/var) <civodul>try configuring your Guix checkout with --localstatedir=/var <civodul>didn't you get a configure warning for that? <civodul>anyway, try passing --localstatedir=/var and let us know how it goes :-) <civodul>it looks like Guix punishes those who leave it for too long ;-) <Steap>I take it that I can work like this as long as I don't need to hack the daemon, right? <rekado>my problem with guile-git is again hard disk corruption :( <rekado>maybe now is a good time to ask this: are there any special settings I should have set for using an SSD? <rekado>I’m compiling code on this machine almost every day. <efraim>It should be fine. If you're really worried you could make /tmp a tmpfs, which should be faster than an ssd anyway <rekado>efraim: thanks for the confirmation <ng0>sneek: later tell efraim: one of the packages you reorganized of Mate made the panel/bar no longer display the active windows in the bar <ng0>sneek: later tell efraim: taking a break now, maybe I have time to look into it later today. the panel symbols look better, but windows not being in the bar is probably not something people want if they have the option ;) <civodul>Steap: you can also run the daemon from your checkout with "./pre-inst-env guix-daemon --build-users-group=..." <civodul>rekado: i use an SSD without any special settings, FWIW <civodul>yeah for that you need to make sure you have the right dependencies available <Steap>yeah, I have ~/.guix-profile/share/guile/site/2.2/{gnutls,ssh/auth}.scm <ng0>or is it just "cputime"? <ng0>ACTION goes read the source <ng0>unit testing and mocking framework for C/C++ <- best place would be cpp.scm ? <ng0>I see nothing like "test-frameworks" or something <ng0>same file as gtest or gmock would be an option thougfh <ng0>ah, both are not packaged just mentioned or bundled. I'll just pick one. <ng0>gtest is googletest btw <ng0>some packages reference it as "gtest" with an TODO note <sneek>Welcome back efraim, you have 2 messages. <sneek>efraim, ng0 says: one of the packages you reorganized of Mate made the panel/bar no longer display the active windows in the bar <sneek>efraim, ng0 says: taking a break now, maybe I have time to look into it later today. the panel symbols look better, but windows not being in the bar is probably not something people want if they have the option ;) <efraim>Hmm, maybe something about applets <efraim>i'd try mate-panel without the --in-process-applets, not sure if that'd make a difference or not <efraim>i think that and alphabitizing were teh main things I had for that package <ng0>yep, the configure switc hwas new <ng0>it improved the quality of the bar symbols (great) but did something with the ability to display windows (bad). We can investigate that <ng0>I've put ccputest in check <ng0>I have 2 or 3 hours, I'll see if I can find a fix for Mate <ng0>maybe another distro had this error before <ng0>I'll fix up the weechat tests first, then mate <ng0>okay, I had to add something to the bar <ng0>"Add to Panel" > "Window List" <ng0>no idea why it dispeared before <ng0>would be nice if we could instruct weechat to use a /gnu/store/…weechat-scripts instead of the server url. <ng0>cmake .. -DENABLE_TESTS=ON it was <civodul>Apteryx: looking at your bluetooth-service patch, is it on purpose that 'auto-enable?' is #f by default? <ng0>in weechat terms, is "autoenable" the same as "autoload"? <civodul>bluetooth is unrelated to Weechat i think :-) <ng0>I don't see when people join or leave <ng0>I am working on "scripts" for weechat <ng0>so instead of querying the weechat.org/bla/bla.tgz using the store <Apteryx>civodul: yes! To keep the same behavior as currently (bluetooth controllers are off without user explicitly turning it on) <ng0>if you enable a service, don't you want it to be active? <ng0>or do you mean it to be used with herd start servicename? <Apteryx>Right... Is this service not part of base services... let me refresh on this. <Apteryx>Hmm. I think to leave this auto-enable off is better by default. I'm using a barebone WM but for Gnome users, there is probably some applet which would keep track and remember your bluetooth controllers power state (enabled/off). Setting auto-enable to default couild clash with expected behavior of such tools. <ng0>will you / have you added a note about this to the documentation of it? <Apteryx>ng0: the service will provide you with the means to control your bluetooth devices. Whether such devices should be enabled at boot or manually should be left to the user to configure in my opinion. <Apteryx>I did document the effect in our user manual. <ng0>in (define (clang-runtime-from-llvm llvm hash) tests are #f with the comment "require gtest". Do we want them to be enabled? <ng0>or is there some other reason they are off? <ng0>refresh my memory, how can I build packages that are not define-public? via repl and use the module? There must be some guix function I forget <ng0>it is used in clang-runtime though, so I can just build clang-runtime <rekado>ng0: you can tell “guix build” to evaluate an expression and build the resulting value <efraim>Guix build -e '(@@ (gnu packages foo) bar)' <nee`>Hello, is there a guide to installing guixsd over an existing os? Is it enough to just run `guix system init os-declaration.scm /` and reboot? <cehteh>nee`: that would certainly leave some cruft around, but you may try to test that in a VM <Apteryx>I borked Guix with by running the garbage collector. I now get: ERROR: In procedure dynamic-link: file: "/gnu/store/17cs0py0x4iy258bfldc78bni3i0k7cq-libgcrypt-1.7.6/lib/libgcrypt", message: "file not found" <Apteryx>I downloaded the binary installer and there is a copy of the needed store item (libgcrypt-1.7.6), but copying it into my gnu store is not a good idea, right? What should I do? <Apteryx>I will attempt something from the USB installer. <efraim>it seems our quassel bundles inxi and mpris ***abbe_ is now known as abbe
***bmpvieira__ is now known as bmpvieira_
***luto___ is now known as luto
<efraim>can someone check 'guix size quassel' for me? my connection is bad enough i'm not getting a response from the substitute servers and I don't want to build it from source <lfam>Are there any procedures in Guix or Guile for checking if a directory is empty? <sneek>Welcome back lfam, you have 1 message. <sneek>lfam, rekado says: The comment about bash/texlive is incorrect in the current version. I have WIP that makes it correct. <efraim>we have a file-exists? option, which can be a directory <lfam>I have a situation where I need to create a directory in case some other tools want to use it, but I would like to ignore the directory later if it's empty. <lfam>Hey, you should try my latest go-build-system with Syncthing. I just removed Syncthing from my pkgs repo <lfam>I think there are still a couple rough edges and unanswered questions, but it's pretty close to being done. <efraim>i could put my gccgo patches on top of it and try it out on aarch64 <lfam>I just added an XXX comment to (guix build go-build-system) and pushed again <lfam>Or put this on top of your gccgo packages. It shouldn't matter to the build system how the Go compiler is built. It just assumes there is a `go` package that it can use <lfam>But, this works for syncthing. I'm using it now <efraim>i got gpm building again after the 'autoconf patch <lfam>Oh, it already has the #:go key, efraim. <Apteryx>Managed to fix my Guix by running the GuixSD installer, running `guix pack guix', mounting my system partition in /mnt and then extracting the guix pack to /mnt; updated {~,~root}/.config/guix/latest to point to the fresh Guix! <Apteryx>I'll be sticking to 'guix pull' for a while to try it out. <nee``>Hello, I installed a broken guixsd config. On boot I get dropped into a guile REPL after a partition failed to resolve. Is there any way I can inspect the filesystem and edit text files and do something to fix this? <rekado>nee``: you can use “scandir” from (ice-9 ftw) to list directory contents. <rekado>can’t you boot the previous system? <Apteryx>nee``: the easy way would be to use a previous (working) generation from the grub boot menu and fix your config file at ease there. <nee``>I don't have a previous system this is my first install on this server. <civodul>Apteryx: you seem to be doing crazy stuff :-) <rekado>nee``: can you boot the live system? <nee``>No, I tried to install it from a debian system on a second partition, but overwrote the previous grub since it's only one disk. I can probably boot debian somehow through the grub console. <Apteryx>civodul: Eh! I got into trouble running Guix from git and garbage collecting parts of it (wasn't registered). In retrospect I could have probably just pointed ~/.config/guix/latest to an old guix entry in /gnu/store; although I'm happy I learned that 'guix pack' can be used as a recovery tool! <nee``>I don't see any /dev/sdaN partitions. I was on debian with guix installed, mounted the guix-sd partition in /mnt and called `guix system init /mnt/etc/config.scm /mnt/` with a config very much like this: http://paste.lisp.org/display/355075 <civodul>Apteryx: that's clever, i wouldn't have thought of using 'guix pack' for recovery <Apteryx>(unless I forget to put the argument ;) <Apteryx>civodul: When using Guix from git, is it supposed to be registered as a gc root? If so, by what mean? <civodul>Apteryx: no, there's nothing special to do <civodul>the only problem really is if you run guix-daemon that you built yourself, *and* you built it with a different localstatedir <Apteryx>Hmm. I just checked under /usr/local aln there was nothing related to Guix there at least an old acl file. <Apteryx>So it seems this doesn't explain it. The library that got garbaged collected was libgcrypt 1.7.6 (hash: 17cs0py0x4iy258bfldc78bni3i0k7cq).