<emsyr>nckx you were right! The problem had to do with the xorg-configuration part. I removed that and it worked! Now I'm using sddm. Thanx a lot!!! <nckx>emsyr: Glad it worked out đ <nckx>Marlin[m]: I don't think we have any. <emsyr>nckx also used the OR for the removal of the services. <xavierm02>hexchat doesn't seem to see the noto fonts so I can't see nckx's smiles :( <nckx>xavierm02: What does âfc-list | grep Emojâ return? <nckx>Pft, everything is a mode to you people. <xavierm02>maybe I should install noto from the config.scm? <nckx>xavierm02: No, don't do that. <nckx>Pastebin what âfc-cache -rvâ says. <nckx>xavierm02: Nothing will see it, because fontconfig doesn't âč <nckx>Bingo: /var/cache/fontconfig: not cleaning unwritable cache directory <nckx>sudo rm -r /var/cache/fontconfig <nckx>People will do anything for sweet mojies. <nckx>xavierm02: Does the fc-list command above return something now? Doesn't matter what. Should be 2 lines. <nckx>xavierm02: If so, restart Hexchat & enjoy. <nckx>All fixed. I'm glad this is no longer a bug that only happens to me. <nckx>What in blazes is running fc-cache as root⊠<xavierm02>I'm not sure what the fish meant but I see it all :-) <nckx>xavierm02: That makes two of us. That was weird. I'm glad they're gone. <alexanderbarbosa>maybe java-commons-compiler...but it seems that collections has it too... <nckx>alexanderbarbosa: openjdk:jdk. <Marlin[m]>also, x2go seems awesome. I'm gonna start using remote access a bit, and X forwardinf is good but slow <Marlin[m]>maybe i'll try packaging x2go, it seems like the best one <nckx>x2go used to be *fantastic*. Haven't used it in years. Shame it's not possible on Wayland. <nckx>Marlin[m]: It would be nice, I'm sure. <minall>What can you say to me about the .m4 fileformat, for what it is used?m I'm searching information about it, and it seems to be a 'File TypeMacro Processor Library', though, I can't find the reason of usage. <kori>minall: its a GNU m4 macro file <minall> But why it is used is my question too!, I'm checking the source code of a driver, and it includes several .m4 files, <kori>minall: check to see if anything needs to be replaced automatically in the m4 files <minall>Welp, it says that it can list the operating system features that the packages from a template file that lists the operating system features that the package from a template ... <str1ngs>minall: it's hard to say what it's used for. because m4 is a macro processor. though generally it's used to generate text or core. think of it like a template engine <Marlin[m]>Indeed, seems like X forwarding and SSH is all we have for remote access <Marlin[m]>(i mean, the server side is lacking, we have plenty of clients) <buhman>for dotfile management, I have seen that gnu stow is popular for this. could it be practical to use guix packages to manage home directory configurations? <buhman>wow, that is quite interesting! the documentation calls itself an "extension", but as a novice guix user, the implementation looks like some convenience functions over existing packaging primitives. <buhman>.. which is actually exactly what I had imagined. <niten>hey all...i'm trying to define a new service, but i'm getting this error: "guix system: error: no target of type 'macvlan-bridge' for service 'macvlan-bridge-service'" <niten>what is the 'target' it's talking about? <jfred>managing home dirs with guix does sound interesting, though I'm skeptical it'll scale well with a read-only home dir... I really want it to though :P <jfred>I do use stow for some of my dotfiles (my emacs config in particular) <quiliro>I have news that a Guix contributor is in my country Danny O'Brien <quiliro>If any of you contact him, please tell him to ask for me with the people he meets, most people (on free software) know me <str1ngs>niten: I suspect it want a service type not a service? <rekado_>weâve just placed an order for 30 new build farm servers. Yay! <xavierm02>jfred: It could scale if enough people used it, but if you need to punch holes for every program you use, it'll be pretty hard. I've thogh a bit about it and I think that guix packages should know which files / folders they use in the user's home. <jonsger>rekado_: so when will they be ready? <xavierm02>And then, the package installer makes the program use files in ~/.guix-home/<package-hash>-package-name/<thing> instead of ~/<thing>, where ~/.guix-home is readonly ~/<thing> is a symlink to ~/.guix-home/<package-hash>-package-name/<thing>. <xavierm02>And when you upgrade the package, it copies those files to the location with the new hash, so that if the new version deletes stuff / ruins your files (such as history and bookmarks in icecat for example), you can still recover. And if the new version converts some file to a new configuration format that's not backwards compatible, then you can still run the old program with the old config <xavierm02>And as a bonus, you can fully encapsulate programs, and not give them access to the user's home. With packages handling this, you can use packages that handle this with package that don't without punch holes yourself (since the real home is not readonly). <xavierm02>(Well in reality, you probably wouldn't want ~/.guix-home to be readlonly, just some files in it) <rekado_>jonsger: donât know how long the delivery takes. <rekado_>then installation, then moving the existing head node + storage to a new rack <rekado_>then updating the machine records and doing key exchange etc <efraim>jonsger: do you have any experience/links to using guix in docker for ci? <jonsger>efraim: not really. I used guix in docker only for some quick manual tests... But I think I saw some GitlabCI stuff with guix in docker... <xavierm02>error: failed to load 'guix/scripts/pack.scm': <xavierm02>ice-9/eval.scm:293:34: no binding `zip' to hide in module (gnu packages compression) <rekado_>did you run ./bootstrap && ./configure --localstatedir=/var and all that? <xavierm02>I hadn't rerun ./boostrap. I didn't think I needed to every time I pulled :o <efraim>I was looking to 'guix pull' and test a bunch of my customized packages <jonsger>oke. So then you need a different setup I think <jonsger>guile-json3 gots pulled in, so the pipeline should succeed :P <apteryx>interesting discovery: Guile macros cannot be used in Gexp scripts. <apteryx>eh, seems my discovery is rubbish... or I'm thoroughly confused. <apteryx>out of curiousity, do you see "driver 'pcspkr' already registered, aborting' when running: dmesg | grep pcspkr ? <apteryx>the system beep on my X200 stopped working out of the blue <apteryx>let me reboot to see if it's true for every boot... <jonsger>This time-error is only happening in guix 1.0.1 and gone in guix-weekly (build from recent master commit) <jonsger>efraim: the other error is "guix system: error: cloning builder process: Operation not permitted" when guix needs to build some software. This is due missing capabilities of docker. I didn't found the parameter yet or forgot it... <efraim>i didn't even see a cloning error <efraim>yeah. i might've missed it though <jonsger>so you shouldn't need "guix pull" then <efraim>jonsger: then i install 'guix' or 'guix-weekly' ? <apteryx>efraim: we're you replying to me when you wrote 'i see that too' ? <apteryx>OK! does this file exist on your machine: /dev/input/by-path/platform-pcspkr-event-spkr ? <efraim>/dev/input/by-path/platform-pcspkr-event-spkr: symbolic link to ../event8 <jonsger>efraim: succeded now, if you remove the "guix pull" step you could get rid of "/var/guix..." stuff :P <efraim>jonsger: then it doesn't know where the guix binary is <efraim>jonsger: I thought the 'dependant' field meant I wouldn't need to specify artifacts to carry over, but that might solve it <xavierm02>Is there some magic trick to not recompile everything when debugging the last phase of a package? <roptat>you can pass the test phase for instance by adding a #:tests? #f temporarily, it should speed up things a bit <xavierm02>So the problem with icons missing in LyX if qtsvg is not in the profile looks like it gets fixed by adding the qtsvg path in QT_PLUGIN_PATH with a wrap-program. <xavierm02>It seems to be a common problem and there are slightly different versions of that fix for several packages using qt. The wrapping looks pretty odd. Shouldn't the QT_PLUGIN_PATH instead be set in the profile? <xavierm02>With search-path-specification? (I'm not entirely sure what this does yet, but it looks like it could help) <runejuhl>Hi all. Is there a good way of making available a back catalogue of package versions so any version, previous or current, can be installed? As I understand it the git package repo (usually) only contains a single version of a given package. <xavierm02>runejuhl: Idk but "inferiors" should be a good keyword to search about that. <efraim>runejuhl: it's also possible to package older versions of packages <efraim>Using inherit it becomes much easier <runejuhl>efraim: alright, thanks -- I'll look into that <jonsger>efraim: I found the patches for the time issue while guix downloads stuff. They are already on it's way to Tumbleweed. Thanks for the hint :) <pinoaffe>hi everyone, I get "invalid keyword: #vu8()" when trying to install a local package, any idea what the cause might be <roptat>pinoaffe, maybe an issue with your local package then. Can you share the package definition? <xavierm02>Should I "make" every time I change a file in the guix repo before the "./pre-inst-env guix build mypackage"? <roptat>it's best, but it's not necessary <roptat>it prevents you from building the changed files everytime <roptat>your sha256 field must not be empty <roptat>(you can copy a hash from another package, and then guix will fail but tell you the actual hash, or simply download the soruce with "guix download", which will also give you the hash) <pinoaffe>it still fails though, for some reason :( <sneek>mbakke, you have 3 messages. <sneek>mbakke, raghavgururajan says: Any improvements regarding core-updates-->master merging? <sneek>mbakke, raghavgururajan says: Any improvements regarding core-updates-->master merging? Just following up :) <sneek>mbakke, nckx says: I think Raghav is practicing to be a manager some day. đ <pinoaffe>roptat: well now it says "Invalid keyword: #vu8(236 70 157 154 56 94 245 226 221 95 239 83 186 130 139 161 248 65 163 99 155 16 73 218 36 188 253 227 205 233 160 148) <shiftlockboom>Has anyone experience with installing guix on libreboot system with encrypted /boot? <pinoaffe>but anyhow, even when copying a string from other packages, I get an error message stating that #vu8 was not found <apteryx>good news, importing syntax using (use-module ...) inside a Gexp *does* work, after all. <apteryx>(begin (expr) ...) at the top level causes expr to be considered at the top-level by Guile <apteryx>could someone run "tzselect", 4 [enter], 19 [enter] and confirm they see: Therefore TZ='Asia/Tokyo' will be used. <apteryx>Selected time is now: Thu Aug 1 07:06:37 JST 2019. <xavierm02>what's your workflow to submit patches to guix? <xavierm02>after the part where the package is ready, properly indented etc. <xavierm02>do you git commit, git format-patch and send that? <xavierm02>the documentation talks about git send-email but that doesn't seem to exit <apteryx>xavierm02: yes, git commit, guix lint, git format-patch, git-send-email (or attach manually to your email client) and send to guix-patches@gnu.org <xavierm02>git: 'send-email' is not a git command. See 'git --help'. <xavierm02>It's really weird because tab autocomplete the "send-email" part.. <mbakke>xavierm02: You need to install the "send-email" output of git, i.e. `guix install git:send-email`. <roptat>pinoaffe, oh, that's because you use (guix build download) but you should use (guix download) instead <Marlin[m]>Hey guix, how can i dee xkb options? It would usually be in /usr/share/X11/xkb, but i didn't find it in guix-profile <samplet>Whatâs the story with core-updates? I have some time I could spend fixing something if thatâs helpful. <apteryx>Marlin[m]: I've 'locate' xkb, and one entry is: /gnu/store/i2zj3n2b2sxpkdikdxmkh1qpzphx7m2m-xkeyboard-config-2.24/share/X11/xkb <apteryx>so you'd want to 'guix build xkeyboard-config' to find yours <apteryx>docstring of `with-imported-modules' is not clear <apteryx>make MODULES available in the evaluation context of EXP <apteryx>this mislead me to think it did something like (use-modules X) for me. <apteryx>but if you know that gexp is a file, I guess there is less place for a doubt. <apteryx>nevermind, the later part of that docstring explains it more concizely: MODULES is a list of names of Guile modules searched in MODULE-PATH to be copied in the store <bricewge>Extending `shepherd-root-service-type` is there a way to use a list or function for `start`. <rekado_>do you know how I can build a virtual machine that does not need a graphical environment? <rekado_>I passed -curses to the generated VM script, but that only helps with early boot. <rekado_>(I just gave a presentation and it was embarassing not to be able to show off a Guix-built VM on the cluster.) <bricewge>I'm writing a service that should run at startup and at specific time. And I would like to use the same function in mcron and shpeherd. <rekado_>bricewge: a shepherd action requires a G-expression. <rekado_>I guess you could use the same procedure and just wrap it in a G-expression for use with shepherd. <rekado_>bricewge: do you have some WIP code that you could show us? <rekado_>bricewge: the Guix manual says in âShepherd servicesâ that you can define shepherd actions. <bricewge>In `auto-upgrade-shepherd-service`, `start` is incomplete. <rekado_>and they have a âprocedureâ field. <bricewge>Or am I missunderstanding what "action" are for. <xavierm02>I have a new dream: guix lazy-build that caches the content of the folder after each phase, and only recompiles if either the phase description or the content of a previous phase changed. <rekado_>bricewge: actions are for custom commands that are not start or stop. <rekado_>xavierm02: itâs a shared dream. Perhaps with some planning it can be made reality? <bricewge>rekado_: For running a headless VM `-nographic -serial mon:stdio -append 'console=ttyS0'` works for me. <bricewge>rekado_: Ok so I can't pass a gexp to start then <xavierm02>rekado_: It took me a day to find in which other package to copy code to make LyX work. I don't think I'm skillful enough to even attempt that yet. <xavierm02>Maybe next week if I spend the whole week doing stuff :) <minall>When buiding something on guix, the build is isolated right? then to install a package on guix, you should build it but from a package definition? that's the only way? <rekado_>minall: are you looking for another way? <xavierm02>I think that the next things I'll try are: (1) Look at making qtsvg export stuff so that all other packages that depend on it can stop wrapping. (2) Try to add a --no-building option to guix package <rekado_>minall: technically, the build is done from a derivation. A package definition is first compiled down to a derivation. <xavierm02>(But if those things look too hard for a newbie, I'd be happy to know it) <bavier>xavierm02: iirc the suggested option name in the past has been --only-substitutes <minall>Thank you, It was just a question for curiosity <minall>I'm trying to understand the inner working of the driver xf86-video-openchrome, any suggestions for a newbie?, they have a lot of .m4 files, I researched a little and it seems to be to make macros, but why m4 is used instead of other filetype? <bavier>minall: the .m4 suffix is usually used for files intended as input to the m4 macro processor <minall>sorry for my ignorance, m4 macro processor do you mean any processor? because in that case it makes sense it is used... <bavier>minall: see 'info m4' or 'guix package --show=m4' <quiliro>ayer no estuviste disponible, te buscaba para hacer el paquete de guix juntos <minall>bavier: I'll install it, but since I don't have it install, I assume that or, it is not required to my pc, or it is only required by building, or something I don't understand <minall>quiliro: En la tarde estuve un poco complicado, igual sigo investigando un tanto el paquete... <minall>Ahota mismo haciendo un video de instalacion de debian, para el curso, y mientras se instala sigo revisando el paquete del driver <minall>bavier: It seems that m4 is required by GNU Autoconf, which is used a lot in the package, now let's see what GNU Autoconf is ! <quiliro>mejor un vĂdeo de instalaciĂłn de preos <minall>quiliro: Lo seria, de hecho queria hacer de guix, pero el Doctor me dijo que mejor hicieramos de Debian, ya que es mas universal <vagrantc>tengo paquetes de Guix para Debian ... pero un poco viejo <minall>quiliro: Claro, solo que sin los repositorios non-free <mbakke>samplet: core-updates is still waiting for a full rebuild, once Mark and janneke has finished verifying the new bootstrap tarballs. <vagrantc>very exciting to see the reduced bootstrap <minall>quiliro: Pero el prefirio Debian, y claro no es mi eleccion <samplet>mbakke: Thanks for letting me know. Iâve since wandered off to work on Gash (i.e., do my part in further reducing the bootstrap binaries). <minall>vagrantc: I see, that would be awesome, since if you want to use guix on debian you have to install it manually! <minall>vagrantc: Buenas contribuciones! <samplet>mbakke: Okay. Iâm building ffmpeg to see what that test failure is about. <samplet>vagrantc: Are you using your ASUS C201 much? Do you know if it still works with a recent Guix? <vagrantc>samplet: i've only occasionally booted it, and never really got a usable GUI ... haven't touched it in a few weeks, but think i had it working with linux-libre 5.1.x <mbakke>samplet: you should probably wait until #6647 has started on the CI, as I just pushed a ~50% rebuild. <vagrantc>samplet: it's actually the fasted armhf build machine i have, though *mbakke wants to revive his bricked C201 :/ *vagrantc resurrected the C201 a few times with a chip clip while tested native u-boot patches <samplet>mbakke: Oh I see. Passing â-nâ gives me a âwill be builtâ list a mile long. :) I think I will try again later. <minall>quiliro: Igual el dice que esta bien ya que sin los repositorios non-free no debe de haber problema <minall>Guix, how do I get an enviroment to work under the package xf86-video-openchrome? i'm trying to d <mbakke>vagrantc: Yes and no.... I bricked the firmware and soldered on cables to the flash chip so I didn't have to buy a $20 chip clip....flashing went fine, but it refused to turn on afterwards :D <minall>I'm running= guix environment --pure xf86-video-openchrome, but I don't see any packages, or maybe I'm not using guix environment well? <minall>I can also check what the package contains, using -guix build --source xf86-video-openchrome-, it this a better aproach instead of using guix environment? <xavierm02>Is ./pre-inst-env guix install <package> really the way to test a package? <apteryx>xavierm02: you could also guix environment --pure --ad-hoc <package>, then start it from CLI there <minall>what does the -./pre-inst-env does? <apteryx>it sets the Guile load paths to use the Guix built from sources instead of using the 'normal' one. <apteryx>so that you can run guix from your source tree, without affecting your stable guix system <minall>I see, that was very aclaratory, thanks! <rekado_>mbakke: Iâd love to merge wip-texlive soonish. Is it ⊠expected to see so many build failures on ci.guix.gnu.org? <mbakke>rekado_: I think so.... All Java dependents fail on non-x86_64, for example. <mbakke>We really need a "compare" functionality in Cuirass... :/ <mbakke>rekado_: Some of those failures look "real" (though probably transient), e.g. roary and luminance-hdr should build on x86_64. <rekado_>mbakke: we also really need a ârestart buildâ feature on Cuirass â at least until we can depend on it to do the right thing all by itself. <rekado_>canât wait for the new build nodes to be operational. We should be able to use more of them for building for non-x86 via Qemu. <rekado_>theyâre probably fast enough to make this feasible. <rekado_>it bothers me greatly that our build farm setup isnât as helpful as we all hoped it would be. <efraim>Java on non-x86_64 fails on master too <xavierm02>Can't exec "autopoint": No such file or directory at ... <xavierm02>So I'm lazy and don't want to "guix environment guix" every time I interact with the git repo <xavierm02>And when I don't do it I get this error, but guix search and grep -rn both return nothing when I search for autopoint... <bavier>xavierm02: autopoint is in the gettext package <xavierm02>How could I find that information myself? My only idea would be to try all the dependencies of guix... <bavier>xavierm02: that's a reasonable approach ;) <bavier>xavierm02: we don't have any sort of binary-to-package lookup <bavier>it's something that cuirass could conceivably do <xavierm02>configure.ac:89: error: possibly undefined macro: GUILE_MODULE_AVAILABLE <xavierm02>(when running ./bootstrap outside of guix environment guix) <bavier>xavierm02: are you saying you want guix development packages installed into your profile? <dongcarl>mbakke: Did your changes fix #30756? Could probably be closed. ***Guest43664 is now known as benny
<mbakke>dongcarl: I haven't made any changes in that area since the switch to GCC 7 (which does not completely fix it). <mbakke>dongcarl: There are (probably..) still many packages with #include_next failures on core-updates, because they misuse `gcc -isystem`. <mbakke>Specifically, if you pass -isystem /path/to/glibc/include, GCC will fail. <vagrantc>haven't watched it, but hopefully wasn't too bad :) <mbakke>raghavgururajan: I will send an email once core-updates is ready for general testing. <roptat>raghavgururajan, you know your irc client can probably autocomplete names with tab? that way you can't misspell a name ;) <raghavgururajan>roptat I do not use IRC Client. I am using Gajim to connect to irc severs via xmpp-irc gateway. <raghavgururajan>roptat It is so easy for me that xmpp being extensible. I do irc via xmpp-irc (biboumi) gatway and so SMS via xmpp-sms (cheogram) gateway. Soom I will be using matrix and sip with xmpp. :) <niten>that results in: guix system: error: no target of type 'macvlan-bridge' for service 'macvlan-bridge-service' <niten>the only mention of 'macvlan-bridge' in the macvlan-bridge-service function (which is where I'm getting the error) is a record type <rekado_>xavierm02, bavier: how would the service behave in the presence of numerous builds of the same package with different hashes? For a âwhat providesâ query what should the service return? <lfam>Hey vagranct, what do you use to do the "live typing" thing in your talk? <vagrantc>lfam: the package in debian is "sm" called screen-message <lfam>Thanks, I like the style of presentation <vagrantc>it's a tremendously useful tool for lightning talks <vagrantc>and transmitting short messages across a room :) <Lukas4452>I get this error after successfully installing Guix <lfam>It's missing the kernel module sdhci_acpi.ko <Lukas4452>For those who don't open the pic: it says /gnu/store/<<hash>>-linux-modules/sdhci_acpi.ko <lfam>I don't have experience with this part of the system but I would try adding "sdhci_acpi" to initrd-modules in your OS declaration ("config.scm") <lfam>I'm not sure. Does anyone have experience dealing with missing kernel modules and Guix? <jonsger>Lukas4452: maybe you have to append %base-initrd-modules at the end of the initrd-modules list <rekado_>jonsger: is there a URL somewhere that proves that Guix can be installed in OpenSUSE? <rekado_>(I need it for a grant applicationâŠ) <lfam>Building Guix on core-updates I see these warnings: "WARNING: (guix scripts archive): `error-source' imported from both (gcrypt common) and (gcrypt pk-crypto)" <lfam>Is that going to be an issue? <lfam>Also, recent QEMU versions fail to build with "/gnu/store/.../glibc-2.28/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory" <xavierm02>So I installed all dependencies of the guix package in my profile and ./boostrap still doesn't work... <raghavgururajan>vagrantc Nice talk! So by packaging MES into debian, do you mean making debian distribution reproducible as well? <xavierm02>rekado_: If you're talking about the binary-to-package things, it's mostly useful when you don't have the binary. So you just want the name of the package that currently produces it <xavierm02>Lukas4452: Maybe cons -> cons* in the initrd-modules <rekado_>xavierm02: the thing is: we only know what *store item* provides a file. <jonsger>rekado_: Nice to see it mentioned in a grant application :) Together with efraim, I found a major issue in the package, but the fix is already on its way :) <xavierm02>rekado_: If the build server builds everything, you can make it look in the /bin of each store item, and then from the name of that store item, you get the package name <xavierm02>Other than that I'd expect it to be pretty safe <Lukas4452>Guix is pretty neat, it just needs to work on my Laptop <leungbk>Many of the web/json-related tests are failing for me right now, including many package-related ones. If I run `(lookup-origin "http://github.com/jgm/pandoc.git")` or similar in the Guile REPL after importing `(guix swh)`, I get #f. <leungbk>I'm guessing this is related to the Guile-json upgrade, but it's difficult to debug this with the REPL alone. <rekado_>leungbk: do you have any version of guile-json installed? If so: which? <leungbk>@rekado_ Yes, Guile-json 3.x to comply with what's expected on the Guix master branch. <xavierm02>Can I list the outputs of a guix package without looking at the source? <Lukas4452>I got a warning, "at least 2,497.7MB needed but only 1,657.9MB available in /gnu/store <lfam>xavierm02: Yes, they are in the output of `guix package --show` <mbakke>xavierm02: `guix package --show=package` and `guix search ^package$` will list the outputs. <lfam>Lukas4452: 1657MB is pretty small for Guix. At that size the configured system needs to be relatively minimal <lfam>I recommend either allocating more space or rewriting config.scm to create a smaller system <lfam>Lukas4452: Re-partition the storage <xavierm02>I think using the partition editor would be a way better idea than trying to do this from a command line <xavierm02>so try to remember what you modifier in the config.scm and start again <lfam>Lukas4452: Are you sure you followed all the steps in the installation instructions? It sounds like the target partition was not mounted <null_radix[m]>hi :) is there anyway to test services that you are writing? With packages i was using the preinstall script and developing in the guix repo. Is there a simiral work flow for services? <lfam>And did you manually start the cow-store service? <xavierm02>idk about guix but on other distros you can ctrl+alt+F2 to get a terminal <lfam>I would manually check the size of the partition before doing the final step in the GUI <lfam>It sounds like something isn't working there <lfam>Okay, but Guix is trying to install to a partition that is only 1.6 GB <xavierm02>null_radix[m]: The ./pre-int-env thing apparently just tells guix where to look for stuff so the same workflow should work. I've never done it though. <lfam>So, something is not right :) You'll need to make sure it's installing to the partition that you want it to <Lukas4452>I guess Guix downloads to ram 1.6 GB and then copy to the 50GB /mnt <lfam>You aren't limited by your RAM when downloading things here <Lukas4452>Ok, then the installer can't see it right, cfdisk says 50gb <lfam>Lukas4452: It sounds like the cow-store service isn't working right. If that service is failing, then you will be limited to RAM <xavierm02>So since instealling all of guix's dependencies didn't work to avoid having to "guix environment guix", I have resorted to a bash alias. But it's still pretty slow. Is there some way to speed it up? <xavierm02>I am under the impression that the packages available in ./pre-inst-env are not really updated by running make in the git repo. Is this normal? <lfam>xavierm02: What you see with ./pre-inst-env should reflect what has been built in the Git repo. <str1ngs>xavierm02: its updated with ./configure <str1ngs>pre-inst-env.in is expanded to pre-inst-env <lfam>`./configure --localstatedir=/var && make`, assuming your localstatedir is really /var/guix <rekado>xavierm02: whatâs the reason to avoid âguix environment guixâ? <rekado>xavierm02: if you want this to be persistent you can also use â--rootâ with âguix environmentâ <vagrantc>mbakke: huh. looks like some fundametal change in python test infrastructure ... won't actually have a chance to look at for another week or two <vagrantc>mbakke: might be worth trying to update u-boot to 2019.07 ... <vagrantc>i don't recall needing anything unusual to test the 2019.07-rc* versions ... <GNUtoo>hi, I'm trying to have all the software tools I use for developement be FSDG compliant, <GNUtoo>For instance I often have to cross compile software for specific kernel versions for instance <GNUtoo>Is it possible to use Guix to do that, for instance to cross compile tools like evtest for ARM to run with a 3.0 kernel? <GNUtoo>(like by changing the linux headers and glibc versions and whatnot) ***weedloser_ is now known as weedloser
<dongcarl>GNUtoo: Yes, Guix is especially good at creating artisanal toolchains like that <vagrantc>oh, guix switched to guile-json 3.x ... well, that simplifies some things for debian packaging <GNUtoo>thanks a lot, I was used to yocto years ago <mbakke>vagrantc: master is fine, it probably has to do with the new pytest (4.4) on core-updates. <Lukas4452>TWO hours of walking in a circle, does someone know how to fix that? <mbakke>vagrantc: No hurries, we're still waiting on a (final!) full rebuild. <roptat>Lukas4452, could it be you need sdhci-acpi instead of sdhci_acpi? <mbakke>Lukas4452: what is your error message? <GNUtoo>dongcarl: is there some documentation on how to do that, like have local git source in some directory and build from there? <roptat>(I got that when installing on an arm board: guix would give me the name with a _ but I needed the name with a - instead, or the reverse) <roptat>Lukas4452, looks like the issue I had with my arm board, I replaced _ with - <Lukas4452>I didn't install it tho, it was the installer <roptat>oh, so maybe you need to install manually :/ <roptat>not sure if the installer can generate the file and if you can modify it afterwards <GNUtoo>dongcarl: oh ok, I start to understand <mbakke>Lukas4452: what kind of system are you installing on? <GNUtoo>So I've to make standalone scheme files <Lukas4452>If I fixed it with _ > - , is the installer broken? Should I create a issue on the bugs mailing list? <mbakke>Lukas4452: are you installing to a SD card? <mbakke>Lukas4452: please report it to bug-guix@gnu.org <vagrantc>there are a handful of sbustitute* patches in u-boot-tools ... maybe some of them are no longer needed <vagrantc>Lukas4452: really, the bug is in linux being inconsistant with what the loaded modules vs. filesystem modules are called ... <vagrantc>sometimes modules with an _ are remapped to - when loaded and vice-versa <Lukas4452>But we will see if that was indeed the little dash that caused it <vagrantc>i thought there was a fix for that particular problem at some point... <mbakke>vagrantc in this case it seems like a critical module is missing from the initrd <roptat>vagrantc, I think I reported it already, and solutions were discussed, but I don't remember seeing a fix <mbakke>Lukas4452: can you share the configuration file? <Lukas4452>I will write some "nice" comments in that config.scm <xavierm02>rekado: My main reason was laziness. But with a bash alias and --root everything it's already nearly perfect. One thing I really disliked while I was using fish is that it doesn't have the [env] thing so I never know where I was, but now I switch back to bash so that's one less reason <roptat>Lukas4452, if that works, would you like to write to that bug (34902@debbugs.gnu.org) to say you hit the bug too? <sneek>Welcome back excalamus, you have 1 message. <sneek>excalamus, nckx says: I just missed you, but hi and welcome đ <Lukas4452>Since 2and a half hour we try to fix that and still the same??? <Lukas4452>Jeez I'm really really mad at myself and guix <mbakke>Lukas4452: Does the config contain a line like (initrd-modules (cons "sdhci-acpi" %base-initrd-modules)? <Lukas4452>It is (initrd-modules â("mmc_block" "sdhc-acpi")) <nixo_>Hi! guix pack is failing to create a working gzip with r (guix pack -RR -S /opt/gnu/bin=bin r r-purrr). Other programs are working (e.g. julia) <roptat>that's another bug then, you definitely need %base-initrd-modules <roptat>try (initrd-modules (cons* "mmc_block" "sdhc-acpi" %base-initrd-modules)) <roptat>are you using the installer from 1.0.1? <rekado>nixo_: oh, perhaps thereâs an unqualified reference to gzip in R. <roptat>mh... I kind of remember that bug... I thought it was fixed <nixo_>rekado: I think I was not clear. It's creating the tarball, but I get: ./opt/gnu/bin/R: bad interpreter: /gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash: no such file or directory <roptat>oh that was already too late for 1.0.1 <nixo_>(rekado: while guix pack -RR -S /mybin=bin bash works, I can run ./mybin/bash with no problems) <jonsger>roptat: ah yes, I run into the same issue while installing guix on a Hetzner vm <jonsger>Lukas4452: maybe I have a iso laying around including the patch. Are you on x86_64 or aarch64? <xavierm02>Is there no vi package? (I know there are many variants but some programs (e.g. git) just really want to open vi (at least when EDITOR is not set) so if there's a package I'd like to install it in case I need it someday <lfam>xavierm02: There are the vim, vim-full, nvi, and neovim packages <lfam>nvi is probably the smallest <xavierm02>They never said it was easy to install, they said that if you ever get it working, and then mess it up, you can get back to the working state :D <lfam>We definitely want it to be easy to install <jonsger>with this image I succeded back then :) <Lukas4452>Again , I will see if it again says "missing sdhci" <xavierm02>I can help you break it once it's running if you want <Lukas4452>Well, my address is "Görlitzer StraĂe 78, 26127 Oldenburg, Germany" <vagrantc>or --ignore-missing-modules or something in the "guix system reconfigure" call <roptat>Lukas4452, don't you need "sdhci-acpi" in that list then? <Lukas4452>I can't skip the module that loads my heckin mmc <vagrantc>you can check if it's actually in the initramfs and possibly ignore that error... <vagrantc>i had to use something to avoid the module check when first working on the softiron overdrive and novena boards, if i remember... <minall>quiliro: I need to talk with you <roptat>vagrantc, but that's a boot error, not a reconfigure error, right? <vagrantc>the error i recall was a reconfigure error <roptat>Lukas4452, my best guess is that you need either sdhci_acpi or sdhci-acpi in your initrd-modules <roptat>you can probably find where they come from to get the correct name <vagrantc>specify both of them and use --ignore-missing-modules or whatever it was called :) <roptat>no, because guix will try to load both at boot, and one of them will fail <roptat>at reconfigure time, it can find the module as sdhci_acpi or sdhci-acpi just fine, so it doesn't give a warning or anything <vagrantc>guix loads modules manually? it doesn't rely on other tools to implement that? <Lukas4452>Dude, vagrantc, the missing module loads my disk <roptat>Lukas4452, from that issue, it seems you need to add "sdhci-acpi" to that initrd-modules line <quiliro>and learning reverse engineering drivers and firmware <roptat>Lukas4452, along with the rest of them, of course) <vagrantc>i've played this game a few times, and there are some ugly workarounds <vagrantc>you might want to check from the initramfs shell if the module you need is present in the initramfs, and guix is just not loading it for some reason <rekado>nixo_: oh, I understand. Thatâs odd. R is a shell script that eventually runs some binary. I wonder if this problem exists for all shell scripts. <rekado>R keeps a reference to bash, so I wonder why the relocatable tarball doesnât arrange for it to be found. <rekado>it should be part of the tarball. <nckx>sneek: later tell apteryx: When I run tzselect, 4, 19 on Guix System it jives with what DDG tells me is the âtime in tokyoâ⊠<xavierm02>I just looked at the make targets and there is none called installer <nckx>xavierm02: It's in the manual (it's not a make target, but a Guix command). I forget where. <nckx>(guix system disk-image âŠ) <nckx>xavierm02: ./pre-inst-env guix system disk-image gnu/system/install.scm <xavierm02>./pre-inst-env: /home/xavierm02/Workspace/guix/scripts/guix: /gnu/store/2lkjflfxlv444iywq2hhlrjvf74d0l1m-profile/bin/guile: bad interpreter: No such file or directory <nckx>xavierm02: That looks like you need to bootstrap after a âah, yes, you guessed it. <nckx>Lukas4452: Chill your horses. This'll take at least a few minutes. <nckx>Seems like I'm building the kernel first, I guess it was just updated. <xavierm02>I do that regularly, it's like 30min I think <nixo_>rekado: yes, I was thinking the same but don't know which other program to test <lukas4456>xavierm02, nckx : if done please send mail with the link to luraktinus@gmail.com <nckx>lukas4456: Hmkay. I don't know *why* I'm building this for you, I just happened to lurk upon your question, but I hope it works for you. <lukas4456>i have 2 Hours and 30 mins left till my internet is down <lukas4456>nckx: the curent installer is completly broken for me <nckx>lukas4456: Unless something goes plain wrong you'll have it before then. <nckx>Dunno. I'm just going to throw it up on my site. <xavierm02>lukas4456: If you really need something running, now would be a good time to download a debian live-cd, just in case. <nckx>Yes. Pipeline your life. <avocadoras>Hi, I have some questions about Emacs download from guile repo; how does it work? kind of confused after reading through the docs <nckx>âŠtar? Wait, we are talking about the ISO, right? <lukas4456>pack the iso in a tar.xz archive like the official installer <nckx>I'm positive the official installer is not tarred. <avocadoras>"By default, Emacs (installed with Guix) âknowsâ where these packages are placed, so you do not need to perform any configuration" <avocadoras>I'm not sure what this means... I currently install packages from Melp, elpa, gnu with use-package which uses package to manage everything <avocadoras>does this mean that I could get rid of my ~/.emacs.d/init.el file ? <xavierm02>Well stop installing with anything other than guix <nckx>avocadoras: Easy to test⊠<nckx>(I also think not, not outright anyway.) <xavierm02>I do know that something like half of guix packages must be emacs related so you can just guix install all the things you previously installed via melp / elpa etc. <avocadoras>nckx: I would have to use guix install emacs instead of apt install emacs? <xavierm02>Oh. You're using Guix on another OS, not GuixSD <nckx>avocadoras: Absolutely no idea. Guix on other OSes is a strange & scary land for me. <vagrantc>avocadoras: if you're running a debian based distro with guix on top, you could choose either, depending on where you wanted to get emacs from ... <xavierm02>any emacs mode installed with guix will work with the emacs installed with guix <xavierm02>any emacs mode installed with apt will work with the emacs installed with apt <avocadoras>ok, gotcha. I've not moved to GuixSD cause I dont have compatible hardware, I need propietary stuff still to have wifi running etc <xavierm02>anythign mixing the two, strange stuff may happen <avocadoras>"By default, Emacs (installed with Guix) âknowsâ where these packages are placed, so you do not need to perform any configuration. If, for some reason, you want to avoid auto-loading Emacs packages installed with Gui..." <nckx>Guix's emacs package does some patching (âMake sure Man looks for C header files in the right placesâ, âUse 'guix-emacs' in "site-start.el". This way, Emacs packages provided by Guix and installed in ~/.guix-profile/share/emacs/site-lisp/guix.d/PACKAGE-VERSION are automatically found.â). <dutchie>and stuff i have installed via use-package and melpa works fine <nckx>avocadoras: That's probably what that paragraph is referring to. <dutchie>(although it's on my lengthy todo list to make guix definitions for the packages that aren't available yet) <nckx>dutchie: Guix's emacs or Arch's, though? <nckx>[linux-libre: âMODPOST 5277 modulesâ. Wow.] <nckx>xavierm02: Not yet. Turns out the machine I offload to was already building a different linux-libre. Oops. I've paused that one. 
