<lfam>shoaloak: Those lines are used to import other files of code. (gnu system nss) is the module used by GuixSD for the Name Service Switch functionality. The module name (gnu system nss) corresponds to the filesystem path gnu/system/nss.scm in a copy of the Guix source code <mbakke>shoaloak: I think it should be (use-modules (gnu) (gnu system nss)), which simply means load "gnu.scm" and load "gnu/system/nss.scm". <mbakke>lfam: (guix utils) need to be imported in the builder. But, that will change all users of meson-build-system. So I'll revert it for now. <sensiblemn_>fyi: someone in the #libreboot channel is trying to figure out how to boot a GuixSD DVD in libreboot. i don't know how to help them but maybe someone here could. <mbakke>lfam: You should be able to pull staging and get substitutes for most things now. <lfam>sensiblemn_: Can you point them to this channel? <swiftgeek>srsly anyone write some roadmap/ticket on putting those things into squashfs <swiftgeek>sensiblemn_: libreboot is completely irrelevant at this point <swiftgeek>sensiblemn_: the only workaround i can think about is to put it on separate btrfs partition with compression enabled <lfam>I think we should avoid being derogatory towards other projects here, okay? :) <mbakke>Are we still allowed to bash systemd? :P <lfam>I'll meet you by the railroad tracks after school mbakke! <swiftgeek>well it's a simple issue that is a major roadblock for portability of installation medium <sensiblemn_>lfam: as long as you don't bash bash, i think that's ok. <mbakke>swiftgeek: I didn't follow the discussion, what was the problem with the ISO? <swiftgeek>there should be only 3 things required in install medium of an distro: kernel, initrd, and compressed filesystem <mbakke>swiftgeek: Contributions welcome ;) <swiftgeek>just stating the issue so maybe somebody can create ticket or sth for it <mbakke>swiftgeek: Feel free to email bug-guix@gnu.org with details. <swiftgeek>all i see it hat guixsd iso has 7096 directories, 45806 files <mbakke>Ah, right. Compressing that with SquashFS would be great. Would you be willing to create a bug report regardless? <mbakke>Oh wait, the PatchELF change was only for armhf, which doesn't use PatchELF. <mbakke>So I guess we can revert the revert. <swiftgeek>what i can say additionally is that some kind of kcmdline option is required for passing location of squashfs image <swiftgeek>then it can nicely fit with everything else out there <swiftgeek>but again since i'm not an user i can't propose anything <swiftgeek> --root=31393730-3031-3031-3139-343131363739 --system=/gnu/store/1adnfzni8i9zbn4fjabwr82b01fpk352-system --load=/gnu/store/1adnfzni8i9zbn4fjabwr82b01fpk352-system/boot # looks as alien as it gets to me <swiftgeek>in any case i have nothing in common with guix which is why i come here :) <swiftgeek>despite grepping for iso9660 i'm afraid i can't read initrd <swiftgeek>d4sz5f55amx82mcj52h0s0zar4sdipc5-uuid.scm looks somewhat close <swiftgeek>but i still don't see anything forcing iso9660 <swiftgeek>i see something that seems to load kernel modules, and i guess it's not loading enough unless eg. ext4 is compiled in <swiftgeek>so the only thing that somehow kicked in so far is shrink pendrive partition by whatever you expect guix iso to be (i used 2GiB), dd iso onto it <swiftgeek>copy vmlinuz + initrd to main partition because grub freaks out ***fkz is now known as Guest93222
<wigust->Hello Guix, How to escape ‘@’ in a package description? <civodul>mbakke: wasn't the target-arm32? issue misdiagnosed? <civodul>it was used in (guix build-system meson), which is "host-side" code <civodul>(except maybe armhf-linux rebuilds of course) <efraim>Sorry about that, I normally don't push commits at night <efraim>mbakke: how's glibc coming along? <voronovank>hi! I'm an applicant for outreachy program and I have some problem with guix. I'm trying to add "dropbox" package. I've got package definition by "guix import pypi", but apparently it requires "pytest-runner" and when I'm trying to get its definition by "guix import pypi pytest-runner" I get this -- https://paste.debian.net/1015661/. And right now if I'm trying to "guix import pypi dropbox" I also get something similar. I'm definitely doing something <voronovank>wrong but I can't figure out what exactly and I'll be grateful for help! <efraim>it has to do with the certificate, there's something in the manual about X.509 certificates <efraim>but I normally try wrapping it in `guix environment guix`; so it would be `guix environment guix -- guix import pypi pytest-runner` <civodul>essentially you need to (1) install 'nss-certs', and (2) define a couple of env vars as described <efraim>I haven't looked at the python dropbox package recently, but I'm not sure that it will function without the actual dropbox program, which isn't eligible for inclusion into guix proper <grafoo>hi! i'd like to setup virt-manager/libvirt with guix. is there a recommended way to do so? <grafoo>currently i installed libvirt as root and created corresponding systemd services for the daemons manually. <grafoo>btw. i'm on debian9/ubuntu16.04/fedora27 <mbakke>civodul: There is one test for arm32 in the "builder" of meson-build-system, which affects all platforms. <civodul>grafoo: no special recommendations; on GuixSD people would use the services available there <civodul>on other distros you could roll your unit files, indeed <grafoo>civodul: ok thanks. everything worked out fine so far, however there is no default network device listed in virt-manger. <grafoo>added e.g. a bridge device manually works though. <civodul>i'm not familiar with virt-manager though, so i can't help on the specifics <grafoo>no worries. should i post the info in this channel if i find out how to create a working non-guixsd setup for virt-manager? <grafoo>but it seems like symlinked paths are not supported by the server <civodul>grafoo: you could post the info on the help-guix@gnu.org mailing list (no need to subscribe) <grafoo>has anyone experienced something similar? <civodul>you have to do "xset -fp $(readlink -f ...)" or something like that <civodul>this has been fixed in the manual in master <grafoo>thumbs up for all of you creating guix. i like it very much so far :) <voronovank>efraim, thanks for information about dropbox. If it's true I'll find something else that i'd like to add. <efraim>hmm, tried to update my copy of mcron and it wouldn't read my files in .config/cron/, i'll have to look at my jobs later <civodul>oh, let me know when you have more info <mbakke>civodul: There are only 500 builds left in the Hydra staging queue, and the master evaluation timed out. <mbakke>WDYT about merging and starting a new evaluation? <mbakke>Many of the remaining builds needs to be rebuilt on 'master' anyway thanks to the imlib2 and imagemagick update. <civodul>did you try GNOME or something like that? <mbakke>Oh... "adwaita-icon-theme" fails in the unpack phase with "tar: This does not look like a tar archive". How did that happen. <mbakke>Odd, my source archive was 0 bytes! Had to manually GC it. <mbakke>Must be from my aggressive GCing the other day, but disconcerting that it would leave and try to use an empty store item. <mbakke>Hmm, "gspell" has the same problem. <grafoo>is there a way to "rebuild" an official package with different configure options? <wxie>civodul: I have got feedback from #libreboot. <wxie>civodul: regarding guixSD DVD booting <wxie><swiftgeek> and keep in mind libreboot is 100% irrelevant <wxie><swiftgeek> specing: tree of that iso is literally megabytes <wxie><swiftgeek> 4MiB of tree <wxie><swiftgeek> this is beyond ridiculous <wxie>civodul: I do understand that, but is guixSD iso a problem for booting? <rekado>grafoo: you can define a package variant. If you want to use it as a dependency throughout the package graph, you will need to rebuild dependent packages though. It’s possible with the package-input-rewriting facility. <mbakke>efraim: can you test #30873 on aarch64? <mbakke>wxie: It's still not clear why this ISO only fails to boot on Libreboot though. <efraim>mbakke: it might be a little bit, we're spring cleaning and all my machines are off <efraim>Its eerie how quiet it is with no computer fans <mbakke>People have successfully installed it before, could it be a problem in newer versions? <efraim>mbakke: I looked at it quickly from my phone, should we also remove bison as an input from the other glibc-s? <grafoo> `guix build -f libvirt.scm libvirt-custom` returns `guix build: error: libvirt-custom: unknown package` for that matter <mbakke>efraim: I didn't think it was worth the effort. Besides, the other libcs do use it when available. <mbakke>grafoo: For `guix build -f`, you'll need to return the package object in the file. So just adding a single line with "libvirt-custom" as the last line should do the trick. <grafoo>ice-9/boot-9.scm:3823:12: ice-9/boot-9.scm:3823:12: Wrong type to apply: "libvirt-custom" <grafoo>mbakke: sorry to bother you but i've only started out with guix yesterday. <wxie>mbakke: Thanks for the information. Do you mean that somebody is investigating? <mbakke>grafoo: Try to just `guix build -f the-file.scm` without any further arguments. <mbakke>wxie: Not to my knowledge. Can you file a bug report? <mbakke>civodul`: GNOME seems fine, and I've reconfigured my system and profile on it. <mbakke>Bah, this matrix client doesn't grok backticks in user names. <wxie>mbakke: ok. I will do that. <mbakke>civodul`: I'll go ahead and merge, please start a Hydra evaluation when you're around. <grafoo>same result: ice-9/boot-9.scm:3823:12: ice-9/boot-9.scm:3823:12: Wrong type to apply: "hello" <mbakke>grafoo: On the very last line, return just the string "hello", without parens or quotes. <mbakke>civodul`: I'm getting "In procedure scm_lreadr: guix/build/gnu-build-system.scm:345:53: unknown character name ---" on core-updates after the latest commit. <sneek>Welcome back bavier`, you have 1 message. <sneek>bavier`, civodul says: re "commit bc499b113 broke guix build on guile@2.0.14", please submit a bug report, yes :-) <nee``>I removed a bunch of services from my config, ran reconfigure, readded some and made a new reconfigure. Now some of the service user-accounts have different UIDs and can no longer access their old files, so the services fail to start. I manually reset some UIDs and GIDs, but mariadb still fails to start. <mbakke>nee``: That's terrible. Can you file a bug report? <nee``>I haven't checked if it's completely reproducable, yet. It took me some time to realize the UIDs changed. I assume users get removed when there are no references to them? <mbakke>nee``: Yes, "service users" get removed when they are no longer needed. <mbakke>NixOS have dedicated user IDs for each service, maybe we'll need to employ something similar. <thorwil>so now my build fails with: module not found "xts.ko". but i have Cryptographic API: -*- XTS support <thorwil>i.e. it's fixed on Yes. if that isn't the option tied to xst.ko, i have a hard time finding any hint <thorwil>efraim: i don't know if guix cares about builtin vs module <thorwil>but menuconfig is very stubborn on having that on -*- <g_bor>I'm preparing two patches now, and I have questions about how to divide them up, and how to parse the commit message. <thorwil>most surprising of that list of modules (or kernel features?) guix expects was hid-apple <g_bor>One of those is a refactoring. Do we use refactoring terminology there, like extract function from module to module, and like or just like we do with any other patch: delete variable from module 1, module 2 new variable? <g_bor>The other patch adds the same native input to over 50 packages. Should that be a series of 50 patches, with the usual commit messages broken up by package, or is there any other way to create that, and still be acceptable? Usual policy demands to patch one package at a time if I get it right... <efraim>I did one per package for source-file-name, but it could go either way <bavier`>g_bor: factoring terminology is fine. you'll see commit logs like "* file.scm (foo): move to ...\\n* file2.scm: ... here." <g_bor>Ok, fine, then I will use that. <g_bor>Do you have any idea about the other case? <g_bor>It comes from, that is a package is using juint, and is also using the ant-build-system, and the ant specified is the java8 variant, then ant-junit is needed as a native-input. <bavier`>I think a single commit would be fine <bavier`>but like efraim mentioned, there's case history in splitting it up. <vvedantham>When I try "guix environment guix" I get the following warnings and then nothing else <vvedantham> /gnu/store/f8k940vy9gck66m9r4id5m098w3hxgka-bash-minimal-4.4.12/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) guile: warning: failed to install locale warning: failed to install locale: Invalid argument substitute: guile: warning: failed to install locale substitute: warning: failed to install locale: Invalid argument bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) bash: warning: set <bavier`>imo, if it addresses a single issue, a single commit is fine; it just happens to affect many packages <bavier`>vvedantham: those are warnings. does it put you in the expected shell environment? <vvedantham>bavier: No it does not. Just exits out after these messages are printed. <g_bor>Ok thanks for the info, I've gotta go now. Bye! <thibran>Hi, I need a little help. Since a few weeks I can't run 'guix pull'. Any idea how to fix it? <roptat>I've already seen this error when a configuration file was precompiled for a previous version of guix <thibran>Is there a way to delete the wrong precompiled file? <roptat>so maybe your version of guix is very old? <roptat>when was the last time you guix pull'ed? <thibran>guix (GNU Guix) c553b08b4949c9bb53ffd9b83b5a6de8e459ac25 <roptat>I think the best way to solve it is to move the latest symlink like so: mv ~/.config/guix/latest{,.bak} <rekado>what does “echo $GUIX_ENVIRONMENT” print? <thibran>I moved the config and pull is currently working <rekado>“guix environment” is expected to spawn a sub-shell in which the requested packages are available. <rekado>so if it is successful you don’t see any extra messages. <thibran>echo $GUIX_ENVIRONMENT -> returns nothing right now (but maybe because the pull is running) <roptat>thibran: the message was not for you ;) <thibran>I use fish shell, if this changes anything <thibran>The pull is still running. All seems to work fine. Thanks a lot! <rekado>vvedantham: could you please paste the complete output to paste.debian.net? <rekado>vvedantham: please try this: “guix package -i glibc-locales”, then “export GUIX_LOCPATH=$HOME/lib/locale”. <rekado>then in the same shell try running “guix environment guix” again. <rekado>vvedantham: could you please paste the result of running “env” to paste.debian.net? <vvedantham>rekado: env | grep GUIX gives GUIX_LOCPATH=/home/vvedantham/.guix-profile/lib/locale GUIX_ENVIRONMENT=/gnu/store/089fxz54l14xsldvx4ls21njl12d5n4i-profile <rekado>vvedantham: do you get the same error after “unset LC_ALL”? <rekado>you may also need to do “export LANG=en_US.utf8” <efraim>mbakke: I'm having trouble applying the patch, but it's probably something I did. building out to glibc and make now <mbakke>efraim: Can you also/instead try the updated patch sent recently? <rekado>vvedantham: oh, you know, this could be a problem of the guix-daemon’s environment. <vvedantham>rekado: just doing an unset without the export gives me guile: warning: failed to install locale warning: failed to install locale: Invalid argument substitute: guile: warning: failed to install locale substitute: warning: failed to install locale: Invalid argument bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8): No such file or directory <vvedantham>rekado: I simply rebooted after the install script and tried "guix package -i hello" and that gave some results. Doing guix-daemon --build-users-group=guixbuild now says "guix-daemon: command not found" <rekado>vvedantham: that’s okay. “guix-daemon” is not in your environment. <rekado>vvedantham: are you using Ubuntu? <rekado>vvedantham: what does “/sbin/init --version” say? <rekado>that’s what the installer script checks to see if you’re using Upstart or SystemD <efraim>ah, i see you removed the pt_BR translations, that was one of teh files that gave me trouble <efraim>ok, i've applied the new glibc-2.27 patch and patches 2 and 3 <vvedantham>rekado: /sbin/init: unrecognized option '--version' <rekado>vvedantham: okay, good. So the installer script probably installed the systemd service file. <rekado>vvedantham: does /etc/default/locale exist? If so, what are the contents? <rekado>vvedantham: hmm, I’m sorry, I’m not very familiar with locale problems on Ubuntu. <rekado>my guess is that the locale data for en_US.UTF-8 don’t exist. <rekado>another thing that might be problematic is that your default locale is not a UTF-8 locale. <thorwil>something in guix kernel configuration makes XTS support switchable to M, but i can't find it <thorwil>not only is XTS support fixed to Y with my custom config, that's also the case for a completely new one <thorwil>is the primitive-load with kernel modules accessible to an inheriting package definition? <mbakke>thorwil: in the interactive kernel configuration menu, you can see what pulls it in by pressing '?' IIRC. Try switching the reverse dependencies to 'm'. <thorwil>mbakke: already tried a few rounds of that <thorwil>now i took the guix config, tweaked some cpu related options. replaced the entire block device-drivers up to file-systems with one taken from my custom config <nckx>thorwil: So what's selecting it? (‘Selected by...’) <thorwil>Selected by: CRYPTO_DEV_CCREE [=n] && STAGING [=y] && CRYPTO [=y] && CRYPTO_HW [=y] && OF [=n] && HAS_DMA [=y] || FS_ENCRYPTION [=m] || CRYPTO_CAMELLIA_X86_64 [=m] && X86 [=y] && 64BIT [=y] && CRYPTO [=y] || \\ │ <thorwil> │ CRYPTO_CAMELLIA_AESNI_AVX_X86_64 [=m] && X86 [=y] && 64BIT [=y] && CRYPTO [=y] || CRYPTO_CAMELLIA_AESNI_AVX2_X86_64 [=m] && X86 [=y] && 64BIT [=y] && CRYPTO [=y] || CRYPTO_CAST6_AVX_X86_64 [=m] && CRYPTO [=y]\\ │ <thorwil> │ && X86 [=y] && 64BIT [=y] || CRYPTO_SERPENT_SSE2_X86_64 [=m] && CRYPTO [=y] && X86 [=y] && 64BIT [=y] || CRYPTO_SERPENT_SSE2_586 [=n] && CRYPTO [=y] && X86 [=y] && !64BIT [=y] || CRYPTO_SERPENT_AVX_X86_64 [=m]\\ │ <thorwil> │ && CRYPTO [=y] && X86 [=y] && 64BIT [=y] || CRYPTO_SERPENT_AVX2_X86_64 [=m] && CRYPTO [=y] && X86 [=y] && 64BIT [=y] || CRYPTO_TWOFISH_X86_64_3WAY [=m] && CRYPTO [=y] && X86 [=y] && 64BIT [=y] || \\ │ <thorwil> │ CRYPTO_TWOFISH_AVX_X86_64 [=m] && CRYPTO [=y] && X86 [=y] && 64BIT [=y] || CRYPTO_DEV_QCE [=n] && CRYPTO [=y] && CRYPTO_HW [=y] && (ARCH_QCOM || COMPILE_TEST [=n]) && HAS_DMA [=y] && HAS_IOMEM [=y] <nckx>‘Selects’ are distinct from ‘depends’, and are declared by the selecting symbol. I think the output above is about as close as the Kconfig system comes to listing them sanely. It's all very... suboptimal. <nckx>Usually it's pretty easy to parse once you learn the precedence, but I can't make head nor tail of yours. :-/ <nckx>make[1]: *** [scripts/kconfig/Makefile:23: xconfig] Illegal instruction <thorwil>indeed. the reason i did not just use the guix config is that my custom config contains exactly the right device drivers. changing from gotta-build-them-all to that seemed too much work <nckx>Looks like I won't be helping you tonite :-D <nckx>Menuconfig works. CRYPTO_XTS is {M} here... <thorwil>no worries, the kernel build takes very roughly half an hour. it's such nice suspension to only then learn if those modules are all in place <thorwil>nckx: like i said, i only got it to {M} by loading the guix config. it's -*- for my custom config or when starting with none at all <nckx>My configuration isn't based on Guix's. But the dump above *is* from your custom config, right. <nckx>just diffed it with mine and they appear identical -_- <thorwil>nckx: just wanted to say. that dump is with the guix config <thorwil>guess i could have made a list of those to diff with ... but now i got my frankensteined one ^_^ <nckx>I thought it was obvious that I wanted to see the *problematic* one, but oh well :-D <nckx>So it works, now? Great! <thorwil>nckx: i will know once the kernel has been built <thorwil>a bit messy because the top is pasted back from my log