IRC channel logs


back to list of logs

<isthis4real>what is diff between #guix and #bootstrappable
<alloy>leoprikler: u-boot definition is easy through the make-u-boot-package procedure. bootloader install needs a gexp as it uses install-file to move the u-boot.bin to the boot partition. When defining the os the initrd-modules need an empty list, because the linux-libre-arm-generic kernel is required (doesn't provide most of the initrd modules and they don't seem to be needed).
<bluekeys>Hi guix, does anyone use use-package? It's trying to download from melpa, but I don't want it to, I just want it to use guix packages
<alloy>leoprikler: And one has to consider setting up the a boot partition as vfat and marking the main ext4 one as bootable for u-boot to find it.
<isthis4real>gpg --verify run as user or root doesnt seem to even "end" nothing happens, theres an empty line added to terminal as though the command is running, but thats it
<isthis4real>in the steps to install binary
<leoprikler>bluekeys: you'd have to write use-package bindings for emacs-guix to work, and that is probably very hacky
<leoprikler>s/to work/for that to work/
<oriansj>isthis4real: the difference between #bootstrappable and #guix is #guix is the general help for guix and discussion about guix and #bootstrappable is where the bootstrapping of all Modern software is taking place (using guix as a tool for the levels above GCC 4.7.4)
<oriansj>as per the steps provided, you need to first sudo su and do the steps as root
<oriansj>gpg --verify should take approximately 2 seconds, unless you are on a low power system and untar should not cause memory exhustion unless you have less than 256MB of RAM
<bluekeys>bye guix
<isthis4real>above gcc 4.7.4? isnt gcc like 9.2? how is this modern?
<isthis4real>i was able to tar in another folder now, no errors...
<isthis4real>gpg --verify - still doesnt seem to work
<isthis4real>i may have noticed the same hanging/not working gpg --verify command before on other distros...
<isthis4real>bootstrapping...still dont compiling? or creating packages for guix format?
<oriansj>isthis4real: bootstrapping as in I handwrite all the software required to build a cross-platform C compiler and can build it all starting with a 357byte hex0 assembler that I wrote in hex
<nckx>isthis4real: Because this is about bootstrapping, which happens in different intermediate steps; you can't build GCC 9 from nothing. Or indeed a lot of something, if that something can't compile C++.
<isthis4real>is this...related to guix primarily? im not seeing the link yet
<isthis4real>guix was in the topic in bootstrappable...
<oriansj>isthis4real: no, bootstrapping is universal for all operating systems on the planet which want formal proof of no trusting trust attack backdoors
<oriansj>bootstrapping is also being done on bare metal
<oriansj>No operating systems or Firmware or microcode
<oriansj>just pure logic gates running code bootstrapped from a hex-monitor hand toggled into memory
<isthis4real>so hex0 you created from... hexlang? is this like typing 0-F characters all the time (hexadecimal)
<oriansj>isthis4real: no
<isthis4real>which hex...3 letters in google search drives me crazy...
<isthis4real>too many acronyms related to computers or anything else really
<adjtm>hi everyone
<nckx>isthis4real: The hex just stands for hexadecimal; as far as I know hex0 is its own thing, not ‘based on’ anything (except in spirit).
<adjtm>I'm a Replicant (Android distribution) contributor and we have been researching lately the chromium freedom issues
<oriansj>isthis4real: well if you read one of the files you will see: that I handwrote the ELF header and have functionality for reading characters from a text file and converting it into a binary file
<adjtm>we are planning to use ungoogle-chromium guix sanitized source tree for building webview (we don't distribute the chromium browser, but webview is the browser component part of the android api)
<oriansj>which is then used to build a macro assembler and then a C compiler that then builds a cross-platform C compiler written in C
<adjtm>what's the easiest way of downloading the guix ungoogled-chromium source tree from a distribution without the guix tool?
<oriansj>The steps of how it does that is in here:
<adjtm>I want to check the guix signing of the source package
<oriansj>adjtm: wget usually
<adjtm>oriansj, what's the URL?
<oriansj>depends upon the package but the package definition usually includes that info
<adjtm>(define-public ungoogled-chromium
<adjtm> (package
<adjtm> (name "ungoogled-chromium")
<adjtm> (version %package-version)
<adjtm> (synopsis "Graphical web browser")
<adjtm> (source ungoogled-chromium-source)
<adjtm>I don't know the ungoogled-chromium-source url
<adjtm>I have never used guix, so I know nothing about where it downloads the source packages from
<adjtm>in it says: running
<adjtm>`guix build --source ungoogled-chromium` will run the pruning scripts
<adjtm>and generate a sanitized tarball, or (more likely) transparently
<adjtm>download an already-processed source from the build farm.
<adjtm>I want to download the already-processed source
<oriansj>adjtm: if you look for define ungoogled-chromium-source in gnu/packages/chromium.scm you will see the url
<adjtm>I don't find it there, do you mean: ?
<oriansj>adjtm: it says: (uri (string-append "" "/chromium-browser-official/chromium-" %chromium-version ".tar.xz"))
<adjtm>oriansj, but that's the not processed source code, not the sanitized one, right?
<adjtm>I could install guix, and run the guix tool
<oriansj>correct, it looks like guix also performs multiple steps to ungoogle chromium
<adjtm>which it will download the processed tree or sanitize it itself
<oriansj>but it doesn't have a repo with that work predone
<adjtm>but I would like to download the preprocessed package
<adjtm>oriansj, but the guix tool downloads the processed package if its cached by the build farm, how can I get the cached tree?
<oriansj>adjtm: you mean just the built binary?
<adjtm>no, the source code
<adjtm>running `guix build --source ungoogled-chromium` will run the pruning scripts
<adjtm>and generate a sanitized tarball, or (more likely) transparently
<adjtm>download an already-processed source from the build farm.
<oriansj>adjtm: guix downloads several pieces of source code in that script and pieces them together
<adjtm>so the easiest way of getting the sanitized tree is installing guix and running guix, right?
<oriansj>adjtm: generally yes
<adjtm>what's the guix command to download the source tree and processing it without building?
<oriansj>adjtm: guix download
<adjtm>guix download --source ungoogled-chromium ?
<adjtm>will that sanitize the source code?
<adjtm>or it will be before doing it?
<oriansj>or guix archive --source
***jje is now known as Guest54965
<adjtm>oriansj, rereading your comments suggest that guix downloads a .tar.xz of the source tree, so we should probably get the git repository of the dirty ungoogle-chromium tree, download the guix clean scripts and run on top of it, then commit the cleaning process
<adjtm>it's not ideal, but from our research the guix source tree is the only one that we can trust
<adjtm>the guix's cleaned source tree
<adjtm>dllud, does FSDG allow building from git repositories? I ask that because if the source had freedom issues in the past, the user could checkout previous commits and build a version with the freedom issues
<adjtm>we download git repositories with all the history
<dllud>adjtm, I am not certain, we may get the answer by looking at how linux-libre does it
<oriansj>adjtm: we build all the time from git repos
<adjtm>I wrote all the last messages in the wrong channel, but I think that it doesn't matter
<adjtm>I now very little about FSDG, don't take anything I ask too seriously
<adjtm>mbakke, do you have anything to say about what I have asked about ungoogled-chromium?
<adjtm>oriansj, we also do
<adjtm>I suppose it's ok
<adjtm>oriansj, I suppose that guix build --source downloads a tarball so the user never builds from the git repository, am I right?
***jje is now known as Guest9381
***jje_ is now known as jje
***jje is now known as Guest32210
<gnutec>Don't foget to download the manual of Guix.
<gnutec>For any reason, there is not link to manual in the first guix page.
<adjtm>gnutec, thanks for the link, downloaded
<gnutec>adjtm: :)
<adjtm>maybe I will give guix a try, there are not many interesting distributions ;)
***jje_ is now known as jje
***jje is now known as Guest87749
***Guest87749 is now known as jje`
***jje_ is now known as jje`
***jje` is now known as jje
<peanutbutterandc>Question: Is there a way to get guix-installed packages to show up in the menu automatically (on a foreign distro, of course)? Any triggers? Configurations? Anything?
<peanutbutterandc>I know flatpak-installed apps show up in the menu, and can be selected to be the default file opener.
<peanutbutterandc>Also, is down right now
<peanutbutterandc>The IRC really is quiet today. Very unusual. o.O
<efraim>It's Sunday
<peanutbutterandc>efraim, I see. That makes sense. Do you happen to know if there's a way to have guix-installed packages to show up in the menu? Are there some triggers, etc?
<efraim>peanutbutterandc: I don't know of any offhand. Last time I tried was a couple of years ago, I normally stick with CLI programs when on a foreign distro
<efraim>I would think messing with the XDG environment variables might do it, but it can have nasty side effects
<peanutbutterandc>efraim, It would be great if guix could do that too: just like flatpak
<efraim>Definately worth looking into. I'll have to see how flatpak does it
<peanutbutterandc>Also, another question: guix lint says "scheduled software heritage archival" and "the source file should contain the package name" for this package:
<peanutbutterandc>I am not sure I understand what they mean. Here's the full lint message (I've fixed all but the two at the top and the bottom):
<efraim>for chordpro, before the sha256 line, you should add (file-name (git-file name name version))
<efraim>without it the source download in the store will be /gnu/store/...-checkout, with it it'll be /gnu/store/...-chordpro-0.974_017-checkout
<efraim>the software heritage line I think means we've triggered some API for software heritage to get them to archive the sources
<peanutbutterandc>These (file-name) etc. things... they aren't documented, I don't think... are they?
<peanutbutterandc>Don't remember seeing them in the reference manual. Also, I suppose file name is only used for git checkouts, right?
<peanutbutterandc>Also, just looked up 'Software Heritage'. Whoa. Cool. Does that mean that if, somehow, the original source goes down, and Software Heritage has the files, guix will automatically - without any changes to the package definition - use the Software Heritage version?
<peanutbutterandc>Question: why (file-name (git-file name name version)) and not just (git-file name version)? Could you please explain that procedure to me please? I'm a n00b.
<peanutbutterandc>also, git-file seems to be undefined. Which module do I need to import to be able too use it?
<peanutbutterandc>Oh! I got it now! It's (git-file-name name version)! Thanks!
<roptat>hi guix!
<peanutbutterandc>Hey there!
<leoprikler>peanutbutterandc: file-name is the field you're setting and (git-file-name name version) is its value (after eval)
<leoprikler>those fields are documented as part of the package reference (6.2.1 if memory serves)
<peanutbutterandc>leoprikler, I see. Thank you. (I meant git-file-name procedure.) Anyways, do you happen to know if there's some sort of trigger etc that could be used to get guix-installed packages show up in the GUI, menu etc?
<mbakke>adjtm: did you find out what you needed?
<mbakke>adjtm: note that ungoogled-chromium will be removed from Guix soon, see
<efraim>peanutbutterandc: sorry I didn't mean to disapear, my irc client seems to have stopped updating
<peanutbutterandc>efraim, It's all right. I understand. No worries. (:
<peanutbutterandc>What is the IRC-client of choice around here, BTW/
<efraim>i like quassel
<efraim>sometimes I use weechat
<peanutbutterandc>I see
<count3rmeasure>whoever wrote elf.scm
<count3rmeasure>thank yo
<count3rmeasure>literally none of this was meant to be sent, the joy of switching windows. but anyway, thanks!
<efraim>I've commited an os-config (container config really) to my guix channel and it broke my guix pull with an error ' (value ("no code for module" (gn services bnw-container))) (value #f))' Any suggestions what I might be missing from the file? Just a header declaring that it is a module?
<efraim>bayfront seems to be down
<sturm>hi folks, when I run `guix pull` as root on my Guix System in preparation for a reconfigure, I get: guix pull: error: Git error: object not found - no match for id (229818064a154a38dff1c0a9a6bc3ba66a2d4925). That's a bit strange because guix pull as my regular user worked and gave me the mentioned commit.
<raghavgururajan>sneek later ask civodul nckx mbakke After removal of ungoogled-chromium from guix, is there a viable replacement that can be an alternative to icecat, by having a different rendering engine from icecat? I have seen some web pages performing differently between web-engines gecko and blink. :-)
<sneek>Will do.
<oriansj>raghavgururajan: well there is qutebrowser which is based on webkit; vimb which is based on webkit; sbcl-next; luakit; dillo which has its own custom engine; surf; netsurf which has its own custom engine; emacs-w3m if you tend to go overboard with emacs...
<leoprikler>epiphany based on webkit :)
<leoprikler>we have a lot of webkit-based browsers
<oriansj>and non-webkit-based browsers
<oriansj>Ironically no torbrowser though
<oriansj>but we do have onionshare and eschalot; which is nice...
<leoprikler>does icecat not come with some tor plugin?
<oriansj>leoprikler: the tor project stopped developing the independent tor plugin a while ago if I remember correctly.
<bluekeys>Hi guix. I'm trying to get started using swiper and counsel, emacs-ivy exists, but swiper and counsel don't. I've tried using guix import elpa -a melpa-stable swiper > swiper.scm and then guix package --install-from-file=swiper.scm but it didn't just magically appear! I added a few use-modules statements, but am now stuck on an error message about invalid keyword in url-fetch
<leoprikler>bluekeys: can you paste your swiper.scm?
<ArneBab>Why is ungoogled-chromium removed?
<bluekeys>Sure, pastebin?
<leoprikler>whichever paste you prefer
<leoprikler>(here on guix we use debpaste tho)
<leoprikler>instead of (guix build download), use (guix download)
<bluekeys>Wow! It worked... This is really great. How would I go about getting it added to the main repo?
<leoprikler>fix the license (elpa seems to always return #f), add it to a local copy of guix, verify that it builds and then send the patch to
<leoprikler>you may want to read the contributing guidelines
<leoprikler>("C-h i m Guix RET m Contributing RET")
<bluekeys>Thank-you very much
<oriansj>ArneBab: the short answer with guix is usually if no one is willing to deal with something it is removed; if someone wants something badly enough it'll be accepted one way or another. It is very much a whoever does decides culture.
<bluekeys>Have a nice day/night everyone. Bye guix
<PotentialUser-96>hi, how to install remmina?
<oriansj>PotentialUser-96: well according to guix package -s remmina; we currently don't have a package, which means a package definition needs to written first to build it.
<oriansj>but after that you can use that definition with guix package -f filename.scm to install it
<oriansj>or after it's package definition gets absorbed into guix: guix package -i remmina
<PotentialUser-96>well, does guix have alternative to have rdp connection to server?
<str1ngs>oriansj: dont' forget nomad, based on webkit. and uses guile for extension :P
<oriansj>str1ngs: haven't seen that one yet; thanks for the tip
<str1ngs>oriansj: it's pretty new and WIP
<str1ngs>note, I'm biased because I'm the author :P
<oriansj>str1ngs: got a link?
<PotentialUser-96>can somebody suggest how to add and up vlans within guixsd?
<str1ngs>oriansj: not much in terms of docs/website yet
<oriansj>str1ngs: pretty common when you are more striving to make it work the way you want
<str1ngs>oriansj: if you are familiar with emacs most thing just work. but mainly the API is still in flux so hard to document
<amz3>PotentialUser-96: what is rdp?
<str1ngs> remote desktop protocol
<oriansj>PotentialUser-96: for adding vlans: ip link add link eth0 name eth0.100 type vlan id 100 as for upping in guix, I honestly don't know as it isn't something I generally use
<amz3>ok got it
<oriansj>PotentialUser-96: the Linux standard alternate to rdp is ssh
<oriansj>ssh -x if you want pretty graphics from the server
<str1ngs>maybe X11 forwarding is comparable yeah
<str1ngs>probably VNC is more like RDP though
<adjtm>mbakke, thanks for your reply, unfortunately webview is a hard dependency for us, because it's an android system component and many apps use it for rendering their GUI
<oriansj>generally servers don't have GUIs as that is a waste of resources
<oriansj>also a massive potential source of vulnerabilities
<adjtm>mbakke, I understand that for guix using firefox based browsers instead of chromium based is a minor issue
<adjtm>even if we could make a webview shim for gecko no app developer would test their GUI with it and I will probably break a lot of apps
<PotentialUser-96>the problem is I need to admin windows server =(
<str1ngs>adjtm: it might be best to start with
<adjtm>str1ngs, that's our current plan: use ungoogled-chromium with guix cleaning script
***leoprikler` is now known as leoprikler
<oriansj>PotentialUser-96: freerdp + leverage Powershell and Desired State configuration
<str1ngs>adjtm: that should give a generally overview of ungoogled. then you can reference and guix patches. which there are probably not many of. from my understand based off of debian
<adjtm>str1ngs, that would probably break webview build, but we can start from it
<adjtm>str1ngs, right now I'm building ungoogled-chromium-android which is a fork of ungoogled-chromium to build android's chromium and webview
<str1ngs>adjtm: I have been starting to look at the build process myself. I plan to possibly use CEF for nomad. which should simplify the blink backend for nomad
<str1ngs>ungoogled-chromium-android seems interesting . might be another useful backend for nomad
<efraim>is 4GB of RAM is low for compiling icecat?
<str1ngs>efraim: yes, but if you are not using many cores might not be too bad
<efraim>I have two on this machine
<str1ngs>you might be okay, but it could take a very long time
<adjtm>str1ngs, mbakke: it would be ideal if we had a cleaned fork of chromium from where we could all build it for our distributions
<str1ngs>adjtm: also I would concider qtwebengine. it's ungoogled by default and works on android
<str1ngs>adjtm: I have a working declaration for guix if you are instrested
<adjtm>str1ngs, we need a webview component, I suppose that qtwebengine doesn't provide webview interface
<str1ngs>actually on android I think it uses QtWebView
<adjtm>so in the end it uses the system webview?
<str1ngs>I'm not 100% sure.
<str1ngs>is your current stack using Java?
<adjtm>str1ngs, ungoogled-chromium-android has still some problems half of them I think would be easy to solve
<adjtm>str1ngs, this is for the Replicant distribution
<adjtm>we build a complete android ROM
<PotentialUser-96>does you support firefox in any way?
<adjtm>PotentialUser-96, who is your question for?
<str1ngs>adjtm: ungoogled-chromium-android sound like the better choice here
<PotentialUser-96>to somebody who use firefox
<leoprikler>guix has icecat, which is a debranded firefox
<leoprikler>I personally use neither, though
<oriansj>PotentialUser-96: guix includes icecat by default but there are vanilla firefox package definitions available
<oriansj>str1ngs: nomad/guix/gnu/packages/nomad.scm :: error: emacsy-minimal: unbound variable
<str1ngs>oriansj: noamd is in guix, you'll need the dependencies
<PotentialUser-96>where find all definitions?
<str1ngs>oriansj: guix install nomad . should just work
<str1ngs>oriansj: also are you sing guix 1.0? without a pull?
<oriansj>str1ngs: 1.0.1-3.4a54ed7
<str1ngs>oriansj: what does guix describe output?
<oriansj>str1ngs: error: failed to determine origin (I do blind builds)
<str1ngs>blind builds?
<oriansj>str1ngs: there is no time or environment or anything except source code and compiler binary
<oriansj>even the file names passed are fake and randomly generated;
<str1ngs>if you are locally building nomad, you will need the dependencies. in this case emacsy-minimal
<str1ngs>guix.scm and guix/gnu/packages/nomad.scm are really only used for development. the recommended installation is to use guix install using the guix proper expression
<oriansj>got it, I'll add it to my build queue
<str1ngs>oriansj: though if guix pull is upto date. guix build -f ./guix.scm should work as well
<oriansj>str1ngs: well I always end up running a little behind (cost of building everything local)
<str1ngs>do you use your own substitute server? might be a good way to cache files etc
<oriansj>str1ngs: all systems build and there are spot checks for variances.
<oriansj>there is only a single caching server for the source tars
<oriansj>it is to ensure that any compromise would have to effect ALL systems at the same time (Including those that are eternally offline)
<oriansj>but I guess it is just a side effect of my day job.
<str1ngs>oriansj: if you have problems let me know. there is also #nomad-browser. you can ping me there
<oriansj>str1ngs: good to know ^_^
<str1ngs>oriansj: the feature-g-golf branch is much more bleeding edge. and gives a better indication of what the future will hold.
<oriansj>I am usually on #bootstrappable as I am working on changing the guix bootstrap with janneke and a bunch of fun people
<str1ngs>interesting. I've been meaning to look at mes. I have my own package manager that has really low dependencies. and I was thinking of checking out mes for bootstrapping
<str1ngs>it also supports things like rootless cgroup containers.
<str1ngs>IPFS for P2P package distrobution
<oriansj>you might wish to checkout
<str1ngs>mescc look like via would really benefit from. via is the package manager
<oriansj>I bootstrapped a Cross-platform C compiler from a 357byte hex0 assembler; that I hand wrote
<str1ngs>via needs 0 system dependencies to install packages once it's built
<oriansj>and I am currently doing the mes-m2 port: which will provide the whole mescc toolkit and bootstrap of guix when it is done
<str1ngs>looks really intresting
<oriansj>it is alot of fun
<oriansj>got a link to via?
<str1ngs>I think though that. some of the bootstrap binaries could be removed it guix supported things like tar, gzip, xz naively?
<oriansj>str1ngs: that is why we are writing alternates in scheme to replace them and bash
<str1ngs>oriansj: here is an example plan/package declaration
<oriansj>so when we are done; guix will only depend upon guile (then later Mes.c)
<str1ngs>oriansj: in via I get around this by using go's stdlib for tar gzip etc. including native go git implementation
<oriansj>str1ngs: I just handwrote my own libc in 8 assembly instructions
<str1ngs>but via pre dates the idea of functional package management . so it's missing some of the fancy things guix supports
<str1ngs>I hope to play with mes eventually. :)
<oriansj>str1ngs: a simple git clone and git checkout gcc_build and make is all that is required
<str1ngs>with via, you don't even need git proper
<str1ngs>and on second thought, I might be able to provide a git client for guix without the need for libgit2. just a passing thought
<oriansj>str1ngs: guix-git
<str1ngs>guix-git uses libgit2 so there is a dependency there. in regrades to bootstrapping
<str1ngs>actually I thougt you meant guile-git. is guix-git something else?
<oriansj>str1ngs: well in regards to bootstrapping; we are stripping out binaries as quick as we can (in fact Guix has the smallest binary footprint by a huge margin)
<str1ngs>oriansj: you mean in source binaries?
<oriansj>str1ngs: correct
<str1ngs>I guess you mean in the context of bootstrapping
<oriansj>right now we are looking at 120MB uncompressed (compared to debian's 500+MB and Gentoo's 300+MB)
<oriansj>(debian's numbers and Gentoo's are compressed values)
<str1ngs>ahh yes. for via. all you need is the via binary. but it uses the preexisting packages to bootstrap
<oriansj>and when we swap out guile for mes-m2; it'll be down to 197KB uncompressed
<oriansj>and then we have the mescc-tools-seed; which reduces it down to 357bytes total
<str1ngs>technically to bootstrap via. you just need a running kernel, network and the via binary
<oriansj>str1ngs: we can run on bare metal
<oriansj>No bios, no firmware, no microcode
<str1ngs>though I generally boot strap in a rootless cgroup. using via shell
<str1ngs>are you familiar with guix's container code? I've been meaning on looking at it. in the context of guix build
<oriansj>str1ngs: I work at a lower level than that primarily
<oriansj>To ensure that guix gets a completely trusting trust attack resistant base
<str1ngs>I can see stage0 really helping with that
<oriansj>guix for all of its flaws is the most accepting distro in regards to supporting our bootstrapping work
<oriansj>plus with alots of scheme developers; there is a talent pool to help with the rewriting of core-utils into scheme to be run on guile (mes-m2)
<str1ngs>why not just use mes to build
<str1ngs>though scheme coretutils is still intresting
<oriansj>because scheme core-utils seems like more fun to do
<str1ngs>I think a scheme coretutils has more long term benefits. I agree
<leoprikler>+1 for Scheme coreutils
<oriansj>There is literally nothing stopping anyone else from taking what we have working; make the improvements required to build toybox directly and just use that but thus far no one seems interested in that work.
<oriansj>leoprikler: we are alway recruiting people who are willing to do the work ^_^
<str1ngs>oriansj: I might look at that for via. but really I was hoping to eventually replace via with guix
<oriansj>even 30minutes a week can make a real difference
<str1ngs>oriansj: via literally started as bash scripts based off of LFS. and morphed into a full blown binary package manager.
<oriansj>str1ngs: and it certainly appears to be a beautiful effort of love
<str1ngs>though I use it less and less due to guix these days :)
<oriansj>and I am certain there are probably a few tricks in there that guix could use to become even better
<str1ngs>some features what I'd like to get into guix eventually, IPFS support. rootless containers. build shells for easier debugging build isolation.
<oriansj>str1ngs: I think IPFS support is probably the one that should be done first
<oriansj>especially for the source tars
<str1ngs>yep, alternatively gnunet make work for this too
<str1ngs>gnunet has scheme bindings which is nice
<oriansj>str1ngs: the more the better I feel
<oriansj>I'd even go for raw torrent support if someone was willing to put in the work
<str1ngs>the only other thing I have in via that you really can't replicate is machine readable/writeable package declarations. but guix functional package management kinda supersedes that
<oriansj>str1ngs: guix uses s-expressions and those are easily machine readable/writeable
<oriansj>in fact s-expressions are easier to parse and manipulate than any other structured data format
<str1ngs>right in theory. but in practice writing s-expressions is not used. with via plans are formatted and sorted and have certain meta data automatically updated.
<str1ngs>example. dynamic C dependencies are automatically added/updated to the plan declaration.
<str1ngs>example is the only line manually added to this plan
<str1ngs>and some of the version url meta data
<oriansj>str1ngs: I generate s-expressions whenever I wish to update my guix manifest file. I even have a script in scheme for it
<str1ngs>oriansj: right, but the package declarations in guix are not machine formatted or updated. if you get my gist
<oriansj>str1ngs: that is why we have guix grafts:
<oriansj>and guix refresh
<str1ngs>will look at graphs more when I have time :)
<leoprikler>s-expressions are not machine-writable?
<leoprikler>I've been using write wrong all these years :(
<str1ngs>s-expressions do not serialize like json does.
<oriansj>str1ngs: (list 1 2 3 4 5 (cons 9 10)) ?
<str1ngs>try sorting then formatting, and then modifying that s-expression. it's not trivial
<oriansj>(sort (list ...))
<oriansj>(for-each format (list ...))
<str1ngs>I mean pragmatically, then writing such that the s-expression has the least amount of diffs
<oriansj>well if you wrote a program to generate s-expressions; that is a minor engineering detail
<str1ngs>take this diff for example .
<oriansj>yeah, that looks just like the guix package for youtube-dl diffs
<str1ngs>this diff clearly shows what has changed from the previous build. and the declarations are uniform though all declarations. the filed orders etc. again this can be done use s-expressions. but it's not trivial
<oriansj>in bash, that may be true
<oriansj>but in python or C or scheme, I have never had a problem with it
<leoprikler>Especially not in Scheme
<oriansj>s-expressions simply are ( $CONTENT )
<str1ngs>in guix scheme it manual. with json you can write it how you want. but it can be rewritten to be formatted identical to the original
<str1ngs>for example I can just do via fmt. and it will format every json plan declaration in one sweep.
<leoprikler>you can do that in Scheme as well, have even looked at the alist api?
<str1ngs>but you can't do that in guix. it's ad-hoc
<oriansj>str1ngs: you can do that in any s-expression if you wanted
<str1ngs>I can also serialize to toml or s-expressions even. just that the code is the same every time.
<oriansj>str1ngs: one can also s-expression -> json ->s-expression
<str1ngs>such that*
<leoprikler>you can even do s-expression to HTML ;)
<oriansj>or xml
<str1ngs>I'd like to see guix packages serialize to another format and still work :P
<leoprikler>don't we already have guix import json tho?
<oriansj>leoprikler: you are absolutely right
<leoprikler>(not that I'd want to write build descriptions in JSON, but if that's your fetish...)
<str1ngs>you could import json. but could open a s-expression as json modify it. and then save it as s-expression with only the changes in place?
<oriansj>str1ngs: deterministic code has that property
<str1ngs>leoprikler: I don't that implied insult
<str1ngs>I dont' appreciate
<leoprikler>I'm not shaming, I have my own fetishes.
<oriansj>leoprikler: off topic
<oriansj>let us not hit that topic space please
<oriansj>str1ngs: poor choice of wordings perhaps but back to the core topic
<oriansj>you should be able to do everything in json should you so desire
<str1ngs>oriansj: yes, guix deterministic side supersede it's lack of serialization features. I agree
<oriansj>and one could go from s-expression to json and back again to suit your preferred workflow
<oriansj>it is ultimately part of guix because someone wanted/needed it
<leoprikler>str1ngs: but do you really need the serialization as part of guix?
<str1ngs>right that is the idea, but I'm not sure if you can go back from scheme after an import
<leoprikler>you can `read' the files with guile and guile-json exists
<str1ngs>leoprikler: no, if you read the thread we were having an academic discussion on package manager features.
<bluekeys>Hi guix. I'm following info guix m contributing poorly I suspect. I've checkout out the src to ~/src. I set up the pure env and ran ./bootstrap w/o incident. I'm now at configuring and am about to set localstatedir=/var am I doing it right?
<leoprikler>bluekeys: yep
<leoprikler>str1ngs: guix literally has a guile shell as one of its features...
<str1ngs>leoprikler: it also does not support IPFS, android, windows. it's not above critique :P
<str1ngs>or MacOS either. in fact using serialization I've ported via to power9, android, windows etc
<str1ngs>so serialization has some very practical application.
<leoprikler>I don't think Windows is ever going to be a viable free software platform.
<oriansj>str1ngs: well guix's portability is largely related to the amount of effort developers are willing to put into porting it
<oriansj>and thus far most guix developers tend to be in the FSF camp
<bluekeys>guix feels like the free-est of the free os's
<oriansj>but I doubt we would reject efforts to port it to more systems if they were done
<str1ngs>oriansj: agreed, but serialization has made for less work. I'm the the only developer of via. and serialization has made porting easier. I'm using this to show how useful the feature is
<oriansj>str1ngs: well that is the issue around here; argument and discussion always is trumped by running code.
<oriansj>The best way to change who guix works is to submit a patch
<oriansj>thank you leoprikler
<str1ngs>oriansj: of course, but we were doing a comparison of features. personally guix far exceeds via features list :P
<oriansj>str1ngs: a million features matters not if it doesn't include the one you need.
<leoprikler>I doubt serialization would help much in our porting efforts.
<str1ngs>the primary draw back is portable containers
<oriansj>well we have portable archives
<str1ngs>I'm assuming guix is using cgroups for build isolation, which is not a thing on MacOS IIRC
<str1ngs>I think maybe a better approach is to cross build on linux then have guix substitute install
<str1ngs>that would probably work for MacOS atleast
<oriansj>well there is the ability to make the build containerization host specific
<oriansj>if someone was willing to put in the time, we could enable that sort of build work to be done on those hosts
<str1ngs>intresting I bootstrapped power9 on a machine I did'nt have root access on. that was fun
<str1ngs>I could'nt use guix in that context due to nested containers. which was sad
<oriansj>well, guix developers don't generally solve issues they themselves don't have
<oriansj>and there isn't anything particular about guix that couldn't have been adjusted to improve that situation.
<str1ngs>that's understandable.
<str1ngs>I've been meaning to look at the container code. I think it's possible to make guix build be completely rootless
<oriansj>I look forward to your improvements ^_^
<str1ngs>here the rootless syscalls I'm using
<str1ngs>one thing that might need is that guix needs build users. which is need root access to create.
<str1ngs>though you can map uid's with cgroups so maybe that can we worked around
<oriansj>well one could write a guix user mode which assumes the sysadmin hates guix and routes around that damage by burning disk space
<str1ngs>hehe, there are security benefits to this aswell. but you are right this is more useful for systems you might not have root access too. or the systadmin won't install guix
<vixus>I want to add some additional packages to the installation disk OS. When I inherit from an operating-system definition, can I append to the existing packages directive, instead of overriding it completely?
<str1ngs>vixus: the packages field in operating-system can do this. usually you cons* them to %base-packages
<str1ngs>vixus: did you use a template to start with?
<vixus>I'm doing (inherit installation-os)
<vixus>Which already cons* a bunch of packages to %base-packages
<leoprikler>you should be able to access the fields of that os
<str1ngs>vixus: you can in that case just add the packages before the cons* tail list
<leoprikler>do (cons* <packages> (operating-system-packages installation-os))
<str1ngs>vixus: you might need to add the modules to use-package-modules if the config is using that.
<str1ngs>or use the guile moduels
<str1ngs>err modules*
<vixus>str1ngs: yeah this is a package in gnu/packages/base
<str1ngs>vixus: it will error if the module is not used yet
<vixus>Hmm, `guix package -A make` says it's defined in gnu/packages/base.scm but (use-modules (gnu packages base)) doesn't seem to export it
<vixus>oh it's called gnu-make :p
<str1ngs>vixus: which package is it?
<str1ngs>nvm you just answered :P
<gnutec>Hello! I finally install glibc-locales and the message about locale is over. But still there if I "sudo guix". The "sudo guix system reconfigure /etc/config.scm" will work?
<vixus>leoprikler: works a treat, thanks
<vixus>str1ngs: thanks for the package module heads up too
<str1ngs>gnutec: you need to install glibc-locales for the root profile as well
<gnutec>strlngs: I did! "sudo guix install glibc-locales" But the message still there.
<vixus>gnutec: sudo -E guix?
<str1ngs>gnutec: are you using foreign distro?
<gnutec>str1ngs: No! Guix System Install
<str1ngs>oriansj: I put mes on my TODO list. will be fun to play with I think
<gnutec>vixus: What is -E?
<leoprikler>-E, --preserve-env preserve user environment when running command
<gnutec>Well! Know the "sudo guix system reconf..." is building something. Lets see.
<gnutec>Guix need to change this info. They said that glibc-locales is only necessary for foreign distro. But I have to do this with guix system install. :/
<ArneBab>oriansj: that catches me on the hop quite badly — I use Guix for home office and need some chromium variant for testing. My locally installed firefox also broke with the updates from yesterday, along with intellij (I’m not sure what’s broken; I get segfaults, but then I had to use LD_LIBRARY_PATH hacks to get them to work). For Firefox icecat 68 should be a suitable replacement if the update works today.
<gnutec>No! I still have a erro with ...nss... something.
<oriansj>ArneBab: well I certainly hope we can find a reasonable long term solution to that (Mostly we just need to find someone willing to keep up with Google's bad behavior in Chromium so that we don't have to drop it)
<ArneBab>I hope so, too
<sfrantani>Hello Guixers! I'm having some trouble running guix system vm.
<sfrantani>Every time I invoke the command via this script and this system configuration , qemu complains that there are no bootable hard-drives.
<sfrantani>Am I supposed to installa Guix inside a qemu volume before running guix system vm?
<sfrantani>Also I should add that /tmp/qemu-img is pree
<sfrantani>*present and read-writable.
<efraim>If I convert all the rust crates to the new type I don't think I can deprecate them since they're all hidden packages
<sirgazil>Hi, do you know which package provides the git send-email command?
<jlicht>hey guix
<leoprikler>sirgazil: git:send-email
<sirgazil>Oh, thanks leoprikler :)
<sirgazil>leoprikler: How did you know that?
<leoprikler>I've tried using it, but then didn't bother with the mail server config
<leoprikler>(Alternatively `guix show git`)
<sirgazil>Ah, ok. But did you use some search feature in guix to find it?
<leoprikler>you can do guix package -s, but I'm not sure whether it handles outputs
<jlicht>sirgazil: If I do `guix search send-email`, git shows up
<leoprikler>that said, I knew that git send-email is part of git itself, so it made sense for me to try guix show
<sirgazil>jlicht: Yeah, thanks. I thought installing git would get me send-email. I'm not familiar with what outputs mean nor the : notation. I'll have to read.
<atw>slightly OT question, but packaging related: where does bundle install put dependencies? I'm roughly looking for the equivalent of ~/.m2, if that makes sense.
<leoprikler>atw what exactly do you mean by bundle install?
<atw>I mean running this bundler subcommand:
<leoprikler>try $HOME/.bundle
<nckx>Hullo #guix.
<atw>leoprikler: thanks! Sorry, I'm XYing a bit here, let me back up: what I really want to do is run the haml-to-html in I'm also trying to follow
<atw>is the bundler package a little broken or am I doing it wrong?
<thomassgn>ison[m]: Hi, didn't see your message til now. I figured out I needed to stop display-manager. Then I can run sway from a tty cli. I can't start sway sessions from SDDM though, I mean it shows up, but after typing my password and pressing enter the login dialog disappears but the background window doesn't change and none of my inputs gives me any input (i.e. pressing my shortcut for terminal doesn't yield a
<thomassgn>terminal.), but I can jump to a tty with C-M-<f2> so it's not frozen.
<leoprikler>atw: does the same command work if you have bundle installed as user?
<atw>I'll give it a shot ...
<atw>same result as in my paste :/
<efraim>atw: what if you try a different version of ruby
<efraim>oh, I thought bundler came from ruby, not that it was a separate program
<leoprikler>atw: after reading the blog post, the conclusion for me is "don't use bundler, use (guix build-system ruby)"
<leoprikler>as far as your build problem is concerned, have you tried `guix import gem`?
<atw>I don't think the repo I'm interested in is published as a gem, but I can try writing a guix.scm for myself
<nckx>apteryx_: I don't have any other Blue-toothed devices.
<atw>ah right, I did try this a bit, but depends on bundler, which I'm guessing is an oddity. so I have to write a guix.scm and I guess rewrite the Rakefile
<gnutec>I did! Is because sudo need -E option. Know I upgrade everything, kerner 5.3... Look.
<gnutec>No need download again! I install Blender as well. Just need 0ad and SuperTuxCart.
<nckx>gnutec: Which error message does Supertuxkart give you?
<nckx>It segfaults here but that might be driver-related.
<gnutec>nckx: none. I just start now. It's OK. :)
<nckx>Oh. Cool.
*nckx slightly jealous but happy.
<nckx>Anybody here own an X220/X230/Ivybridge machine?
<gnutec>To much app I was instaled. Blender, gimp, audacity, inkscape, ungoogle-chromium, warzone2100, minetest, ...
<nckx>guix: error: too much app.
<gnutec>I doing know 0ad and supertuxkart.
<nckx>gnutec: Those are a lot of big packages 🙂
<gnutec>nckx: Yeh! I charge my 4G today to solve that problem. 6GB of internet.
<str1ngs>nckx: I have a x220
<nckx>str1ngs: Would you mind testing supertuxkart? It segfaults here before drawing anything, but I'd like to rule out my custom kernel before opening a bug.
<nckx>(on Guix System.)
<str1ngs>nckx: I don't quite use guix it on it. and in the past I've used a tainted kernel due to wifi
<nckx>Oh, okidoke.
<nckx>Thanks for responding 🙂
<str1ngs>but I can try it out, get back to you
<nckx>str1ngs: Thanks!
<gnutec>nckx: You need a good computer to run supertuxkart in all high graphics. I did in very low whith GNU/Linux Trisquel.
<leoprikler>running `guix build supertuxkart` and `/gnu/store/.../bin/supertuxkart` works fine on my machine ;)
<nckx>gnutec: I've played it on this machine before, about half a year ago, or more.
<nckx>I've even played Wolfenstein: New Order on this machine. It's a fun little box…
<gnutec>Guix System?
<gnutec>nckx: Still installing...
<ArneBab>I get build failures for fetchmail.
<nckx>ArneBab: undefined reference to `SSLv3_client_method'?
<ArneBab>is that known?
<nckx>No, it's just what I got just now.
<ArneBab>I’ll report a bug
<nckx>Looks like an openssl version mismatch
<nckx>There's a new version of fetchmail, I'll try building it.
<nckx>ArneBab: It builds but the test suite complains…
<ArneBab>is it already in guix?
<nckx>Well, no, it fails 😛
<ArneBab>arg, yes, because test failure means do not ship :-)
<ArneBab>Here’s a bug for referencable notes:
<nckx>…or disabling the failing test, but only after trying to fix it 😉
<nckx>You know you're #winning at debugging when you're inserting printf()s with substitute*…
<leoprikler>teach me, senpai
<nckx>Well, that was actually easy. ArneBab: could you test the new fetchmail version & close the bug if it didn't break anything else?
<ArneBab>sure — thank you!
*nckx goes back to watching trash TV.
<ArneBab>pulling now, that will take a while