<vagrantc>hmmm... i wonder if rather than doing all these "make dist" related steps by hand ... if i shouldn't just make it a package definition. :) <xelxebar>On an unrelated note, I find it annoying that to run a docker-service-type, you need elogind, which in turn starts an entire graphical login :/ <xelxebar>Pretty sure we don't need to force a graphical login just to run dockerd. <vagrantc>hrm. i thought this would be as easy as (define-public guix-tarball (inherit guix)(name "guix-tarball")) with some tweaks to the build phase, but no dice. <vagrantc>hrm. i thought this would be as easy as (define-public guix-tarball (package (inherit guix)(name "guix-tarball"))) <vagrantc>exactly that, all i get is: guix build: error: guix-tarball: unknown package <xelxebar>vagrantc: How are you invoking the build? I just tried something similar yesterday without problems. <vagrantc>the above in package-management.scm without proper indentation... <vagrantc>i first tried something more complicated, but then i figured i'd try to reduce it down... <xelxebar>terramorpha: I can't point you to any official list, but alternative substitute servers do get discussed here every now and then. Some are officially run by Guix, others by users. <mroh>anyone knows if/where we have "gstreamer-player"? meson.build:23:0: ERROR: Dependency "gstreamer-player-1.0" not found, tried pkgconfig <sneek>mroh, luis-felipe says: Thanks, but I don't have access to the router myself. I kinda depend on services run by kind souls on the Web. <xelxebar>terramorpha: IIRC, most of these alt servers offer substitutes for specific collections of packages rather than act as full drop-in replacements for the official one. <mroh>ah, nvm the pkgconfig is in gst-plugins-bad. <helaoban>watup guix! question: which package provides 'man'? <chrislck_>is guix's cuirass a possible drop-in replacement for travis? ***chrislck_ is now known as chrislck
<lfam_>It's not a "drop-in" in the sense that the configuration is not compatible <chrislck>maybe with a (yaml->g-expr "ci/travis.yaml") :) <lfam_>It also has less documentation, stack exchange questions, etc. I'd guess it would take more elbow grease <chrislck>would be nice if all these travis refugees could find asylum with guix <lfam_>Did something happen with Travis? <apteryx>has anyone tried producing debug symbols for glib? <apteryx>It depends of the operating-system definition <apteryx>the lightweight desktop is about 3 GiB IIRC. <apteryx>note that even if the base install is small, Guix requires relatively lots of disk capacity if you want to keep multiple profile generation in your history <ZombieChicken>which vary in size based on the difference between installs, right? <apteryx>it mostly vary based on the amount of package that were updated, either directly or through their dependencies <xelxebar>Can one use guix edit to view the source for services? <apteryx>ZombieChicken: for the bare-bones.tmlp 'guix size' says total: 1172.1 MiB <apteryx>that's gnu/system/examples/bare-bones.tmpl <xelxebar>Anyone here using qemu with a samba shared directory? <xelxebar>For some reason qemu isn't starting smbd for me :/ <ryanprior>I just updated two git-fetch origin packages using emacs-git-packaging and it was smooth as buttah. <ryanprior>I'm very pleased with M-x guix-packaging-hash-git <apteryx>is this one of your project? (emacs-git-packaging) ? ***benny_ is now known as benny
<apteryx>xelxebar: is your samba share working well otherwise? <xelxebar>apteryx: Just using samba backend to share a host dir with guest. <xelxebar>Pretty sure there's no need to have samba running on the host beforehand; qemu is supposted to automatically start smbd, no? <xelxebar>Doing something like this: qemu-system-x86_64 -netdev user,id=net0,smb=/path/to/share ... <xelxebar>Of course, samba is also installed as well. <apteryx>I don't see anything in the docs :-/ (info qemu) <xelxebar>apteryx: Looking at the qemu source, it looks like the smbd command ends up as something like 'smbd -l /tmp/qemu-smb.XXXXXX/ -s /tmp/qemu-smb.XXXXXX/smb.conf' <apteryx>it's a bit confusing, it say it is a 'built-in SMB server', but also that 'Note that a SAMBA server must be installed on the host OS'. <xelxebar>Yes, that is confusing, but you do have to have samba installed. <xelxebar>I have no idea. This is the first time I have used it. <xelxebar>However... starting qemu, that /tmp/qemu-smb.XXXXXX directory does get created, so I tried manually running the above smbd command. <apteryx>one gotcha with our Samba is that it expects some directory hierdarchy to exist under /var/run, so you'll have to manually create a couple directories there <xelxebar>It exists silently with a non-zero status <apteryx>We'd need a service definition to take care of it <apteryx>When I tried it complained about it, so it was easy to know. <apteryx>there's a switch to keep it in the foreground <xelxebar>My last pull was a couple days ago. Could that possibly make a difference? <xelxebar>apteryx: Would you like to see a copy of the smb.conf that qemu generates? <xelxebar>apteryx: With the -S switch: exit_daemon: daemon failed to start: Failed to create session, error code 1 <apteryx>OK, I got it running: daemon_ready: daemon 'smbd' finished starting up and ready to serve connections <apteryx>I had error 1 earlier with "Failed to create /var/log/samba/cores for user 1000 with mode 0700\nUnable to setup corepath for smbd: File exists" <apteryx>I had created that file manually I guess but it was owned by root so I had to use 'sudo'. <xelxebar>Well, in my case the above "faired to start" error is all I get. <xelxebar>You will need to create the /tmp/qemu-smb.NPJST0 directory of course <xelxebar>Well, at least we have a reproducible problem. <apteryx>strace just told me: [pid 7585] write(1, "bind failed on port 445 socket_addr = 127.0.0.1.\n", 49bind failed on port 445 socket_addr = 127.0.0.1. <apteryx>[pid 7585] write(1, "Error = Permission denied\n", 26Error = Permission denied <xelxebar>Oh. I always forget about strace. Port 445 is priviledged, right? <apteryx>so that'd need to run as root or setuid <apteryx>perhaps QEMU is using a helper to launch it that should be setuid <apteryx>that'd need to be configured in your operating-system setuid-programs field <apteryx>hope that helps! Bed time for me :-) <xelxebar>Had to manually run as root after clearing out some files first :sigh: ***amfl_ is now known as amfl
***sneek_ is now known as sneek
<divoplade>Could someone edit guile-rdf in gnu/packages/guile-xyz.scm to add guile to the native inputs, so as to fix cross-compilation? <vits-test>xelxebar: for me elogind do not start any graphical login; elogind can be w/o all %desktop-services (on its own, at least). <divoplade>Well, it's the same for guile-jsonld in fact <divoplade>Wow, there are a lot of guile packages that don't have guile as a native input <xelxebar>vits-test: Hrm. At least in my case, putting (elogind-service) in my services caused some half-baked gui login manager to start <librem>hiya. I installed Guix on my Librem 15 v4 (pureboot) successfully. The problem is I can't boot into it. Here's the desktop.scm file i used https://qbin.io/piano-ethics-3uxh - nothing was installed into /boot, I only have the files of my other OSs there. How do I get it to boot? What more information would help resolve this issue? <librem>despite my system not using EFI at all? ***apteryx_ is now known as apteryx
<librem>Yeah, it's a Purism Librem, it uses Heads <vits-test>librem: IDK, but rekado also had troubles with Librem. <librem>rekado_ did you manage to solve it? <vits-test>librem: in mean time, are U sure fb21f40b-92ef-48b7-acbd-9590fa509a9b is equal to /dev/sda ? <xelxebar>librem: How far into the boot sequence do you get? <librem>I can list my boot entries, but it shows only the boot entires that are in /boot/grub/grub.cfg <librem>And I can boot another OS as per usual <librem>Ahah! i think i figured it. it installed grub to the guix root. /guix/boot/grub/grub.cfg <librem>And not the /boot partition on /dev/sda1 as I had thought it would. <vits-test>librem: if U mount /dev/sda1 to /boot of /guix (make backup)? <librem>I need all the boot files of all OSs in the same partition otherwise I'd have to reflash my bios to change OS <librem>the kernels and ramdisks i think <civodul>mothacehe: hi! i'm looking at what bavier[m]1 reported about the installer <civodul>a simple fix is to decrease the default #:listbox-height <civodul>but i wonder if Newt allows us to have it scale as a function of the terminal size? <mothacehe>civodul: hey! yes I've been thinking about it but I would prefer to use a ratio relative to the terminal size. <civodul>otherwise we can use (guix build syscalls) <mothacehe>oh that's already available in (gnu installer newt utils) screen-columns and screen-rows parameters. <mothacehe>that are used to scale config page and error page dimensions <civodul>mothacehe: so we could change #:listbox-height to (max 5 (- (screen-rows) 10)), say? <civodul>still an approximation because we don't know how much space the text above uses <civodul>i can let you handle that if you're already looking at it! <Fenlair>just saw the openwifi talk at fosdem, man would it be cool if that got some traction :) <mothacehe>civodul: sure, I'll try to propose something today :) <chrislck>guix could offer asylum to travis refugees... would be a nice boost <chrislck>it needs a rosettacode for travis / circle-ci to cuirass format <civodul>chrislck: Travis-CI is primarily a service though, isn't it? <mbakke>it looks like the ungoogled-chromium build from 30+ hours ago has gotten "stuck" on the CI <mbakke>trying to build it directly results in "Waiting for locks or build slots", but none of the CI builders are actually running it. <civodul>mbakke: it's being built from by hacky script! <civodul>there's another one being built by *your* hacky script <civodul>fundamentally Cuirass can never successfully build it because it takes too much time <civodul>we would need to increase the absolute timeout globally, which doesn't seem like a great idea <mbakke>civodul: when it's finished, can you test whether the hardware acceleration fix from fddc87063231f8f9aa22bbbc5bca4a46b9bbf004 made a difference wrt #44417 ? <mbakke>perhaps Cuirass should start taking the "timeout" property into account? <leoprikler>civodul: i think the comment about travis-ci might be w.r.t. configuration files <leoprikler>Gitlab CI, Travis etc. all use some variant of yaml, where as Cuirass is fully Scheme IIUC. <civodul>re timeout, the problem is that it's a per-session setting, via set-build-options <civodul>so you'd set the timeout for the whole Cuirass session, not just for this one build <civodul>Hydra didn't have this problem because it created one session per build <civodul>but in turns that could led to poor scheduling, or (put differently) the need for scheduling above the daemon <Fenlair>if I have multiple machines synced with nfs and I would want guix on them to install software on all machines simulatanious, would I just bind mount /gnu to an nfs share? and what would I do with /var/guix? Usually I wouldn't want to have /var shared :/ <civodul>hmm C-x v l & co. are broken due to the latest .dir-locals.el changes, is that right? <mothacehe>Do you know an easy way to test changes in guix-daemon invoked scripts such as "offload" or "subtitute"? <civodul>i run "sudo -E ./pre-inst-env guix-daemon ..." <nefix>hello! I've packaged kind :) I'll try to contribute to the source code, but I doubt I'll succeed :S <civodul>that can look intimidating at first but hopefully it's nothing insurmountable <mothacehe>civodul: thanks, so do I but it refuses to run a new script I added in (guix scripts ...) <civodul>mothacehe: with "no code for module" or...? <chrislck>civodul sure travis needs hardware. but imo a recipe to create cuirass config from travis will attract ppl <mothacehe>hehe it runs /home/mathieu/guix/scripts/guix ... which is ok, but it fails with "command not found", well I'll see that after lunch. <chrislck>+ recipe to set up guix in any cheap vps host <Fenlair>nefix: I'm trying to contribute my package of remmina as well and I made some mistakes on the way, but everyone here is super nice and helpful! <nckx>Top of the morning, Guix. <nckx>Guix has made me physically incapable of typing samba. It *always* comes out as sambda. <nckx>I wish to lodge a complaint. <vits-test>#meetoo, cannot type inet-pton, always inet-pron. <nckx>Let's combine our lawsuits and split the $. <vits-test>there may be another victims, i didn't hear anything from str1ngs for a few days.. He did prepared some releases for Guix. <nckx>When I run the system test suite I get: hint: gnu/tests/monitoring.scm:314:19: zabbix-front-end-configuration: Consider using `db-secret-file' instead of `db-password' for better security. <nckx>Is that relevant for tests? If not, can it be silenced? *nckx .oO Fine, looks trivial enough to port over lunch... <sneek>spk121 was last seen in #guix 12 minutes and 42 seconds ago, saying: .. <civodul>nckx: this hint is obviously harmless but kinda annoying <nckx>(It wasn't actually trivial because it can't be a gexp, which I guess is supposed to enforce ‘security’, but I can't wait for a less icky real secrets service.) <nckx>Until then I guess it can just be ignored. <civodul>yeah, i think db-password exists only for test purposes <nckx>I'd like to change the description in the manual because it's IMO just wrong (the contents are not appended), but I guess the manual is frozen now? <civodul>it is frozen, but maybe you can post it to guix-devel so we weigh the pros and cons ***terpri_ is now known as terpri
<apteryx>civodul: re .dir-locals.el is it? If you press '!' to accept the snippets, I think it works as intended, I think. It's when we refuse the new snippets that a problem was found by cbaines. <apteryx>civodul: what is frozen is the version-1.2.0 branch only, no? Which leaves master open for changes, correct? <apteryx>nckx: I have the same problem about 'sambda'. Why is that? :-) <apteryx>xelxebar: the ELF under /gnu/store/vax19d5i30qnq7bjwqshbgd78606k7m8-qemu-5.1.0/libexec can be made setuid root, but unfortunately the thing that launches samba is just a script, which can't (for security reason). <apteryx>xelxebar: I just read that if you must run QEMU as root, you should use the ‘-runas $USER’ so that it drop root privileges, switching back to $USER before starting guest execution. <nckx>apteryx: <branch> Oh, I wasn't aware of The Branching. <apteryx>civodul: I've tested your patch without any change this time, and couldn't see the strace output changing when recreating the ~/.guix-profile symlink :-/. <nckx>If confirmed my mail is noise and may be ignored. <apteryx>Oh, a fix I've been postponing because of the broken mpd system test is a too eager evaluation that causes /etc/passwd to be parsed for a missing user: to reproduce: 'guix system search mpd' <nckx>Yeah I just ran into that. <nckx>apteryx: How did you do so? The test log didn't contain the clear error message that ‘guix system search mpd’ produces IIRC. <civodul>apteryx: yup, "master" is open to changes, fortunately <civodul>the interesting thing is that it defends roughly the same choices that Guix made <apteryx>nckx: to clarify, this fixes just 'guix system searh mpd', not the system test. <apteryx>I don't currently have a clue about the later <civodul>apteryx: re .dir-locals, i'm not sure if i ever refused snippets, but it'd be great to get C-x v l back anyhow :-) <nckx>apteryx: LGTM and a clear improvement. civodul, any gexp subtleties to watch out for there? <apteryx>civodul: hmm. If you open any file under your guix checkout, do you get the prompt to accept the directory variables? <civodul>it's broken also for files outside my guix checkout <nckx>apteryx: The system test is just ‘connection refused’ in the VM IIRC. Didn't really look into it since I'm trying to break file system tests today, not mpd... <apteryx>what if you start a fresh instance of emacs and visit a guix source? <civodul>that getpw call in mpd-service-type is terrible, great that you found out about it *apteryx tries to reproduce <civodul>but the custom-set-variables block in ~/.emacs may have stuff about it <civodul>yeah it has things like (setq guix-directory ...) <civodul>apteryx: so it seems that resetting safe-local-variable-values, then visiting a Guix file and accepting everything fixes it <civodul>well, except for files outside my Guix checkout :-/ <civodul>mbakke: ungoogled-chromium build failed: <civodul>ld: error: failed to open ./chrome: No space left on device <nckx>Did you forget to mount your external 4TB drive before building Chrome again? <apteryx>nckx: I just pushed the fix reviewed as 0c5d0c57d3 <mbakke>civodul: bah :-/ I guess we'll have to wait another 24 hours then. <civodul>test /gnu/store/ni9r2y26ddyjqnihvfv05rsvgzzz43bv-gui-installed-desktop-os-encrypted.drv fails: somehow, it seems the passphrase is never entered when booting the installed system <civodul>mbakke: yeah, it's becoming increasingly harder to get it built <civodul>you can check what you think of the GC parameters on build nodes <civodul>we could always GC more if needed... <civodul>oh the gui-installed-desktop-os-encrypted test above just passed <apteryx>civodul: hmm when you opened a file in your Guix checkout, was it a .scm or something else? <civodul>could it be that OCR is non-deterministic and thus? <apteryx>I can't seem to reproduce, but I have (setq geiser-guile-load-path (list (expand-file-name "~/src/guix") (expand-file-name "~/src/shepherd"))) in my ~/.emacs as global defaults *apteryx tries without that <nefix>hello! Could someone link me a config example of emacs for Guix developement? I'm new at emacs and I can't figure out how to use the "guix plugin" and the "paredit plugin" toghether. Also the identation stuff, headers etc. Thank you! :D <apteryx>civodul: I still can't reproduce in a freshly launched emacs, without the global geiser-guile-load-path in my .emacs, whether I accept the snippets or not <apteryx>you cou please try moving the two 'eval' from under (nil . (... to under (scheme-mode . (... ? I think maav reported it worked as a workaround <apteryx>Are there any other Emacs users out there that are having issues with the new .dir-locals used at the root of the guix checkout? <luis-felipe>sneek: Later tell maav: How about using "Vistazo" for "Overview"? <apteryx>civodul: another thing to try: launch emacs in a pure environment where no extra emacs packages are installed, to make sure it's not a clash. <civodul>it's weird that these settings are in effect outside the Guix directory <civodul>oh but that's because default-directory has nothing to do with the CWD, no? <apteryx>if I do 'M-x cd ...' it'll update default-directory <civodul>no, in the backtrace above, default-directory = ~/src/guix, even though the file lives elsewhere <apteryx>Wonder why I can't reproduce here... <apteryx>oh, I had this in my .emacs somewhere: (setq default-directory "~/src/guix"), that must explain why. *apteryx retries with emacs -q <nckx>apteryx: Did you push it to master as well? <apteryx>I was thinking we'll merge 1.2.0 back into master when it's done <apteryx>civodul: still can't reproduce, even with 'emacs -q'... <civodul>apteryx: anyway, .dir-locals.el is supposed to apply only to the Guix checkout; why is it even applying here? <apteryx>It seems to be an oddity of the definition living under the catchall nil key <apteryx>if you move the defs under scheme-mode it might stop behaving that way <apteryx>OK, I've read back what maav mentioned yesterday: "it's quite weird as the eval somehow appears in file-local-variables-alist" <apteryx>They described repro steps like: (fresh emacs with geiser+magit -> open guix file -> ! -> Start magit -> start geiser session -> M-. -> M-. -> open file without dir-locals.el -> C-x v =) <apteryx>so perhaps it has to do with Geiser and or Magit doing something funny. <apteryx>I still cannot reproduce with that reproducer and 'emacs -q'. Crazy. <apteryx>Don't think it matters, but my EMACSLOADPATH looks like $HOME/.guix-profile/share/emacs/site-lisp:$HOME/.guix-profile/share/emacs/27.1/lisp <nly>can i install a package for different architecture? <nly>> guix install $(guix build klisp --system=i686-linux) <roptat>guix install klips --system=i686-linux <nly>guix install: error: system=i686-linux: unrecognized option <roptat>hm... I though that was possible <roptat>weird, guix package accepts the -s argument, but doesn't do anything <roptat>ah because it means search, not system ^^' <roptat>installing a store path should work, but you're not going to have any search path spec for instance <roptat>no it's correct, guix package -h doesn't show any --system option <roptat>like you said, guix install $(guix build hello -s i686-linux) seems to work <roptat>but they're the same for guix build <vits-test>guix package -s i686-linux -i nano --dry-run # good <vits-test>guix package --system=i686-linux -i nano --dry-run <vits-test>-| guix package: error: system=i686-linux: unrecognized option <civodul>we now have 91% system tests succeeding <roptat>yeah, because I'm proposing to use guix build, not guix install <roptat>run guix build -s i686-linux hello, you get a store path <roptat>then run guix install /gnu/store/... <roptat>are you using a translation? maybe it's out of sync <roptat>because guix package -h says "-s, --search=REGEXP search in synopsis and description using REGEXP" <vits-test>roptat: no, i merely mistaken build --help and package --help, sorry <vits-test>nly: i hope U didn't missed solution by roptat `guix install $(guix build hello -s i686-linux)` due to my spam. <roptat>which was actually your solution initially ^^' ***bkv is now known as bqv
***jonsger1 is now known as jonsger
<vits-test>sneek tell Grinch: Guix isn't all about evaluation. <sneek>Grinch:, vits-test says: Guix isn't all about evaluation. <civodul>it's funny that the wrong link doesn't lead to 404 <zzappie>Hey guixers! What is the best practice packaging a C project that carries several submodules (some already in Guix), wgets stuff all over the place and copies bunch of header only libraries to the src tree during build? :) <zzappie>is it normal to include ,(origin (method ...) (uri ... (sha256 (base32 ...)))) in inputs? or it's beter to define some-package-for-another-package and include them? <botsnack>I lost my connection so freenode thinks my #1 nickname is still in use! <botsnack>There. Just needed to wait for the timeout :) ***botsnack is now known as divoplade
<vits-test>sneek: did U seen..? It walks, speaks, changes shapes, and smile upon us! <roptat>you managed botsnack transmutation! *vits-test sneek remain silent, shocked deeply by those evaluations or reality. BOO! <civodul>zzappie: this practice is commonly referred to as "bundling" and is frowned upon in Guixland :-) <civodul>it has several problems, one of which being that security issues can go undetected <civodul>so we usually "unbundle" software by having the package refer to existing packages <bavier[m]1>I want to try out these patch-based vcs systems, like pijul, anu, darcs, but their implementations all feel so gross to me. <zzappie>civodul: Thanks for clarification! Cause I've seen both examples in guix packages *zzappie finds amusing how you manage find new ways to make fun of sneek <apteryx>is it possible to start a Guix VM with -nographic on a remote SSH machine without X forwarding? It shows a completely black screen. <civodul>apteryx: i think it should work and not show anything rather than a black screen <civodul>if you want to see console output, you have to pass "console=ttyS0" to the kernel args (-append) and "-serial stdio" to QEMU <civodul>apteryx: BTW, we need to settle on a solution for update-guix-package :-) <civodul>my preference would go to something like i posted a few days ago, not shelling out to git, but if you feel strongly about it, i'm open to other options <apteryx>civodul: about update-guix-package, yes <apteryx>I intended to do so but got stumped not being able to 'make release' :-) <civodul>apteryx: not being able to "make release" because of update-guix-package or because of other things? <civodul>i know that "make assert-binaries-available" is currently failing <civodul>i manually running "guix build -m release-manifest.scm" on berlin to address that... <apteryx>at this point if I run 'make release' on the version-1.2.0 is it supposed to get as far as failing because of update-guix-package? <civodul>yeah i'll retry once "make assert-binaries-available" is happy <civodul>you can remove the dependency on that target though if you want to give it a try <apteryx>I tried: '.../run-vm.sh -m 3000 -nic user,model=virtio-net-pci,hostfwd=tcp::11022-:22 -serial stdio -append console=ttyS0 -nographic' but it returns '(qemu) qemu-system-x86_64: -serial stdio: cannot use stdio by multiple character devices' <apteryx>I think -nographic already redirects serial to stdio *apteryx reads 'info qemu' *jonsger did that enough today, it's just so many parameters... <apteryx>removing the '-serial stdio' allowed to proceed further, but it left me at the Guile REPL because aparently 'no boot file passed via '--load'' <apteryx>jonsger: I found GNOME Boxes pretty nice... perhaps 'guix system vm' could have a switch to output a script or file definition that could be readily loadable in it. <apteryx>how can I use bournish at the early boot Guile REPL? I tried: ,import (guix build bournish) then ,L bournish <civodul>though actually i think the REPL starts in Bournish mode already, no? <civodul>at least when it starts as a result of an fsck failure or similar <apteryx>(current-language) says scheme; Got dropped to REPL because "no boot file passed via '--load'" when using -nographic <apteryx>when using '-nographic -append console=ttyS0' <apteryx>seems like my use of -append is broken :-) /proc/cmdline contains just 'console=ttyS0' <apteryx>I need to find the -reappend option ;-) <apteryx>better just copy the vm.sh locally and hack it up <civodul>ah yes, you definitely need to keep the "--load" bit :-) <civodul>i sometimes "cat run-vm.sh" and add console=ttyS0 + -serial stdio in there <luis-felipe>sneek: Later tell maav: In the Overview page, how about "Guix proporciona actualizaciones y reversiones transaccionales, gestión de paquetes sin privilegios, y más." <apteryx>would be a useful QEMU contrib to have multiple -append appended ;-) <luis-felipe>sneek: Later tell maav: Besides the "vídeo" problem, what I find peculiar is the use of feminine nouns and pronouns as neutrals. I'm courious about this choice. Is that really used in Europe? <luis-felipe>sneek: Later tell maav: Also, in "configuración del sistema al completo", "al completo" is new to me, would "configuración entera/completa/total del sistema" work around there? <apteryx>civodul: I've got debug symbols and gdb on gnome-shell / glib in a GNOME VM with your patch. <apteryx>Now I need to learn GDB ;-) I thought I could 'break desktop_file_dirs_lock' then it 'run', but it doesn't seem to get it. <apteryx>but that'd be a library call anyway, IIUC. <luis-felipe>Reading the website in two languages I find it a little bit difficult again to tell that Guix and the Guix System are two things... <nckx>What does ‘rewriting hashes in `%1%'; cross fingers’ actually _mean_? I thought it was grafts. It's not grafts. <nckx>luis-felipe: Perhaps that's deliberate. They're not really ‘two things’. <luis-felipe>Well, they seem to be when you have separate instructions to install both. <apteryx>another low hanging fruit for the release I think is the fix for 'gnome-maps' package that's on bug-guix; currently it's unusable on GNOME. <luis-felipe>GNU Guix, the package manager that is more than that, and the Guix System, the GNU operating system distributed by GNU Guix. <luis-felipe>Or one has to ask, "are you using the Guix System or Guix on a foreign distro?" <nckx>(sda1): emergency read only <civodul>apteryx: ah, i'm not sure whether gnome-shell forks or what it does exactly <civodul>but now we should do the "real" test: run a vm-image/disk-image where we can actually type "guix install foo" <apteryx>both options were failing last I tried, that's why I stuck to 'guix system vm' so far <vagrantc>i haven't tested it yet ... will it return #f ? <vagrantc>hah, apparently not: guix/tests.scm:446:1: missing closing parenthesis <vagrantc>ah, i can easily test these in-place rather than my convoluted build processes *vagrantc struggles with an if statement in guile :) <civodul>vagrantc: you could write (if (getenv "GUIX_DISABLE_NETWORK_TESTS") #f (false-if-exception ...)) *vagrantc should check irc more often <vagrantc>civodul: but that will still return true if GUIX_DISABLE_NETWORK_TESTS=false ? <cbaines>Something like the following might work if you want to check the value (if (and=> (getenv "GUIX_DISABLE_NETWORK_TESTS") (lambda (val) (string=? val "true"))) #f ...) <sneek>Welcome back cbaines, you have 1 message! <sneek>cbaines, civodul says: congrats on the guile-sqlite bug hunt! <vagrantc>might not be worth the extra compliation, if the convention is to simply use set/unset for boolean <vagrantc>though i've never been fond of that implicit pattern <cbaines>Thanks civodul ! That reminds me, I should probably stop running the coordinator in a loop now it hopefully doesn't segfault... <cbaines>I've also just gone over the derivation ordered allocator, and rather than ~15 minutes to allocate builds, it now completes in 15 seconds! <cbaines>Which should greatly help when building things one after the other <apteryx>are glib for changes staging or core-updates usually? <civodul>cbaines: yeah that sounds pretty nice! <civodul>apteryx: per the guidelines in the manual it may have to be core-updates (6K dependents) <apteryx> how did you find out? guix refresh -l glib mentions about 12 packages <civodul>apteryx: guix refresh -l -e '(@ (gnu packages glib) glib)' <ngz>Hello. I'm encountering Rust packaging oddities. I want to build rust-strum, which has rust-strum-macros as both inputs and development inputs. Unfortunately rust-strum-macros has also rust-strum as development input. How am I supposed to proceed? <cbaines>ngz, the #:cargo-... arguments don't have the same loop issues as package inputs, so it should be OK <cbaines>I think the #:cargo-... bits actually use the package source, rather than outputs from the package, which is why you don't get loops <ngz>OK. I admit I didn't try. Thank you. <civodul>if even the die-hard elispers among us end up packaging Rust code, i think we can say there's a Rust pandemic <vagrantc>does it make more sense for the tests/*.sh to source a common set of functions (currently i have one to propose) or get the return value from a script and act on that? <civodul>vagrantc: i'd say the former, but i think there's little code duplication so far, no? <ngz>civodul: Well, each time I try to package Rust code, I fail miserably, so I go back to the comfort and simplicity of Elisp. Packaging npm stuff may be hellish, but Rust is close to purgatory. <apteryx>I guess vm-image be rewritten in terms of what disk-image is now doing (using genimage to generate the image instead of spawing a QEMU VM, which is slow, IIUC) <cbaines>mroh, I have a working package for fractal, but the commits/patches are a mess <cbaines>mroh, I've pushed the mess now https://git.cbaines.net/guix/log/?h=add-fractal Quite a few packages/commits are redundant I think as I flip-flopped lots on the versions. There are some large groups of rust packages, like the gstreamer stuff and sourceview4 which would be good to package in preparation for fractal. <vagrantc>civodul: there's currently only one function ... so not much code duplication. <apteryx>civodul: oh, did you have a look at the mpd service? <apteryx>no! I'm trying to go to the bottom of the GNOME Shell .desktop refresh thing. <apteryx>so far 16 minutes into the 'guix system vm-image' making on a very fast machine. <mroh>cbaines: thank you very much! Will take a look. <cbaines>what's bringing berlin to it's knees? <civodul>we're really paying a high price for that <civodul>i fixed it yesterday but it'll be some time before we're done building the non-offloadable ones <civodul>this time we can't even fetch substitutes from it :-/ <cbaines>I saw your stuff about fixing the derivations for system tests being flexible, which is cool! <civodul>we'd been having this kind of issue for too long :-) <civodul>an interesting side effect of .drv sorting in Worker::run is that all the partition.img.drv get built at once <civodul>and then all the disk-image.drv, etc. <civodul>so you suddendly get an i/o storm like never <cbaines>was the drv sorting introduced to resolve the locking issues? <apteryx>OK, I'll try to tackle the '(string-append "tmp-root" #f)' thing happening for disk-image <janneke>oh, not offloading images sounded like such a good idea (for my use case) <janneke>interesting mistake to overlook it, i didn't see it coming... <vagrantc>oh, seeing the pine64+ image, i could probably create a pinebook-desktop image pretty easily <cbaines>divoplade, looking at line 145 in guix/scripts/system/reconfigure.scm, it suggests that services in your operating-system record may be #f? <cbaines>actually, maybe not, I'm not sure anymore what services is in this context <civodul>apteryx: great, that one is annoying! <cbaines>divoplade, second try, it looks like reconfigure has failed to determine the live services on your system <civodul>janneke: yeah it does sound like a good idea in the general case, but it's a bad idea at least in this particular case <divoplade>cbaines, so it's the same error if I commented out all my services <divoplade>cbaines, herd status reads: herd: premature end-of-file while talking to shepherd <cbaines>divoplade, yeah, my first theory was wrong. The reconfigure process does stuff with the services you're currently running, and some of that code is failing <divoplade>Is there a solution that does not involve rebooting? <civodul>divoplade: i think the reconfigure backtrace you show is the consequence, not the cause of shepherd not responding <civodul>as for why it's not responding, no idea how that could happen <civodul>maybe it's not select(2)ing on its socket? <divoplade># guix environment --ad-hoc strace -- strace -p 1 -s 200 <mroh>cbaines: nice, ty! Currently packaging a lot of matrix stuff... <apteryx>janneke: yeah, not offloading images is a great idea, except for the official ones, I guess. <apteryx>(from my opinionated user perspective, anyway :-)) <apteryx>civodul: I'm confused, the glib patch you made seemed to work when using a directly modified glib, but not for the replaced (grafted) version... Are there gotchas to look for when building multiple versions (just changing a patch file on the replacement) of a grafted package? <civodul>apteryx: hmm no, nothing special, you can add the replacement as with the Guix patch i sent and it should be fine <jeko>what can I do when I encounter conflict because of package dependancies with different versions ? <jeko>(guile-json in both artanis@0.4.1 and guix@1.1.0-31.1c6d985) <civodul>jeko: normally you get a hint as to what you can do <civodul>in this case, it may be that you just can't have both artanis and guix in the same profile <civodul>because they propagate different versions of guile-json <jeko>civodul: alright so I can forget the vm with artanis in the package list haha thank you. will figure a way out