<tune>I'm doing a guix system reconfigure and it seems to keep getting stuck downloading glibc-locales. the percentage is frozen in the upper 90s and neither the ETA nor download speed values are changing anymore either <tune>I canceled it and started it again once already and it seems to be struggling with the same part <mwette>I'm on attempt number X of building guix from source for Fedora. Each time I run into brick wall after 5-ish hours and give up. Just got through installing gnutls. yay. <g_bor[m]>the chromium error was a bit more verbose, now I know what is happening. Istm the site uses a proprietary codec. <mwette>now can't get guile-git because gitlab.com is asking for a username/password How to get around that? <mwette>have guile-git from old download <nckx>mwette: You can't, because Guix doesn't [need to] support authentication. ***work is now known as M4R10zM0113R
<nckx>I wonder why gitlab.com is shadowblocking you. <mwette>It's weird. I was able to "git pull" on my old clone. <nckx>Unfortunately, I don't know how to manually add git checkouts to the store. Tarballs are easy (guix download), but that command doesn't seem to offer git URL support. ☹ <nckx>Not that Guix doesn't have its fair share of bugs, but you seem to be particularly unlucky in hitting walls. This shouldn't happen™. <mwette>I'm not in the store yet. I'm just trying to build guix itself without having guix. <nckx>I've only ever built Guix from source on a Guix System… 🤷 <tune>my update worked on the third time <mwette>and using git://gitlab.com/.. just hangs <nckx>tune: Interested in adding (reproducible!) download resumption support to Guix? ;-) <nckx>Where did you find this gitlab.com URL? Maybe something forgot to be updated. <nckx>Code complains when it breaks; documentation doesn't. <nckx>(It doesn't exist, says my git.) <mwette>sorry- the sqlite3 one is not from gitlab -- not sure where I got that <nckx>Is it possible that you misread an URL? <nckx>It seems like everything in the README still works. <mwette>I have guile-sqlite3. Now autoreconf -vif is returning "configure.ac:15: error: possibly undefined macro: GUILE_PKG". I'm guessing configure.ac needs to include guile.m4 <nckx>All this guile-foo stuff can get confusing. <nckx>I am the maintainer of none of those things and autotools frankly give me the willies. <vagrantc>i've just recently gotten guix and all it's build-dependencies built for Debian ... and started getting some of them uploaded <mwette>I was confusing guile-git and guile-sqlite3. But I am writing stuff down. One day I will have shell script to build on fedora. <str1ngs>mwette: guile.m4 is part of guile development package. whatever that is called for fedora <mwette>strings: should configure.ac include those explicitly or does that happen some other way? /opt/local/share/aclocal includes guile.m4 and /usr/share/aclocal includes pkg.m4. <str1ngs>it should install it. if not you can just put in the m4 directory <tune>nckx: not really a programmer yet, sorry. <str1ngs>I think Guix uses AC_CONFIG_MACRO_DIRS([m4]) *nckx wonders how you know when you are. <tune>I suppose I don't know that either, but I can at least say I still haven't even managed to package anything <str1ngs>mwette: yes you can just put it in guix m4 source directory. I'm guessing autoreconf is not looking in /opt . dunno <mwette>str1ngs: "autoreconf -vif -I/opt/local/share/aclocal" did the trick <str1ngs>also just a nit pick I would use /usr/local or /usr/local/guix <mwette>so builtin guile is /usr/bin/guile (2.0); I installed guile-2.2 under /opt/local <mwette>yeah -- /opt/guix is another option. I may convert to that next try. <str1ngs>if you are doing a guix stack in /opt might as well isolate it <str1ngs>also if you like this sort of thing. I have a package manger that does a full toochain stack. including guix <mwette>str1ngs: well I have /opt in partition separate from /. So if I upgrade my OS I still have all that stuff -- assuming it links OK w/ OS upgrade. I like to nuke the / partition if I upgrade. <str1ngs>yeah, fedoras builtin guile is problematic at times. I think they should upgrade it to 2.4 <str1ngs>at least when I had to do some work on fedora around 28 it was causing issues. <mwette>gnutls guile-git guile-sqlite3 guile-json now installed :) <nckx>rekado: You still awake? <str1ngs>might be overkill if you just need a guix stack <nckx>tune: Fair point. I look forward to your first package. <nckx>We need more packages. We only have 9839. <str1ngs>it would be nice to get guix dependencies packages for the major distros <nckx>vagrantc and (I think?) jonsger[m] are already doing exactly that for Debian and openSuse. *vagrantc wonders if opensuse is similar enough to fedora to share some packaging <str1ngs>I think they are, but say debian accepts your packages. and then there were fedora packages. that would be a great start <str1ngs>how is that going vagrantc ? I'm hoping that goes through <vagrantc>str1ngs: i've got everything technically working, but we need a different way to get the bootstrap binaries <vagrantc>i think i posted a summary to guix-devel recently... *nckx last used openSuse 6.1 in a real box from a real library; not quite up to speed on later versions. <vagrantc>what's probably the biggest blocker is the gnutls maintainer's reluctance to re-enable the guile bindings due to what i suspect may be historical build problems <str1ngs>even if the dependency got included time being. at least people can build guix from the tarball release then *nckx smells another guile-foo spin-off. <vagrantc>guix requiring an old version of guile-json is a little awkward <vagrantc>debian (and many distros) don't really handle multiple concurrent versions well <mwette>I installed guile-json-3.1.0. Is that a bad decision? <nckx>vagrantc: Feel free to ignore because it's mere curiosity and I'm not going to fix anything: why's that? <mwette>got through guix configure ; guix build started ... <vagrantc>mwette: i was told guix is incompatible with guile-json 3.x and needs the older bindings <OriansJ>vagrantc: well I am working on how to radically change how we get our bootstrap binaries <vagrantc>OriansJ: yes, i'm very much interested in that work, too :) <vagrantc>i've also been working on packaging MES and company for Debian ... <OriansJ>the problem is the big gap between M2-Planet and Mes.C isn't much fun to hack on <str1ngs>I'm confused about bootstrap binaries. does Guix actually need this to build guix from source? <str1ngs>I would think the boostrap binaries are for bootstrapping the toolchains <vagrantc>str1ngs: strictly speaking, no, practically speaking, if you want to use the same substitute servers, yes. <OriansJ>str1ngs: well one requires binaries to build binaries from source; unless you feel like hand toggling them into memory yourself <str1ngs>so is debian blocking guix inclusion because it downloads binaries? <vagrantc>str1ngs: because the binaries are shipped *as* source <vagrantc>the bootstrap binaries are included in the git and tarball releases of guix <OriansJ>However with some work MesCC running on the native guile should be able to self-host and bootstrap from there <str1ngs>okay, but those should not be needed to build Guix I would think. <OriansJ>str1ngs: Guix isn't built as it is a guile program running on guile <str1ngs>right but it uses autotools and guild <str1ngs>I'm just trying to figure out these bootstrap binaires come into play. I would think only when building toolchains <vagrantc>str1ngs: you need bit-for-bit identical bootstrap binaries in order to get the same hashes that go into /gnu/store/* which has a cascading effect throughout all of the possible substitutes for the core toolchains <str1ngs>okay this makes sense. so you can build guix from source. but you still need some bootstrap binaries from there? <vagrantc>i tried symlinking the host binaries, but then only the symlinks ended up in the store and everything failed to build <vagrantc>guix worked fine, just guix-daemon couldn't usefully build anything <str1ngs>hmm make install DESTDIR=$PWD/test does not show any binaries as far as I can tell. <str1ngs>ahh these are just probably static helper binaries <vagrantc>they're very much needed, in my experience, to get guix up and running. <OriansJ>str1ngs: basically it is something we are trying to eliminate entirely but in the end we know we will be stuck with atleast 180bytes of binaries <OriansJ>So we just slowly hammer away at them and remove them one by one <str1ngs>vagrantc, OriansJ this makes more sense. thank for the explination <vagrantc>it's a little confusing in that it has nothing to do with ./bootstrap :) <nckx>OriansJ: 180? That's half of what I last heard (300-something). Nice. <str1ngs>well tar and xz could probably be replaced with ffi or guile-xz <OriansJ>although once mescc-tools gets ports to more distros we can eliminate and generate that binary *str1ngs looks at nckx o.O <OriansJ>nckx: that is the lower bound of an ELF binary assuming perfect code golf <OriansJ>nckx: the current x86 hex0 binary is 357bytes <OriansJ>But it is designed to be easy to read, follow and understand and many possible efficiencies were intensionally skipped for clarity over brevity <OriansJ>str1ngs: mescc-tools can generate the hex0 bootstrap binary <str1ngs>okay, but for these helper binaries is that useful then. I wouldn't think so <OriansJ>str1ngs: we can eliminate the helper binaries by providing a way to generate them entirely from source with identical outputs *vagrantc really wonders about bootstrapping newer architectures like riscv64 that only have support in very recent toolchains <OriansJ>vagrantc: well backporting support for those architectures is one solution but more likely we might end up having to extend MesCC until it can compile GCC 4.7 directly <vagrantc>it is pretty much the fundamental thing that got me excited about guix ... the prospects of an auditable bootstrap. <OriansJ>str1ngs: if you are interested in the bootstrap work being done feel free to hop on #bootstrappable which is where most of the discussion takes place <mwette>guix built w/o errors (Fedora 29) <jackhill>My grub seems to not be automatically loading the luks module anymore. That means it doesn't prompt me for a password in order to unlock the root partition where the kernel is in the store. <jackhill>at the grub command line, running cryptomount -a doesn't prompt me either (the last time I had cryto booting problems, it did) until I run it after running insmod luks. <jackhill>Has anyone seen this/know what could cause it? <M4R10zM0113R>yeah, as in x86_64 and x86, 32/64-bit in the most prevalent architectures <jackhill>Guix actually makes this pretty easy since each store item can depend directly on its own set up libraries insteading of having to deal with installing them all at the same time in one big global name space *kmicu 😉👉👉 47b9614b31 services: Add 'nix-service-type'. <kdtsh>Hi all! I had a question which is likely a matter of simple configuration that I'm just not getting ... I find that my tty1 is constantly being littered with system logging, and I can't find any reason why this would happen. I've looked at the syslog config and I can't see any obvious reason why it would log to tty1. The logging is usually dbus-dae <kdtsh>mon and ModemManager. Does anyone know why this would be happening? <OriansJ>kmicu: do you not realize how early it is over here? <OriansJ>It is barely 5am and I've got work this morning; we need to start talking about boundaries here.... <OriansJ>and being monday it is either going to be an 8 hour day of full cyber warfare or a 14 hour day fighting with another F@cking project manager who wants to shave 20 minutes off their project schedule by turning off basic security features like validation of logins... <emyles>OriansJ: I get that too with 16GB RAM <roptat>OriansJ, that's not related to your RAM, it's an issue with the manual translation <roptat>there's something really wrong with the german translation it seems <pkill9>how do i make a service properly that takes a configuration? <mbakke>pkill9: Look into gnu/services/ for inspiration, and gnu/tests/ to create a "system test" for quick iteration. <rekado_>OriansJ, roptat I can reproduce this here. <rekado_>I wonder if it’s because of 78b0f9419fdac88d7b84314868bab1b1e8173602 or 0e6cee21a48294b81a5e57e00602728fe7f7075f <dutchie>+1 repro for guix pull failing with german manual weirdness <rekado_>“GNU-Lizenz f�r freie Dokumentation” looks suspicious <rekado_>commit 15ec93a7832ae7dde747ccd9bb2bb2776be9f199 is still fine. <rekado_>my guess is that something’s wrong with the locales while building the German manual. <roptat>rekado_, not only that, but there are errors while building the manual on the git checkout too <civodul>mbakke: /gnu/store/rm73rg2gywvdx5d7g5k6aaf4wrjf0cmx-guix-manual.drv fails to build, which in turn prevents evaluation <pkill9>is there a guide on writing a service definition? <civodul>roptat, rekado_, mbakke: maybe we should revert the guix-manual.de.po update? <civodul>though i didn't have problems locally <pkill9>i think i made a service definition that i can configure \o/ <rekado_>civodul: I also don’t see a problem locally in a git checkout. <rekado_>but I see it when doing “guix pull --url=file://$PWD” <rekado_>I’m checking if reverting 0e6cee21a48294b81a5e57e00602728fe7f7075f helps <roptat>the manual is completely broken from line 25398 of guix.de.texi <rekado_>I’ve reverted the commit that updates the manual translation. <civodul>so what's wrong exactly with that PO file? <roptat>well, that's weird because the french manual is also completely broken, and I assume it's also the case for the rest of the manuals <roptat>(when removing the texi files and rebuilding them from ./bootstrap) <civodul>oh, nix-service-type and this doc were pushed a day ago i think <roptat>yes, the result of po4a (ignoring our own script after that) is also completely broken after this line <roptat>so either texinfo markup issue or po4a's parser's fault <roptat>without the line break at the end of that line, it seems to work better <roptat>but the line is over 80 characters after the change ***MinceR_ is now known as MinceR
<roptat>civodul, this is the po4a command if you want to fix the issue: po4a-translate -M UTF-8 -L UTF-8 -k 0 -f texinfo -m "doc/guix.texi" -p "po/doc/guix-manual.fr.po" -l "doc/guix.fr.texi.tmp <roptat>make sure the end of the tmp file looks good :) ***paroneayea is now known as dustyweb
*kmicu knew it from the beginning that that Nix service is a trojan horse from Nix folks. Please don’t forget to subscribe to my conspiracy theory. Cheers! <weld>hi, is guix pull failing for others as well? it fails to build guix-manual.drv here <arbi>I'm attempting to install from a "foreign" distro. When I run `guix system init /mnt/etc/config.scm /mnt` I see "initilizing operating system under '/mnt'..." and "bootloader successfully installed on '/boot/efi'". However, when I check `/mnt/boot` there is no EFI folder. Additionally, when I reboot, I'm able to find the Guix bootloader, however when attempting to boot the Linux kernel the directory in the /gnu/store matches the foreign <arbi>I currently have 2 EFI partitions: `/dev/nvme0n1p3` and `/dev/nvme0n1p4`. The "foreign" distro's bootloader is installed on "p3". I'm attempting to mount "p4" to /mnt/boot <arbi>Is this my problem? Do I need "p4" at all? Should I be mounting "p3" to /mnt/boot before running `guix system init`? <str1ngs>arbi: you can mount your EFI partition to /mnt/boot/efi <arbi>the result would be a directory: `/mnt/boot/efi/EFI`? <arbi>ok thank you, giving this a try <str1ngs>though config.scm should reflect ths aswell. I'm assumed you have done that already? <arbi>I've been mounting `/mnt/boot` instead of `/mnt/boot/efi` <arbi>but my target is `/mnt/boot/efi` in the config <arbi>When I set the target to `/mnt/boot` in my config.scm my bootloader doesn't pick it up <str1ngs>I just bind mount if you are using the same hosted EFI. example. mount -o bind /boot/efi /mnt/boot/efi <str1ngs>you may need to make /mnt/boot/efi by had <arbi>I think that's preferable for me -- I currently have an EFI partition mounted at /boot for my "foreign" distro <arbi>in that case, should I have my config.scm target to `/boot` and bind mount it? <arbi>`mount -o bind /boot /mnt/boot` or `mount -o bind /boot/efi /mnt/boot/efi` leaving the config as is <str1ngs>I would use /boot/efi personally . your call though <mfg>Hi, i'm trying to build a package which is built running `make'. I thought the most appropriate build system is (guix build-system trivial); is there a better suited build-system? <roptat>mfg, the trivial build system is also the most complex one <roptat>you should probably use the gnu-build-system instead <roptat>it implements the standard ./configure && make && make install <roptat>if there is no configure script, you can use an argument to override the list of phases that need to be run <mfg>ah okay, i will try that <roptat>mfg, if you need an example, hashcat is a good one I think (run guix edit hashcat to view the package definition) <mfg>is there a way to automatically initialize git submodules when the repo is cloned? <mbakke>rekado, roptat: guix pull is still failing. <bavier>'guix pull' fails for me currently, in the 'guix-manual' derivation, references to nonexistent nodes in the guix.de.texi file <mfg>mbakke: How/Where do i need to add this command? ***ng0_ is now known as ng0
<weld>bavier, fails in the same way for me, mbakke above also said it's failing. I tried the second last commit but that fails too. <mbakke>mfg: Right, I suppose you mean inside a package definition? You can use '(git-reference (url ...) (commit ...) (recursive? #t))'. <mbakke>I thought I was in #git for a moment... <mfg>mbakke: yes i did, thank you :D ***dxld_ is now known as dxld
<str1ngs>janneke: thanks janneke I will take a look at guile-gi soon <mfg>and another thing: how do i replace the which command with the right program path? <samplet>Has anyone been able to build core-updates lately? The German manual fails, and if I disable building it, I get a pretty cryptic error from “gnu/ci.scm” which seems to be due to something in “package->job”. <janneke>mfg: if `which' is a build dependency, you can just add the which package; alternatives are `command -v' (POSIX) or `type -p' (most modern shells), or solve it programmatically in the build system (look for examples in other packages) <roptat>mbakke, bavier it should be fixed now <civodul>rekado_: is it ok if i reconfigure berlin? <roptat>civodul, I think it's a bug in po4a <roptat>but that really fixed the issue :) <roptat>can you revert the revert to put the german translation back? <civodul>roptat: i can't revert the revert right now tho :-) <civodul>i'm on a separate branch and having dinner soonish <mfg>aec9bb8793ca75a5bbc17, does not work for me. <roptat>danielp3344, it does, but it's not easy to install <roptat>danielp3344, it's called guix system now, not guixsd anymore ;) <cap>Greetings, I noticed that the DNS resolver doesn't work for me in the current guix vm image. Could someone try to reproduce? <roptat>but what I did with mine was to install another distribution first, then install guix on that foreign system, and finally run guix system init /etc/config.scm / <roptat>if that works, your first boot after that will fail, and you'll be dropped in the guix repl from which you can move /etc away and reboot <roptat>cap, can you describe what happened? what's the network service you're running and what's your dns config? <user_oreloznog>Hi Guix! I have installed Guix on a foreign distro (Debian) and it seems to work, but when I want to launch again, say quessel, the program seems to be not installed... <user_oreloznog>Same for hello. Both initially settled and worked. Do not know what to do from here... <roptat>user_oreloznog, do you have ~/.guix-profile/bin in your PATH? <Formbi>just put «export PATH=$PATH:$HOME/.guix-profile/bin» in your ~/.bashrc <user_oreloznog>To export it it the ~/.bashrc, i can just lauch «export PATH=$PATH:$HOME/.guix-profile/bin» without arguments? <dutchie>no, that'll just set it for your current shell session <dutchie>you'll have to do something like `nano ~/.bashrc` and add it to the bottom that way <dutchie>(or vi, or emacs, or whatever editor you like the most) <roptat>user_oreloznog, .bashrc is just a file, you edit it like usual :) <dutchie>you will need to either open a new shell or do `. ~/.bashrc` to get it to pick up the changes <dutchie>or possibly log out and in again if you want gui programs to notice <roptat>dutchie, will gui programs notice anything in .bashrc though? <dutchie>(note: sometimes graphical environments are a bit strange about reading stuff like .bashrc) <dutchie>some login managers are hardcoded to read .bashrc <dutchie>some exec bash along the way and will pick it up that way <cap>roptat: Stock guix vm. The NetworkManager is disabled by default but it isn't clear to me how it is than handled. <roptat>cap, so there's no network configured? <samplet>It looks like it was my local changes that broke core-updates. It’s probably fine. :p <cap>roptat: link is up but no ip lease given besides the link-local ipv6. dhclient runs into a timeout. <cap>my virt bridge is on <roptat>cap so it's not a dns issue, it's network issue <roptat>how did you configure network with these? <roptat>I mean, from the point of view of the virtualizer, not inside the VM <cap>I'm using debian with virt-manager. "I just switched it on"… <cap>the default virtual network device <roptat>sorry, I don't know how virt-manager gives network to its guests <cap>could someone try to reproduce it for himself/herself? ***emyles` is now known as emyles
<rekado_>civodul: yes, it’s fine to reconfigure berlin. <rekado_>I only need to remember to copy kernel and initrd afterward. <tune>when I do a guix system reconfigure, sddm is started. when I reboot, gdm is what's launched. why? <tune>actually I kind of get it. I think gdm comes from %desktop-services and then I have sddm-service also. how can I disable gdm? <rekado_>by deleting it from %desktop-services <vagrantc>yeah, i've been using sway on one machine <vagrantc>cap: i'm using sddm to login with sway, though, not calling sway directly <cap>look for the example config for slim-service-type <cap>vagrantc: could you please share your config with me? <vagrantc>cap: don't have immediate access to that computer <tune>I'm using sway right now <tune>cap: I think I've been to this page before and I'm not seeing anything helpful so far <tune>cap: so launching "sway" from a tty doesn't work for you? <tune>is there a quick way to downgrade one package or do I have to do profile rollbacks <tune>also how do I check the version of something and if I have others <cap>tune: no, it doesn't. I think that some dependencys are missing <tune>for me just adding "sway" to system packages was enough, but it looks like you're not using the normal %desktop-services <tune>so maybe I have something that was needed <cap>I will try tomorrow to hunt down the dependency problems <tune>guix says slurp is on version 1.0.1 but their github has releases for up to 1.2.0 <tune>so I think we're two releases behind <tune>there's a way to check if something can be updated, right? <tune>since this just takes from git <nckx>tune: guix refresh -t github slurp <nckx>Actually, just guix refresh slurp will do. <tune>I see /gnu/store/hvhcfn985gbpr5rmjp2g4gsr5qpp4szw-guix-module-union/share/guile/site/2.2/gnu/packages/image.scm:1629:12: slurp would be upgraded from 1.0.1 to 1.2.0 <tune>but how do I make it do something <tune>gnu/packages/image.scm:1627:2: error: cannot download for this method: #<procedure git-fetch (ref hash-algo hash #:optional name #:key system guile git)> <nckx>But it's not magic; it will only update the version and hash. Making sure it still builds is up to you. <nckx>Maybe ya need guile-git in your profile, can't really say. <nckx>Also, it probably won't work on a read-only ‘guix pull’ repository ☺ <nckx>tune: That you'll probably need to run it in a writable git checkout with ./pre-inst-env. Unfortunately, the above is what I get when I try that. <tune>I started running into issues with slurp after a reboot. I was thinking maybe changes to sway needed a newer slurp now <tune>because I think my slurp version didn't change *nckx tries to update slurp manually. *nckx never actually uses guix refresh -u TBH. <tune>nckx: doing a guix pull now <ItsMarlin>I'll try making a custom keyboard layout later