IRC channel logs


back to list of logs

<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>do it!
<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>./pre-inst-env guix build guix-tarball
<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...
<terramorpha>Hi everyone, do alternative subtitute servers exist ? I find the default mirror to be quite slow. If so, how to I add it ? The docs online explain how to add a key(, but I couldn't find a list of alternative mirrors and their public key.
<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"? ERROR: Dependency "gstreamer-player-1.0" not found, tried pkgconfig
<sneek>mroh, you have 1 message!
<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.
<mroh>sneek: botsnack.
<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'?
<roptat>helaoban, man-db I think
<helaoban>roptat: merci.
<chrislck_>is guix's cuirass a possible drop-in replacement for travis?
***chrislck_ is now known as chrislck
<lfam_>Hi chrislck
<lfam_>It's not
<chrislck>Ok :)
<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
<lfam_>There's an idea :)
<chrislck>(not being rude, gtg rsn)!!
<lfam_>There will probably be some talks about it, or related subjects, at our upcoming virtual conference, the Guix Days <>
<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>when I tried I get:
<apteryx>ah, the debug files are read-only
<ZombieChicken>Hello. How big is a basic guixSd install?
<apteryx>It depends of the operating-system definition
<ZombieChicken>For a standard minimal install?
<apteryx>the lightweight desktop is about 3 GiB IIRC.
<ZombieChicken>including the tree and everything?
<apteryx>let me check for bare-bones.tmpl
<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>(I know almost nothing about samba)
<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: Search for "smb="
<apteryx>oh indeed!
<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.
<apteryx>did it stop working recently?
<apteryx>I updated Samba recently.
<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
<xelxebar>What directories should I create?
<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.
<xelxebar>My invocation is completely silent
<apteryx>it's probably forking
<apteryx>there's a switch to keep it in the foreground
<xelxebar>Yeah, -F
<xelxebar>Same thing. Exit code is 1.
<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?
<apteryx>try with -S too
<xelxebar>I edited out personal info
<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>not with your config though
<apteryx>I ran it as root
<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>Can you reproduce with that config?
<xelxebar>You will need to create the /tmp/qemu-smb.NPJST0 directory of course
<apteryx>yes I could reproduce
<xelxebar>Well, at least we have a reproducible problem.
<xelxebar>Thanks for checking.
<xelxebar>Any idea where the issue might lie?
<apteryx>strace just told me: [pid 7585] write(1, "bind failed on port 445 socket_addr =\n", 49bind failed on port 445 socket_addr =
<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>apteryx: Nooo, don't go! :(((
<xelxebar>Even as setuid it fails :/
<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>Hello :)
<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?
<divoplade>Or should I open a bug for that?
<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 - 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?
<vits-test>librem: try use grub-efi-bootloader
<librem>despite my system not using EFI at all?
<vits-test>no efi? ok
***apteryx_ is now known as apteryx
<librem>Yeah, it's a Purism Librem, it uses Heads
<civodul>Hello Guix!
<janneke>hello civodul
<divoplade>Hello :)
<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 ?
<librem>yes, sda1
<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
<vits-test>librem: like /boot/grub/archlinux.cfg ?
<librem>the kernels and ramdisks i think
<librem>bbs testing
<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>is there a way to do that?
<civodul>otherwise we can use (guix build syscalls)
<mothacehe>there's a newtGetScreenSize
<mothacehe>that is wrapped by "screen-size"
<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
<mothacehe>I guess we "just" need to generalize that.
<Fenlair>hi all :)
<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>but maybe it's good enough?
<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 :)
<civodul>mothacehe: awesome, thanks :-)
<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?
<civodul>like actual hardware
<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.
<mbakke>lots of other jobs that are not making progress either:
<civodul>mbakke: it's being built from by hacky script!
<mbakke>civodul: oh, "good" :-)
<civodul>there's another one being built by *your* hacky script
<civodul>it's hackfest in there
<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>mbakke: i can give it a shot
<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>Fenlair: check out
<Fenlair>wow thank you :D
<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>mothacehe: ↑
<civodul>nefix: hi! never doubt!
<civodul>as with projects of this size, there are guidelines:
<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...?
<civodul>it's most likely a path issue
<civodul>strace! :-)
<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!
<nefix>I'll try then :D
<nefix>Also, I'm getting a cgroup error, which ends up here: I'm quite sure that that's not a really good fix, so if anyone knows a better way to do this, thanks!
<nckx>Top of the morning, Guix.
<chrislck>leoprikler civodul re:travis
<vits-test>nckx: o/
<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.
<vits-test>it's due to uncontrolled spammer was there.
<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>Obvious PTSD.
<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...
<vits-test>sneek: seen spk121
<sneek>spk121 was last seen in #guix 12 minutes and 42 seconds ago, saying: ..
<vits-test>sneek: botsnack
<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.
<apteryx>OK, I'll apply the fix to 1.2
<nckx>Thanks for debugging!
<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>interesting post:
<apteryx>nckx: this is the diff does it look good to you?
<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 :-)
<civodul>is there something i should do?
<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...
<civodul>and no, i don't get a prompt
<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
<civodul>apteryx: same: no prompt
*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>locate-dominating-file, etc.
<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
<apteryx>to the version-1.2.0 branch
<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...
<mbakke>will have a look later
<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?
<civodul>-and thus
<civodul>apteryx: .scm
<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.
<apteryx>for the record, the the safe-local-variable-values that gets populated when I accept the .dir-locals values in my custom-set-variables block look like:
<civodul>apteryx: this is the backtrace when visiting a non-Guix file:
<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>I think it does
<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
<civodul>hence the problem
<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>nckx: I haven't!
<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>I'm asking myself the same question
<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>ah no
<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
<vits-test>nly: maybe i686-linux is wrong?
<nly>roptat: nice, how?
<roptat>no it's correct, guix package -h doesn't show any --system option
<vits-test>nly: guix package -i should work
<roptat>like you said, guix install $(guix build hello -s i686-linux) seems to work
<vits-test>for me no :)
<vits-test>--system no
<vits-test>-s yes
<vits-test>tho it's a month old commit
<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>guix package -s mean --search
<roptat>run guix build -s i686-linux hello, you get a store path
<roptat>then run guix install /gnu/store/...
<vits-test>roptat: acc. to help, -s is system
<vits-test>but i believe U, as U seem right.
<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 ^^'
*nly thanks himself
<nly>хорош vits-test
***bkv is now known as bqv
*vits-test пригорает
***jonsger1 is now known as jonsger
<civodul>i don't get why we're not seeing any evaluation at
<vits-test>civodul: evaluation --> Grinch.
<vits-test>sneek tell Grinch: Guix isn't all about evaluation.
<sneek>Grinch:, vits-test says: Guix isn't all about evaluation.
<vits-test>sneek: botsnack
<g_bor[m]>civodul: I can see 3 evaluations here.
<g_bor[m]>your original link is misspelled
<civodul>g_bor[m]: d'oh, thanks!
<civodul>it's funny that the wrong link doesn't lead to 404
<g_bor[m]>maybe we should fix that...
<g_bor[m]>seems like a good easy bug candidate
<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?
<vits-test>sneek: charge, botsnack detected!
<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>what's your take on that?
<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
<vits-test>look, Kemerovo: a midnight vagrantc!
<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?
<apteryx>other things, let me try again
<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?
<apteryx>ah, just read your message above
<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: '.../ -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.
<jonsger>apteryx: would be a neat feature
<apteryx>how can I use bournish at the early boot Guile REPL? I tried: ,import (guix build bournish) then ,L bournish
<apteryx>it says 'no such language bournish'
<civodul>apteryx: try ",bournish" (IIRC)
<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>,bournish works, thanks.
<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 locally and hack it up
<civodul>ah yes, you definitely need to keep the "--load" bit :-)
<civodul>i sometimes "cat" 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."
<sneek>Got it.
<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?
<sneek>Will do.
<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?
<luis-felipe>sneek: botsnack bag
<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>I mean, it doesn't break.
<apteryx>follow-fork-mode is set to child
<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’.
*nckx briefly AFK.
<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
<nckx>Damn it.
<civodul>apteryx: ah, i'm not sure whether gnome-shell forks or what it does exactly
<civodul>that's why i found strace easier
<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>so, for disabling network tests ... does this look reasonable?
<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>civodul: thanks! :)
*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
<vagrantc>that sounds like a huge improvement :)
<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
<leoprikler>that's probably glib-with-documentation tho
<leoprikler>you need -e '(@ (gnu packages glib) glib)'
<civodul>apteryx: guix refresh -l -e '(@ (gnu packages glib) glib)'
<civodul>leoprikler is right
<apteryx>thank you
<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.
<mroh>ngz: yes, indeed! I'd tried packageing yesterday and everythig was easy until I came to the rust part...
<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)
<apteryx>could be*
<cbaines>mroh, I have a working package for fractal, but the commits/patches are a mess
<mroh>cbaines: oh, nice!
<civodul>ngz: heheh :-)
<civodul>uh the mpd service was badly broken
<cbaines>mroh, I've pushed the mess now 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?
<civodul>apteryx: i'm looking at it
<civodul>are you doing it as well? :-)
<apteryx>OK! neat
<apteryx>no! I'm trying to go to the bottom of the GNOME Shell .desktop refresh thing.
<civodul>heh good
<apteryx>so far 16 minutes into the 'guix system vm-image' making on a very fast machine.
<civodul>and berlin is on its knees :-/
<mroh>cbaines: thank you very much! Will take a look.
<cbaines>what's bringing berlin to it's knees?
<civodul>non-offloading of image building
<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>ah yes!
<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
<cbaines>I had my eye on system test derivations, because I think there's still some issues matching up what has and what builds, which I think might relate to
<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
<divoplade>Hello, I get a big scary backtrace when reconfiguring (it did not happen earlier in the day): do you know what is happening?
<divoplade>How can I debug it?
<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
<divoplade>I'm trying without the services
<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
<divoplade>That does not look good
<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?
<divoplade>I'm in a middle of an important computation
<civodul>anyone using mpd here?
<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?
<civodul>could you "strace -p 1 -s 200"?
<civodul>(i know, i know)
<divoplade># guix environment --ad-hoc strace -- strace -p 1 -s 200
<divoplade>strace: Process 1 attached
<divoplade>select(14, [3 10 13], [], [], NULL
<cbaines>mroh, I've now created to track packaging attempts for fractal
<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 think lfam uses mpd
<apteryx>sadly not currently here
<jeko>Hi Guixters !
<kozo[m]>jeko Yo
<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
<civodul>hi jeko!
<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
*civodul -> zZz
<jeko>civodul: alright so I can forget the vm with artanis in the package list haha thank you. will figure a way out