IRC channel logs

2018-10-03.log

back to list of logs

***tau is now known as Guest73120
***daviid is now known as Guest71064
***Guest71064 is now known as daviid
***nonlinear is now known as NB0X-Matt-CA
***nonlinear is now known as NB0X-Matt-CA
***nonlinear is now known as NB0X-Matt-CA
<nly>Hey, is there any way to install packages with an alias so they don't interfere with each other when working with diff versions?
<civodul>Hello Guix!
<efraim>hi!
<efraim>i'm looking at https://debbugs.gnu.org/cgi/bugreport.cgi?bug=32347 , doesn't look too bad to fix on master
<efraim>wrapping the input with package-with-bootstrap-guile doesn't change the derivation output and breaks the loop
<civodul>efraim: nice!
<civodul>if you want you can post what you have in that issue, along with a way to test it
<efraim>sounds good
<efraim>how are we with core-updates?
<efraim>i'd like to take out the special gcc-4.9
<efraim>and experiment with replacing it with gcc-5 for aarch64 with it's later bootstrap binary gcc
***Koragg is now known as Guest63827
<civodul>efraim: good question
<civodul> https://hydra.gnu.org/jobset/gnu/core-updates is midly encouraging
<civodul>*mildly
<efraim>i wonder if cross-gcc-wrapper should be package-with-bootstrap-guile or inherit gcc-boot0
<efraim>altough I suppose it inherits the gcc that's passed as an input, so it should be fine
<civodul>dunno
<civodul>did you have an immediate need BTW?
<efraim>nope
<roptat>hi guix!
<civodul>heya roptat!
<efraim>in commencement.scm:286, I think 'gmp-6.0' is supposed to just be 'gmp'
<snape>rekado_: when you next reconfigure Berlin there'll be some new Cuirass features ;)
<nly>What's the command to build pkgs for aarch6
<nly>aarch64
<efraim>if you can build it natively then it would be 'guix build foo [--no-grafts] --system=aarch64-linux'
<nly>Ty
<nly>What's does no grafts dom
<nly>do*?
***rekado_ is now known as rekado
<rekado>Hi Guix!
<civodul>hey rekado!
<civodul>snape, rekado: i just started 'guix pull' on berlin!
<rekado>nly: “--no-grafts” disables grafts, which is the feature we use to provide quick security fixes.
<rekado>civodul: thanks!
<nly>Ty
<civodul>rekado: perhaps at some point we should reboot to run the Shepherd 0.5
<rekado>today?
<civodul>whenever you think is a good time :-)
<civodul>as in, you can reboot it if something goes wrong :-)
<snape>no service can be upgraded without a reboot anyway, if my understanding is correct
<civodul>snape: with shepherd 0.5 'guix system reconfigure' can replace any service
<civodul>such that if you run 'herd restart foo' it spawns the new version
<snape>civodul: what I meant is that without a restart, shepherd isn't upgraded to 0.5
<snape>thus nothing upgreades
<civodul>oh right, that's why i said we should reboot someday :-)
<civodul>(meanwhile berlin builds the kernel...)
<g_bor>hello guix!
<civodul>hi g_bor!
<civodul>snape, rekado: upgrade complete!
<civodul>to commit ac4d2ec81a9f7c439b21b4c4ae4a2e949c78ab2e
<snape>civodul: to ac4d2ec81a9f7c439b21b4c4ae4a2e949c78ab2e? But it's quite old isn't it? No Shepherd 0.5.0...
<civodul>hmm hmm
<civodul>it's actually d7d1fc821091de98d66dac71ceed390d82434e40
<civodul>i was looking at the wrong guix
<civodul>bavier: commit d7d1fc821091de98d66dac71ceed390d82434e40 has an invalid email address in the Author field
<efraim>fun times, icedtea-6 for armhf-linux sometimes passes configure, then it fails with Error adding com (in directory lib/rt) to jar archive!
<civodul>snape: now it's running cuirass-0.0.1-19.8d40c49, which is the old one, no?
<snape>civodul:
<snape>indeed
<snape>maybe because you didn't "herd restart cuirass"?
<civodul>i run "herd stop cuirass" before reconfigure so that it would be restarted (it's shepherd 0.4)
<snape>but the reboot should have done the thing
<civodul>we haven't rebooted yet :-)
<snape>still? Oh
<snape>got it
***sturm is now known as sturm1
<snape>civodul: running "herd stop cuirass" before reconfiguring won't upgrade Cuirass
<snape>after the reconfiguration
***sturm1 is now known as sturm
<snape>that what's I was talking about when I said "a reboot is needed"
<civodul>but "guix gc -R $(readlink -f /run/current-system)|grep cuirass" tells me cuirass-0.0.1-20.fe2b73c
<civodul>might be a bug in how reconfigure handles shepherd 0.4
<snape>there is currently no way to upgrade a service without a reboot
<snape>civodul: yes
<snape>I think so tooo
<civodul>well before services currently stopped would be rebooted
<civodul>ok
<civodul>well
<snape>yes, but it doesn't work anymore
<civodul>rekado: would you like to reboot now? :-)
<civodul>snape: bummer
*snape is afk
<rekado>rebooting
<g_bor>rekado: looked a bit around, I used modules net,pxe,http,nfs,scsi,lvm,tftp and could do pxe over tftp and http, mount remote lvm and iscsi volumes, and nfs.
<g_bor>What exacly is needed for berlin?
<g_bor>grub forwards the requests to the platform firmware, so the pxe options available there are exposed to grub.
<rekado>g_bor: in the GRUB console I was not able to access the disks attached to the HBAs.
<rekado>g_bor: I could only see the disks that are connected to the internal RAID controller.
<g_bor>most probably you can do this by something like net root=(pxe).
<g_bor>I will give this a try here, and report back
<rekado>but why PXE boot?
<rekado>I’m not trying to boot over network
<rekado>I just want to specify the kernel from a disk that should be accessible through the HBA
<g_bor>I see that, but could not find a way around that yet. I'm still looking at options though.
<g_bor>What is the disk you are trying to reach? Is it an nfs volume, or something else?
<rekado>it’s a raw disk array
<rekado>i.e. a separate enclosure holding a bunch of disks
<g_bor>can you give me some info about the HBA you use?
<rekado>g_bor: here’s what lspci says about the internal RAID controller and the two HBAs: http://paste.debian.net/1045678/
<g_bor>thanks
<civodul>rekado: thanks for rebooting
<janneke>Hello Guix!
<g_bor>janneke: hello!
<g_bor>rekado: also, if you have some time when you can access the firmware interface of the host, you can check, if the devices are available from there. Grub actually piggybacks on services provided by the firmware.
<g_bor>So, if they are not available from there, then you can't see them in grub either.
<g_bor>rekado: you might also have to enable some options/map the storage in the storage configuration of the host.
<g_bor>Unfortunately our configuration is not exactly as yours, but these might help.
<mbakke>Hello janneke!
<janneke>hey g_bor, mbakke!
<mbakke>I've made some progress on removing the libstdc++ hack on core-updates-next.
<mbakke>The main culprit seems to be that "g++ -v" exits with status 1 and the error:
<mbakke> /gnu/store/qachfs4q8dk5cwgzpygifqhp260m6a3f-glibc-mesboot-2.16.0/lib/crt1.o: In function `_start': /tmp/guix-build-glibc-mesboot-2.16.0.drv-0/glibc-2.16.0/csu/../sysdeps/i386/start.S:113: undefined reference to `main'
<mbakke>*libstdc++-boot0
<janneke>mbakke: oh, great...!
<janneke>mbakke: those are two errors? or are you using "g++ -v" as a debugging tool?
<mbakke>janneke: I'm deep inside the libstdc++-boot0 configure script :P
<mbakke>It tests g++ -v at one point, and because of the exit status decides to skip all C++ checks.
<mbakke>Currently I'm trying to disable the "g++ -v" configure test. "gcc -v" fails in the same way, but the script does not care about that.
<janneke>Ah, I see.
<janneke>i don't see how "g++ -v" would print "undefined reference to main",...hmm unless g++ is a wrapper that I created and the wrapper is fubar
<janneke>mbakke: that's it!
<janneke>or..that may be it
<janneke>the wrapper changes `g++ -v' into something like -> g++ -Wl,--dynamic-linker -Wl,foo, -Wl,--rpath -Wl,bar -v
<mbakke>janneke: Right, I haven't studied the wrapper yet.
<mbakke>Aah.
<janneke>i'm not 100% positive, maybe 'foo' and 'bar' are causing the problem here...but it's suspicious anyway
<janneke>mbakke: yes, it's really the wrapper that should be smarter, i suspect
<janneke>with plain g++ 5.5.0, this: g++ -Wl,--dynamic-linker -Wl,/gnu/store/l4lr0f5cjd0nbsaaf8b5dmcw1a1yypr3-glibc-2.27/lib/ld-linux-x86-64.so.2 -Wl,-rpath -Wl,/gnu/store/bgc2ckrkyz5fg4sp278msyzxs5a30pwa-gcc-5.5.0-lib/lib -v
<janneke>also fails
<janneke>(sorry! :-)
<janneke>possibly we should wrap LD instead of gcc, g++ etc?
*janneke is adding debug printing to tcc and bisecting...trying to resurrect it with mes-pre0.18
<janneke>for the 3rd day in a row ... sigh
<mbakke>janneke: Disabling the "g++ -v" check makes the library build without the need to copy libstdc++.so.
<janneke>mbakke: very nice!
<mbakke>Now continuing on the GCC7 journey, I had a similar failure there which is why I started looking into libstdc++-boot0.
<janneke>ah right, you're looking into upgrading gcc
<janneke>very tedious, time-consuming work ime
<snape> https://hpcguix.op.umcutrecht.nl/ doesn't work. Is there another place where I could see hpcguix working?
<snape>answer: there is https://guix-hpc.bordeaux.inria.fr/browse
<Laalf>mbakke: are you planning to maintain the chromium? it seems like it will not be coming to guix (https://lists.gnu.org/archive/html/directory-discuss/2017-11/msg00003.html)
<Laalf>can someone tell me what an "invalid field specifier" is?
<snape>Laalf: well, we don't know yet if it will come to Guix
<snape>but it may
<Laalf>snape: nice to know. if that is. can other fsf approved distros also package chromium like that?
<snape>yes, once we're convinced it's free
<Laalf>great to hear
<Laalf>does "Invalid field specifier" mean that whatever i wrote there was not expected?
<snape>Laalf: I think it's about records
<pkill9>Laalf: this is more up-to-date: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=28004
<pkill9>i think it needs to be more de-google-ified
<pkill9>or something
<snape>This thread is the most up-to-date pkill9 and Laalf: https://lists.gnu.org/archive/html/guix-devel/2018-09/msg00264.html
<Laalf>snape pkill9 thanks for the updates.
<pkill9>ah it's not known if it's freely redistributable, that sucks
<pkill9>browsers have become huge monstrosities, maybe sometime jokes will be made that <browser> is an OS with everything you need, except a good browser
<janneke>browsers could do with a nice functional programming language, and emacs-like extensions when viewing pages
<nly>Has anyone used dovecot + exim?
<nly>I want to setup a mail server + whatever is necessary to receive mail
<snape>nly: I use dovecot + opensmtpd
<nly>Snape can you share your configuration?
<snape>nly: sure it's https://git.lassieur.org/cgit/emacs.git/tree/guix/config.scm
<divansantana>Anyone here using qemu with spice and got it working alright? Can perhaps share there setup?
<divansantana>I had it working, but after some recent update(last 2 months) it broke. Now when vm starts X logs in then it hangs shortly after.
<divansantana> https://paste.debian.net/1045719/
<Laalf>pkill9: grub is a good os. it even has a bootloader!
<pkill9>lol
<pkill9>nly: i heard it's difficult to run a reliable mail server, how true is this?
<janneke>50% true, 50% untrue; also depending on your definition of "reliable"
<lfam>Laalf, pkill9: So far, we haven't seen any reason to believe that the Chromium package that mbakke is working on is not free software. The remaining work is to make sure it follows the Free System Distribution Guidelines: <https://www.gnu.org/distros/free-system-distribution-guidelines.en.html>
<snape>well, the problem is that we haven't gotten in touch with people working on FSDG compatible Chromium for years
<snape>pkill9: the only real difficulty with mail servers is: dealing with spam
<snape>1. how to detect and filter spam out
<lfam>I don't think that's a "problem" or a reason to block mbakke's work
<snape>2. how not to be considered a spammer
<lfam>In general, we don't coordinate our packaging work with outside groups
<snape>lfam: I don't think either, as you know I've been the one pushing for weeks so that mbakke's work be merged
<snape>but even mbakke didn't want to merge it so...
<lfam>Yes, there is still some work to do. But I felt it was important to contradict the idea that it's not free software or can't be made acceptable for us and other FSDG systems
<snape>agreed
<Laalf>my problem is mainly plugins. i just looked through mine and i dont have any plugins that are not at least open source. the problem that plugins might not work with the finished product (you have to tell chromium to phone home, which maybe gets patched out?) really bugs me. stuff like browserpass might be additional pain
<lfam>Yes, it's possible that an FSDG Chromium will be missing some features we find useful
<Laalf>how would you put 20 different librejs plugins into a patched chromium if you cant use plugins?
<lfam>IMO the really important thing is that it can render HTML / CSS / JS without allowing remote code execution, and that it handles TLS properly. This is suprisingly hard
<lfam>I should clarify... *unwanted* remote code execution :)
<snape>and u block origin ;)
<snape>I can't live without it
<Laalf>i run chromium because i use MANY tabs at once and any firefox just breaks. as for plugins: darkreader, autoscroll and a password manager. i dont need more
<lfam>I have a few hundred tabs open in Firefox 62, it works great!
<snape>I have like 3 tabs. I don't (honestly) understand the point of using hundreds
<Laalf>i constantly break firefox with 300-400 tabs. gets really slow and sometimes crashes. i am fine with chromium.
<divansantana>Updated qxl qemu error/crash. Anyone have spice/qxl working? https://paste.debian.net/1045730/
<Laalf>snape: i dont use bookmarks. for ever folder of bookmarks someone else would create i just move them to a new window
<snape>I put links in an .org file instead
<roptat>info-dir-builder fails with no code for module (guix build utils)
<Laalf>divansantana: when i start qemu-system-x86_64 -vga qxl i dont have any problems.
<divansantana>hmm it seems using -vga virtio -display gtk,gl=on instead of sql fixed the issue.
<divansantana>Laalf: interesting. Which guest OS?
<Laalf>divansantana: none:D i dont have ovmf with libvirt running yet so i dont virtualize yet
<divansantana>Laalf: can you post your command to start the vm?
<Laalf>i litterally used qemu-system-x86_64 -vga qxl
<divansantana>oh. lol. OK, cool let me play around, though the new virtio graphics option may work for me. Thanks!
<lfam>snape: There's no point, believe me!
<lfam>I just can't bring myself to let go of them
<snape>:D
<lfam>It's like a bad version of keeping notes
<pkill9>lfam: when you say remote code execution, do you mean the page downloading and executing javascript from third party websites?
<lfam>pkill9: No, I mean unwanted remote code execution, not intended by the author of the site. Bugs in parsers and renderers, for example
<pkill9>ah
<lfam>Unfortunately very common still
<pkill9>how would an FSDG chromium create that problem? (i might have misread what you meant)
<lfam>Sorry, I was unclear. I was saying that even if things like plugins don't work, it will still be valuable to have a solid codebase that does basic browser stuff like rendering sites and doesn't screw up TLS
<lfam>So, even though our package will be lacking some features / misfeatures compared to upstream, it will still be useful to some people
<roptat>g_bor: for the confusion about hstore in my patches, I wonder if I should rename the extensions field to extension-packages?
<roptat>it would make it more explicit that the field should contain a list of packages, no?
<roptat>he :/
<d1rewolf>guys, where can i find a list of all the packages available from guix without installing it?
<pkill9>d1rewolf: https://www.gnu.org/software/guix/packages/
<pkill9>though annoyingly it doesn't have a search function
<d1rewolf>pkill9: sorry for asking something I should've solved myself by googling. i appreciate the reply ;)
<d1rewolf>pkill9: ugh...that does make it difficult
<pkill9>d1rewolf: np, if you wanna search for packages, put in duckduckgo/google "site:https://www.gnu.org/software/guix/packages <package>", that works for me
<d1rewolf>pkill9: cool. thx very much
<roptat>d1rewolf: there's also https://guix-hpc.bordeaux.inria.fr/browse
<d1rewolf>roptat: cool. thank you
<rockandska>Hi there
<pkill9>hi
<jas4711>any best practices on how to configure a guix server to automatically update important packages (linux + openssh)?
<Laalf>jas4711: guixsd doesnt have an auto upgrade feature at the moment. i dont think that anyone is working on one right now. nixos has one though. so maybe in some time it will be implemented
<nckx>g_bor[m]: Small typo in the blog post ‘GuixSD can be used on [an] i686, x86_64, and armv7 machines’
<jas4711>Laalf: thanks. i'll continue guix pull + reconfigure manually then. only show-stopper for a 1.0 for me
<Laalf>jas4711: thats great that it suits you. i got a few problems for me personally.
<jonsger>guix build with guile2.0 seems to be really broken :(
<nckx>Laalf: I'm all out of the Nix loop nowadays. Does it just do the scheduled equivalent of guix pull && guix system reconfigure? Or is it more than that?
<Laalf>nckx: it runs nixos-rebuild switch --upgrade. which is basically guix system reconfigure
<nckx>Laalf: Aight, thanks.
<nckx>That could easily be done as an mcron one-liner now, for long values of line.
<rockandska>Is there anyone who played with the last manifest format with "properties->provenance" ?
<jas4711>nckx: some intelligence is required to determine if the systems needs to be rebooted for the upgrade to have effect (i.e., if the kernel is updated, or if some upgraded service is unable to restart (shepherd?))
<rockandska>civodul: Hi ludo, Yoann there, do you have some time to spare to chat about our discussion to how reproduce a profile from the instantiate manifest ?
<nckx>jas4711: The latter should be done by 'guix system reconfigure' itself (I believe Carlo is working on it). I don't agree that rebooting is the job of an automatic updater. Who will enter your LUKS passphrase twice? ;-)
<civodul>rockandska: we can chat but i won't be 100% behind my IRC client :-)
<rockandska>civodul: ^^ no worries
<jas4711>nckx: great. sure, it can be optional, but for unattended servers rebooting on security upgrades is important
<nckx>Maybe g s r {c,sh}ould notify the user that a reboot is desirable if the path to the kernel changed.
<jas4711>nckx: yes. and guile.
<Laalf>do kernel modules get backed up before guix system reconfigure?
<Laalf>if not: that is 110% needed before auto upgrade gets rolled out
<nckx>jas4711: We'll just disagree on the unattended reboots point. No reason the admin can't add a tiny bit of code to the mcronjob to detect grub.cfg changes and reboot then.
<nckx>Laalf: 'backed up'?
<jas4711>nckx: i'm happy to add tiny bits of code :)
<rockandska>civodul: just wanna ask what is the true purpose of the instantiate manifest ? and there will be anyway to reuse the new informations inside it ( git repository ) ? could sound stupid, but is there no possibilities to write a file when generating the profile who contain all the original packages definitions + the list of the packages to reproduce the exact same environment ?
<civodul>rockandska: to reproduce the same environment you need the same Guix (+ additional channels), which is roughly what the 'repository' metadata gives us
<Laalf>nckx: they shouldnt be "deleted" or another symlink created while running. if i am at version 9 and upgrade to 11, i cannot use 11s modules. so i want 9s modules to persist until i reboot. i never tried out if they get removed
<rockandska>civodul: but a channel could be a local directory too. when you say "metadata", you talk about your last addition ( properties->provenace) ?
<civodul>yes
<civodul>but yeah i agree, channels could be local, which makes things more difficult
<civodul>there are a few pitfalls :-)
<civodul>it's comparable to reproducing the source code of a C program when all you have is a binary with debugging symbols
<rockandska>civodul: yeah but it is a great start for easy reproducible env
<civodul>yeah
<civodul>though again using the declarative approach upfront is even better
<civodul>"guix package -m", that is
<rockandska>there is no way to include directly all the package definition used for the generation ? this way, it could be reproducible even if the definition was coming from a local directory
<civodul>the short answer is no :-)
<rockandska>civodul: i understand your point for using "guix package -m" but from the point of view as a user, i think the users need an easy way to be able to put their env into a vcs and share them easily and use the instantiate manifest sound great at first for me before discovering it was not the purpose of it
<nckx>Laalf: Hm... By symlink or "deleted" (why the quotes?), do you mean /run/booted-system?
<nckx>Because note that it's distinct from /run/current-system.
<nckx>'current' is updated, 'booted' isn't. The booted kernel looks for its modz in $LINUX_MODULE_DIRECTORY=/run/booted-system/kernel/lib/modules.
<nckx>Does that make sense?
<Laalf>nckx: i dont know. i didnt look into the technical stuff behind guix too much yet.
<nckx>...oh.
<Laalf>great
<Laalf>so the kernel modules still work after you upgraded the kernel and didnt reboot
<rockandska>civodul: "the short answer is no" --> :'( that's really frustrating to not fully understand how Guix works because it was sounding so easy to do when i was thinking about it :p
<Laalf>nckx: "why the quote"? thats simple. i dont know if anything gets deleted or just symlinks removed.
<Laalf>i guess nothing gets removed until you run guix gc. but again: not so sure
<nckx>Laalf: Re-reading your question, it now makes sense when coming from a stateful/FHS/old-school distro mindset. I've gone full Kool-Aid.
<nckx>Laalf: re: gc: That is correct.
<rockandska>civodul: so for now, there is no way to reproduce the exact same environment from the instantiate manifest but only with a source manifest with the same guix / channels ?
<civodul>rockandska: the thing to keep in mind is that files you pass to "guix package -m", along with what "guix describe" shows, provide all you need to reproduce a profile
<Laalf>nckx: i spent very little time with nixos and went into guixsd. when i have a new gpu and ovmf with libvirt finally i am moving full time to it. but for that i need some help with libvirt. i will ask tomorrow since i need to get up in time. i guess i will get deeper into the technical stuff of guix when i am using it full time (at least privately)
<civodul>rockandska: trying to do it "the other way around" (i.e., starting from the result and from there inferring the source) is necessarily harder
<civodul>does that make sense?
<nckx>Laalf: Happy to hear that. Good luck :-)
<rockandska>civodul: sorry but not sure to clearly understand due to my lack of sleep ^^ and I just discovered the "guix describe" addition you add.
<rockandska>civodul: from what i understand , the "provenance meta-data" are only here to helping people to reproduce the env but the instantiate manifest could not be digest directly by "guix package -m" and for now, there is no way to reproduce an env directly from the instantiate manifets file ?
<civodul>rockandska: correct; the recommended way currently is to have a file that you then pass to "guix package -m"
<rockandska>civodul: ok got it thanks, and with "provenance meta-data" there will be eventually in a future a command to accept the instantiate manifest to be able to directly reproduce the env from it.
<civodul>rockandska: possibly, though like i said, it can't be as good as "guix package -m" since it has to infer bits of info
<rockandska>civodul: not sure to be the only one who need it, but maybe others would be interested to see how we could create a manifest from a current profile and containing the channel from where the package coming from and could be subject to a blog post ? :) i didn't see a manifest with the channel specifications for each package yet
<civodul>rockandska: we could definitely blog about this!
<civodul>this is all very recent
<rockandska>civodul: i don't get all the implication and sorry to bothering you because of my lack with guix, but it will be really a nice feature to have "guix package -i" etc.. generating a "file" (including provenance meta-data) who could be used directly to reproduce an env
<civodul>understood :-)
<civodul>and i agree it'd be nice
<civodul>all i'm saying is that it's not that easy, and using 'guix package -m' works today
<rockandska>it will be a killer feature (like relocatable !!!^^) because i encounter many times in my work the hell to reproduce an env and the fact that some package disappear from distribution repo or cause conflicts etc... and would love to push Guix
<rockandska>i fully understand that is not easy as i think and you all already do a awesome job :)
<rockandska>last question about "guix package -m" civodul, not sure it was clear in my last email, but did you see my request about be able to read the manifest file from stdin cause it is not possible at now ?
<pkill9>rockandska: not sure if it's helpful, but you can run previous builds of guix and it will use the package definitions that came with it, so as long as you have a record of the git commit, you can use `guix pull --commit=<commit> --build` and then it will create a symlink to that build of guix, then you do `<symlink>/bin/guix environment --ad-hoc <package1> <package2>` to drop into a shell with whatever packages
<pkill9>you want from that guix commit
<rekado>pkill9: it’s easier with the new “inferior Guix” support for manifests.
<rockandska>pkill9: thanks, but i would like to use it as a profile too and be able to use custom definitions not only the guix "commit" repository
<rockandska>pkill9: as discuss with ludovic, even if it seems not easy at it sounds, from a point of view as a user, the best experience will be to be able to reproduce a profile just be having it "manifest" inside vcs and be able to reproduce just by providing this file to a guix command who will be aware that X package is coming from channel X and package Y coming from channel Y
<pkill9>oh i see, yeah that would be neat
<freepotion>Hi! Can you tell me what hardware is supported in GuixSD? And what about devboards?
<georges-duperon>Hi Guix!
<georges-duperon>So, I'm updating a Makefile so that invoking `make' actually runs `guix build foo`, does the real work there, and copies the results out.
<georges-duperon>And I was wondering, what about actually writing the whole build recipes using Guix directly? i.e., each intermediate Makefile target would become a derivation.