IRC channel logs

2021-11-30.log

back to list of logs

<attila_lendvai>yep, i'm already fooling around in qemu. now, how can i inspect a shepherd service (start, stop forms, etc)?
<vivien>I got GNOME builder to build again: https://issues.guix.gnu.org/52188
<attila_lendvai>i got to: herd eval root (slot-ref (car (lookup-services 'bee-mainnet-0)) 'start) but it didn't help much, because it's a scheme closure
<jlicht>attila_lendvai: what are you trying to do? It almost seems like you are using the shell to interact with the shepherd; why not use guile?
<jlicht>e.g. (begin (use-modules (gnu services herd)) (start-service 'bee-mainnet-0)) in a marionette-eval
<attila_lendvai>jlicht, i want to test my service in a qemu vm, because last night i killed my dev laptop GUI be `herd stop my-service` -- something went wrong.
<jlicht>ah, GUI stuff; good luck!
<attila_lendvai>jlicht, my start form is broken still, and my activation-service-type extension will be complex. i want to mess around in the VM to see what to code up in scheme.
<attila_lendvai>jlicht, this is a complex service that generates/starts multiple shepherd services
<jlicht>so ideally.. some kind of interactive marionette? Where on the host side, you can use e.g. geiser to feed forms and see stuff hapening on/in your QEMU vm?
<attila_lendvai>jlicht, it's not gui stuff. it just killed my gnome somehow.
<attila_lendvai>jlicht, yep, that sounds like something that would be userful
<jlicht>Perhaps some of the folks who worked on/with marionette know how to get it to talk to you; it does not seem to be a very complex backdoor REPL, looking at gnu/build/marionette.scm
<attila_lendvai>for now i'm making progress, and the resistance is not guix/shepherd, but setting up the actual app/config/env
<jlicht>gl!
<excalamus>Good evening, Guix
<guixy>By default the mpd service makes the mpd user with a home directory in /var/run. Shouldn't that be /var/lib?
<the_tubular>Is this a dumb idea : Give a fixed time where no packages can't be pushed to the guix repo so the farm has time to build everything and people can pull from it ?
<KE0VVT>oh dear
<sneek>KE0VVT, you have 1 message!
<sneek>KE0VVT, ArneBab says: if you install via guix, just call wisp.
<KE0VVT>ArneBab: https://wtf.roflcopter.fr/pics/uw3AuxYe/BMn56l5z.png
<attila_lendvai>i'm playing with `guix system vm myfile.scm`, and it stopped working and i have no idea why. i get into a guile repl, and prior to that: no boot file passed via '--load'. nothing changed in how i invoke the wm, only in my service, probably some error
<attila_lendvai>when i quit the repl: Kernel panic - not syncing: Attempted to kill init!
<attila_lendvai>i'm starting with: /gnu/store/[hash]-run-vm.sh -nographic -append console=ttyS0
<attila_lendvai>undo and diff to the rescue
***user3456_ is now known as user3456
<attila_lendvai>FTR, what led to this undecypherable error mode was that i used passwd:uid on a string in an activation-service-type extension (i should have called getpwnam)
<drakonis> https://sourcehut.org/blog/2021-11-29-announcing-the-chat.sr.ht-public-beta/ ah this is neat.
<drakonis>time to whip up a sourcehut service
<attila_lendvai>FTR, qemu -append *overrides* the earlier -append in the run-vm.sh script. (WTH, append overrides?)
<attila_lendvai>how can i increase the RAM for `guix system vm myfile.scm`?
<attila_lendvai>FTR, here override semantics is useful: $(./pre-inst-env guix system vm swarm.scm) -m 2048
<apteryx>attila_lendvai: yeah, got bidden by qemu's poor CLI ergonomics before too
<apteryx>this or -m1000 != -m 1000
<apteryx>bitten*
<apteryx>not to say that Guix's very own is perfect
<apteryx>not saying*
<attila_lendvai>ehh, that's rather unexpected!
*apteryx is cross-building rust 1.54 for i686-linux
<attila_lendvai>i'm looking for an invoke/quiet with setgid/setuid support. i shouldn't need to write my own fork for this...
<guixy>By default the mpd service makes the mpd user with a home directory in /var/run. Shouldn't that be /var/lib?
<attila_lendvai>it seemed like a good idea to use (invoke [...] . args) as an API, but it makes it totally unextendable
<ns12>When I install something using 'guix install', is it normal for Guix to download a dependency multiple times?
<ns12>For example, when I install litecli, Guix downloads cups-minimal, pango, and cairo twice during the install. Is that supposed to happen? Why can't Guix download only once?
<apteryx>it could be various versions, or variants of the same version
<apteryx>that's sometimes used for bootstrapping
<apteryx>if the hash is not the same, Guix isn't downloading the same thing multiple times, but different things.
<apteryx>if you want to review dependencies you can use tools like 'guix graph' or 'guix size'
<ns12>Both downloads of cups-minimal and cairo are for the same version: https://paste.debian.net/1221303/
<ns12>I don't understand why Guix has to download cups-minimal-2.3.3 twice.
<apteryx>seems to be it's just the way it's showing its progress?
<apteryx>are you using multiple daemon jobs?
<ns12>apteryx: How do I find out whether or not I am using multiple daemon jobs?
<ns12>Does using multiple build jobs cause the same dependency to be downloaded multiple times? How?
<apteryx>no, it's just the output
<apteryx>they are printed many times as the downloads progress
<apteryx>I think
<apteryx>sudo ps -eF | grep guix-daemon | grep max-jobs
<apteryx>if you haven't configured anything you won't see any match, which means your daemon is using 1 job
<apteryx>but even without multiple jobs, I think the same output can appear many times in the UI as the download progress
<apteryx>it's a limitation/problem in the UI where the build plan gets populated as the process occurs, and new items are being added to the list and the output refreshes, causing the same items to appear again
<apteryx>it doesn't mean they are *downloaded* multiple times; just printed
<ns12>apteryx: Thanks for explanation.
<apteryx>sneek: later tell ciodul it built! /gnu/store/gx035nyr0msd2zakphv111hjxd9xscy6-rust-i686-linux-1.54.0
<sneek>Got it.
<podiki[m]>nice! does it work?
<apteryx>not sure yet
<apteryx>seems the cross-compiler generated an ELF32 binary for cargo and rustfmt, but rustc itself is ELF64... retrying with some changes
<apteryx>also there'll need to be some top level syntax glue, similar to what was done for pkg-config or polkit
<apteryx>and I have interrogations about if graphes from different architectures can be combined in Guix (never tried before)
<zimoun>hi!
***wielaard is now known as mjw
<mothacehe>hey guix!
<sneek>mothacehe, you have 2 messages!
<sneek>mothacehe, nckx says: When (manually) restarting a CI build, would it be feasible to automatically restart all dependent packages that were marked as ‘dependency failed’ because of that package alone?
<sneek>mothacehe, nckx says: If that is already the case, it's not clear from the UI. A dependent (gnome-shell) remained ‘failed’ even when all dependencies became green. Maybe it was being rebuilt in the background though, I didn't wait around and manually restarted it.
<mothacehe>nckx: that's indeed the case, failed builds are automatically restarted when their dependencies are all successfully built
<mothacehe>but this is indeed not really advertised
<vivien>Hello :)
<ArneBab>KE0VVT: yikes — looks like something in the package does not work yet. Thank you!
<jpoiret>apteryx: did you try making slim depend on elogind in shepherd? i'm just worried that slim's getting too old for it to work properly
<ArneBab>KE0VVT: can you use (import (language wisp)) in guile?
<ArneBab>KE0VVT: guile -c '(import (language wisp))'
<vivien>I’m not sure I understand everything with the libsoup 2/3 duality on core-updates-frozen, so someone reviewing 52188 would help me greatly :)
<ArneBab>@all how can KE0VVT try guile-wisp release v1.0.6 with guix without us creating a new package?
<ArneBab>this is the source: https://hg.sr.ht/~arnebab/wisp/archive/v1.0.6.tar.gz
<ArneBab>the changeset is v1.0.6 (tagged)
<jpoiret>at a first glance, i'd say `guix shell --with-source=guile-wisp=https://hg.sr.ht/~arnebab/wisp/archive/v1.0.6.tar.gz guile-wisp`
<raghavgururajan>apteryx: Are you using linux-libre or linux-libre-lts in your config.scm? I am reading that 5GHz issue could be power management related.
<raghavgururajan>Hello Guix!
<rekado>ArneBab: is it okay to upgrade the Guix package? Or is this a pre-release?
<florhizome[m]>Can I sent patches from icedove? Or do I need an emacs mail setup ...
<florhizome[m]>i would like to set up notmuch ( I created a new mailadress that supports IMAP :D) sometime but I
<florhizome[m]>> <@florhizom:matrix.org> Can I sent patches from icedove? Or do I need an emacs mail setup ...
<florhizome[m]>> i would like to set up notmuch ( I created a new mailadress that supports IMAP :D) sometime but I
<florhizome[m]>* it would be good to just be able to start from icedove
<florhizome[m]>btw icedove looks pretty „fresh“, last time I installed thunderbird it went really hard on my cpu and the ui is much cleaner now
<florhizome[m]>I might just stick with it for a while like this^^
<efraim>I have tor failing on core-updates-frozen on aarch64 and powerpc
<efraim>doh, it's the same test which tails on i686
<zimoun>apteryx:, efraim: this <https://issues.guix.gnu.org/52186> fixes julia on i686. And a couple of julia-* require some fixes. I will send a v2 later today. I will remove a big red block on core-updates-frozen https://ci.guix.gnu.org/eval/49420/dashboard?system=i686-linux
<efraim>awesome
<rekado>the PHP tests on aarch64 are flakey.
<zimoun>rekado, PurpleSym: fix of GHC@8.10 for i686 on core-updates-frozen https://issues.guix.gnu.org/52198
<zimoun>this will remove some red block for core-updates-frozen https://ci.guix.gnu.org/eval/49420/dashboard?system=i686-linux
<zimoun>I do not have enough CPU power for rebuilding all ghc-*. So it could be nice if https://issues.guix.gnu.org/52198 is pushed as soons as possible and let CI points which are failing.
<PurpleSym>zimoun: I thought I fixed the builds for i686. Do we know why this test fails and did it succeed earlier? (I can’t find any earlier successful builds in cuirass3)
<zimoun>PurpleSym: I do not know. The test T14028 systematically fails. The patch trivially skip it for i686.
<zimoun>The test about Quasiquotation. Maybe, it uses something that has changed. Bisect is not an option with GHC. ;-)
<zimoun>PurpleSym: https://ci.guix.gnu.org/search?query=spec%3Amaster+system%3Ai686-linux+ghc-8.10.7
<PurpleSym>I’ll build GHC with your patch after lunch, zimoun. I’ve been bitten too many times by “trivial” changes like this :)
<zimoun>PurpleSym, yeah I agree. Me too. It took all this morning to be sure it correctly builds. :-) Thanks for taking care of GHC.
<zimoun>PurpleSym: ghc-8.10.7 succeeded on 17 nov https://ci.guix.gnu.org/build/1652397/details
<zimoun>then it fails on 21 nov. https://ci.guix.gnu.org/build/1689396/details
<liltechdude>Hello! It is possible to manage mail list with guix?
<liltechdude>on the server side of course (with OpenSMTPD)
<liltechdude>May be someone can share config with me
<PurpleSym>zimoun: But the first build in on master and the second on c-u-f.
<zimoun>PurpleSym, yes but I think Cuirass is lost with the merges «Merge branch 'master' into core-updates-frozen»
<zimoun>I do not know.
<apteryx>raghavgururajan: linux-libre
<PurpleSym>Okay, let me build GHC twice then. With and without the patch.
<raghavgururajan>Ok.
<apteryx>jpoiret: hello; I don't think it's because slim is too old; I haven't yet tried your suggestions (adding dbus or elogind as requirements to it, or even booting with gdm), but will do
<apteryx>(but yes, slim *is* old :-))
***Guest8167 is now known as chrislck
*chrislck has done $guix home reconfigure ~/guix-profile/home-manager.scm and regrets it bitterly
<jlicht>sneek: seen abcdw?
<sneek>I think I remember abcdw in #guix 12 days ago, saying: jlicht: hi!.
<nckx>mothacehe: OK, thanks.
<chrislck>anyone knows how to roll-back guix home beyond the initial generation? where's the original configuration saved at
<rekado>efraim: this time php built fine on aarch64
<rekado>I built it on grunewald; it previously failed three times on pankow.
<attila_lendvai>so, i can copy-paste into a qemu vm started by `guix system vm foo.scm` by copy-pasting the content of the run-vm.sh, and editing it to add console=ttyS0 to the -append line. this is rather cumbersome... is there a way to atomate this? i'm willing to write code, too.
<rekado>you could also just call run-vm.sh with extra arguments
<jlicht>I believe qemu's append overrides previous append-ed stuff
<jlicht>which might be a bit silly considering the name
<efraim>rekado: I assume that was on master then
<rekado>efraim: ah drat, you’re right
<rekado>I mixed up my cuirass browser tabs…
<attila_lendvai>rekado, yep, unfortunately -append overrides.
<attila_lendvai>not much help in #qemu, nor in websearches... :|
<rekado>but still: these builds are marked as failed on cuirass, so it doesn’t hurt to fix them :)
<attila_lendvai>if i were to add a CLI option to guix system vm to disable/enable qemu graphic mode... what would you call that?
<attila_lendvai>the scheme #:key argument is called graphic?
<attila_lendvai>oh well, #:graphic? #false still opens a separate qemu window (as opposed to using the terminal it was started in). i need to patch system-qemu-image/shared-store-script to also include -nographic, but... well, we'll see what the maintainers think about it. preliminary feedback is welcome!
<apteryx>attila_lendvai: the usual workaround is to copy that /gnu/store/...run-vm.sh script somewhere and edit it to your needs
<attila_lendvai>apteryx, that's what i was doing, but it's a serious slowdown in my cycle
<apteryx>not pretty, but gets the job done. a patch to qemu so that later args take precedence above earlier one, and an -append that truly appends would be great patches for QEMU in my opinion
<apteryx>(to upstream)
*attila_lendvai is patching guix system vm to properly propagate the #:graphic? option, and adding a CLI arg for it
<apteryx>OK!
<attila_lendvai>how about calling it --same-terminal or --same-tty? i need help with this.
<attila_lendvai>it will make guix system vm read/print into the starting terminal
<attila_lendvai>or maybe --no-graphic
<apteryx>zimoun: I'll look into it later if nobody beats me to it! Thank you :-)
<GuiGuiGuix>Hello, I'm trying to configure a remote printer with cups but failed either by using gnome-printer or cups admin :(
<GuiGuiGuix>the printer with gnome is well detected canon... but the address is null
<GuiGuiGuix>any idea ?
<nckx>attila_lendvai: Probably ☝ that.
<nckx>The latter.
<attila_lendvai>nckx, you mean --no-graphic, right? i also went with that, and it's working. i'm preparing the commit.
<nckx>GuiGuiGuix: How exactly are you adding the printer to the CUPS Web admin (let's ignore gnome-printer) and how does it fail? I don't quite understand what is null here.
<nckx>attila_lendvai: Yeah.
<nckx>My answer got delayed by little meddlesome paws.
<nckx>With little adorable claws.
<nckx>Ow.
<zimoun>apteryx, cool! Thanks. Wait v2 later today. :-) v2 will fix julia-* packages for i686.
<GuiGuiGuix>nckx: I try to access the admin cups portal either but does not work with root or current user
<nckx>But how exactly does it fail? Note that CUPS does not have a Web interface by default, so if you visit localhost:631 and just can't connect, you need to make sure you have ‘(web-interface? #t)’ in your cups-configuration.
<GuiGuiGuix>nckx: the web interface is well activated , I can access http://localhost:631/ but not http://localhost:631/admin
<nckx>Run ‘sudo touch /etc/cups/cupsd.conf’ and try again.
<nckx>I fixed such a bug but it might not be on master yet, or the fix was incomplete.
<GuiGuiGuix>nckc Thanks you save my day :-)
<nckx>😄
<nckx>This should fix that bug for good but it hasn't reached master yet: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=3b5297d975efd07e7819f671c14856fd0778870e
<GuiGuiGuix>this is my first week with guix with a new laptop so far except intellij and the printer everything works fine :D
<ss2>nckx: oh, thanks for pushing 892f1b7273d57b25940700877a02618fe826cc08, that allows inferiors in services.
<nckx>YW ss2, although it was a purely selfish act.
<nckx>Coincidentally also CUPS-related.
*apteryx tries the i686-linux cross-built rustc in a 32 bit VM
<roptat>GuiGuiGuix, intellij is hard to package, but at least I was able to run it by downloading the binary version. I had to create myself a shell with the dependencies, in a container so I could mount FHS locations from the profile
<roptat>that way, I can provide dependencies where it expects them to be
<apteryx>cross-compiled 'rustc --help' on 32-bit VM runs \o/
<apteryx>but cargo --help doesn't: /gnu/store/6fkn8fc0m642xlnbblv3026cpp4i2411-profile/bin/cargo: error while loading shared libraries: libz.so: wrong ELF class: ELFCLASS64
<attila_lendvai>can i trust guile's RANDOM for generating password?
<nckx>I wouldn't, but ask in #guile. The seeding example is explicitly ‘for non-security-critical applications’. It never mentions what security-critical ones should do…
<attila_lendvai>damn. i have a command that i'm unable to run in herd (but it runs fine in guix repl). "< /dev/urandom tr -dc _A-Z-a-z-0-9 2> /dev/null | head -c32 >password-file". in herd arcivation form the system call returns 2, and i have no clue why. i'm replacing the tools with the full store path.
<attila_lendvai>i guess i should forget guile's random. it straight out starts up with the same seed every time, and "To seed the random state in a sensible way for non-security-critical applications, do this ..."
<nckx>Uhuh.
<apteryx>for the gnu-build-system, we can set #:target; what about #:host?
<apteryx>oh, seems I'm getting away with just #:target rather OK: https://paste.debian.net/1221361/; not sure why libz and libcurl are missing
<nckx>apteryx: What about #:host?
<nckx>What would it do?
<apteryx>for compilers, it'd would act as #:target, I guess.
<apteryx>but I'm not sure :-)
<apteryx>or perhaps it's enough that I use #:target and specify a different --host in the package build system
<nckx>I'm not sure Guix follows that GCC?/Autotools? naming scheme to such a tee.
<apteryx>yeah, which was surprising to me
<nckx>I missed the context that you were building a compiler (but a non-GNU one, so I don't even know if that would help).
<zimoun>does Berlin use real i686 hardware to compile or “-s i686-linux” on x86_64 machines?
<nckx>x86_64
<zimoun>thanks!
<nckx>zimoun: You can see the authoritative (unless someone's edited the file on berlin & not committed it, but who would ever do such a terrible thing!?) list here: https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/machines-for-berlin.scm
<nckx>zimoun: Do you have a bug that needs real i686? I think I have one lying around.
<apteryx>nckx: more context: the wip-cross-built-rust branch
<apteryx>(just pushed)
<zimoun>thanks
<nckx>apteryx: Ooh.
<nckx>So… cross-built Rust as part of the normal dependency graph on some architecture?
<apteryx>that's the end game yes
<nckx>Cool.
<zimoun>nckx, I do not know. I suspect Julia packages to pass tests on real i686 but they fail with “-s i686”.
<zimoun>apteryx: neat!
<apteryx>janneke: do you know if xz-mesboot is supposed to be cross-compilable? it's failing while attempting to cross-build ld-wrapper (from x86_64 to i686)
<apteryx>to reproduce: ./pre-inst-env guix build -e '(@@ (gnu packages commencement) xz-mesboot)' --target=i686-linux-gnu
***iyzsong- is now known as iyzsong
<janneke>apteryx: we never tried that before...
<janneke>hmm, isn't xz-mesboot still --system=i686-linux?
<apteryx>what do you mean? you are wondering if it builds with --system=i686-linux?
<apteryx>(also, hello!)
<janneke>hi!
<janneke>the bootstrap up to gcc-5.5 (?) is built as i686-linux, only after that a cross-build is done to x86_64-linux
<janneke>apteryx: $ file $(./pre-inst-env guix build -e '(@@ (gnu packages commencement) xz-mesboot)')/bin/xz
<janneke>/gnu/store/r1zsxj7wlvw1aa1ifv3nyrrjag44pc9s-xz-mesboot-5.0.0/bin/xz: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.0.0, with debug_info, not stripped
<apteryx>I see! Thanks for explaining.
<janneke>
<janneke>yw
<apteryx>what I'd like is to be able to cross-compile ld-wrapper, but this pulls these cross dependencies which don't build
<jgart>roptat, I made a little script from the tip you gave the other day at the Guix packaging meetup: https://git.sr.ht/~jgart/dotfiles/tree/master/item/bin/executable_in_container
*jgart yet another way to tell if you're in a guix shell/container
<apteryx>is it looking for the GUIX_ENVIRONMENT variable?
<nckx>M-hm.
<jgart>Yup, it just checks to see if it's set and says the "right thing" if you're in or out of a container/shell
<jgart>I might rename it to something shorter but maybe it doesn't matter
<roptat>jgart, really setting $PS1 depending on $GUIX_ENVIRONMENT is a lot easier and you can passively know whether you're in an environment or not
<roptat>just add what the hint gives you to your .bashrc (that time it's really .bashrc) so you get a different PS1 inside the environment
<yewscion>Hello All, is there a mechanism I'm not seeing to specify additional channels in a guix home spec? Or is that meant to live separately from the home configuration?
<jgart>roptat, I had that configured before. Something along these lines: https://github.com/jsoo1/dotfiles/blob/eaf7070a78cbf3d0b43623d00a7feacbbad78068/bash/.bashrc#L20
<jgart>I'll add it also, thnx
<roptat>yewscion, I think it's supposed to be separate, in ~/.config/guix/channels.scm
<yewscion>roptat: Alright, thanks! Just want to make sure I do things in a canonical way.
<attila_lendvai>i wish there was a herd repl command...
<apteryx>I think it supports doing so
<apteryx>grep the sources; you can send commands directly to the socket
<apteryx>or look at the system test examples, they use that IIRC.
<attila_lendvai>is there any strange restriction in a herd activation form wrt calling (SYSTEM ...) and/or setgid/setguid? i guess herd is running as root, right?
<roptat>attila_lendvai, maybe it doesn't have access to $PATH, or a different value?
<attila_lendvai>s/herd/shepherd/
<apteryx>yes, as root
<apteryx>it's PID 1
<attila_lendvai>i'm using full store paths to the binaries. maybe it cannot access /bin/sh? (the C system call wants that)
<attila_lendvai>my code works in a root guix repl, but not in the activation code of a shepherd service. i get an error from the system call, i.e. it's not some package issue.
<attila_lendvai>fork and setuid/setgid to the service user is also involved, but AFAIU permissions and everything is fine
<attila_lendvai>and it's a very hard terrain to debug...
<bdju>I have a video call interview in a few days. Does anyone know if it's possible to screenshare from Sway on Guix System? I'm not sure if I'll need to, but it's a concern I have.
<attila_lendvai>correction: the system call fails even without fork and setuid involved.
<attila_lendvai>a clue is that system* works, but system doesn't. must be something with /bin/sh. the service user's shell is nologin, but the C system manpages explicitly talk about /bin/sh, not the user's shell
<podiki[m]>bdju: I haven't used Sway, but hopefully wouldn't be any different than another distro, likely depends on the video call software you are using
<attila_lendvai>it's the same after changing the user's shell to bash from nologin
<podiki[m]>(though may depend on master vs core-updates-frozen for software versions needed?)
<jpoiret>i know that on sway you have to use https://github.com/emersion/xdg-desktop-portal-wlr, and it doesn't work without some configuration
<bdju>podiki[m]: well, the weirdness would be related to wayland, and I might need certain things in place that might not be packaged
<bdju>jpoiret: thanks for the info. is there a guide on how it's configured somewhere?
<podiki[m]>bdju: I have yet to use wayland, so can't comment there sorry. (I do plenty of video conferencing on X with guix that is fine at least)
<bdju>well, I don't run a display manager right now, and iirc startx doesn't work on guix system. so I would have to do quite a bit of setup to get X going at this point. I'd sooner use a different machine probably
<bdju>(also, I don't really want to use X if I can help it...)
<apteryx>sneek: later tell civodul hi! "ld-wrapper-cross" appears as a native-input in cross-gcc, but is there otherwise a way to get a handle to it in a cross-built package? I'd like to add it to the PATH of the cross-built 'cargo'.
<sneek>Okay.
<ArneBab>rekado: sure it is OK to upgrade! I just didn’t have the time to do it …
<rekado>ArneBab: okay, I’ll update it.
<zimoun>apteryx: In fact julia-* is broken for master on i686. Therefore, it is a bit longer than expected. :-) I will send a v2 fixing all Julia things for i686 on core-updates-frozen tomorrow. I guess. The fix for julia itself remains the same for v1 or v2. Wait just avoid to let CI build some julia-* that I know are broken. :-)
<cryptograthor>Hi, first time here. Running into issues on installing from a USB, I get the message "/mnt/boot/efi doesn't look like an EFI partition"; $ fsck -N /dev/nvme0n1p1 (the efi partition) says the system is formatted as vfat as expected. What else should I look at?
<nckx>Hm, and yet that error is triggered only by ‘grub_strcmp (fs->name, "fat")’ in GRUB.
<nckx>Are you sure it's actually mounted there?
<cryptograthor>lsblk indicates that nvme0n1p1 has mountpoint /mnt/boot/efi
<cryptograthor>though, ls /mnt/boot/efi reveals an empty directory (not sure if that matters)
<nckx>If this machine ha{s,d} a previous OS on it, that's unlikely, but if you just created/formatted the partitition yourself it's expected. We can't say.
<attila_lendvai>FTR, converting (system ...) to (system* "/bin/sh" "-c" ...) solves the issue. still no idea why system doesn't work inside a shepherd activation form.
<cryptograthor>it's a fresh reformat. Running guix system reconfigure /mnt/etc/config.scm, I got a message about being unable to determine system provenance
<nckx>What does ‘mount | grep /mnt/boot/efi’ return?
<davidl>Aanyone who wants to review a guile-bash package update and bug-fix (https://issues.guix.gnu.org/51791)? You can also PM me here on IRC for questions/comments.
<attila_lendvai>nckx, FYI, the --no-graphic patch: https://issues.guix.gnu.org/52204
<nckx>Thanks. I've got to go now. I told cryptograthor to reinstall Guix System (something was clearly wrong with GRUB in a way that would be hard to debug remotely). If someone here might hold their hand, it would be wonderful.
<nckx>'night Guix.
<apteryx>nckx: good night!
<cryptograthor>To configure the efi partition, is this correct use of mkfs? $ mkfs.fat -F 32 /dev/nvme0n1p1 # efi
<rekado>yes, that (with /dev/sda1) is what I ran as well.
***Myrcies is now known as myrcy
<roptat>cryptograthor, I'd expect you to run guix system init instead of reconfigure, if you're in the installer
***ss2`` is now known as ss2
***mark_ is now known as mjw
<attila_lendvai>updated trezor support: https://issues.guix.gnu.org/52207
<lilyp>attila_lendvai: w.r.t. random, most programming languages (IIRC guile included) use Mersenne Twister by default, which is *not* cryptographically secure
<attila_lendvai>lilyp, thanks! is /dev/urandom any better?
<the_tubular>I'm trying to figure out what are the "*-minimal" package in guix's repo
<the_tubular>reading the package definition isn't really helping me
<attila_lendvai>to answer myself: yes, /dev/urandom is fine.
<lilyp>attila_lendvai: The kernel random-number generator is designed to produce a small amount of high-quality seed material to seed a cryptographic pseudo-random number generator (CPRNG). It is designed for security, not speed, and is poorly suited to generating large amounts of random data. Users should be very economical in the amount of seed material that they read from /dev/urandom (and /dev/random); unnecessarily reading large quantities of
<lilyp>data from this device will have a negative impact on other users of the device.
<lilyp>from https://linux.die.net/man/4/urandom
<dissent>hey guix, i successfully used guix lint and build on a package i'm attempting to add. this was in admin.scm. when i attempted to lint and build another package it reads "unknown package". what could be the issue here?
<lilyp>i.e. don't read from urandom directly into passwd; that's wasteful af
<lilyp>dissent: if it only exists in your local checkout you might need to build that first and use pre-inst-env
<lilyp>it could also be a hidden package or something in which case you need to eval your way around it
<attila_lendvai>background: i'm using /dev/urandom to generate a password when a service first starts. this is what upstream does also (in their debian package).
<dissent>lilyp: thanks for the response. will attempt to figure it out.
<roptat>the_tubular, they're "minimal" variants that have less dependencies, in general
<the_tubular>Yes, this is what I could gather, are the features comparable ?
<roptat>since there are less optional dependencies, there are less features
<the_tubular>Which features are missing ?
<roptat>depends on the package, for instance wpa-supplicant-minimal is the same as wpa-supplicant, but it can't use dbus
<the_tubular>I see
<roptat>or emacs-minimal would let you edit files, but without graphics, multilingual support, network capabilities (or at least without SSL), ...
<dissent>lilyp: that did the trick, thanks.
<dissent>that is, rebuilding the previous package definition
<jgart>dissent, have you been using ./pre-inst-env for building packages in a checkout?
<dissent>jgart: yes. managed to succesfully build `fff`.
<jgart>oh great!
<jgart>send a patch ;)
<dissent>jgart: that is where i lost all my confidence haha.
<jgart>you might need to patch some binaries for fff
<jgart>check out other shell packages in guix
<jgart>Guixers, wdyt? https://github.com/dylanaraps/fff
<jgart>lilyp, nckx, roptat,
<dissent>jgart: check out our matrix chat. I sent you the definition I came up with.
<roptat>yeah, I'd replace some of these calls. I saw a call to "file", which we don't provide by default I think
<roptat>the lazy way would be to propagate, the right way is to substitute* that to a store reference to file
<jgart>dissent, share it here too
<jgart>the latest one
*roptat needs to go
<jgart>thanks roptat!
<dissent> https://termbin.com/x23t
<jgart>dissent, see ytfzf for the long way
<jgart>raghavgururajan, and I had to take a patch for that one
<jgart>but try roptat suggestion first with substitute*
<jgart>grep for examples of others using substitute*
<jgart>In other words, you have to get any executables in fff to use the ones from /gnu/store/... explicitly
<dissent>i see.
<jgart>dissent, https://github.com/dylanaraps/fff/blob/master/fff#L154
<jgart>for example, line 154 above is calling `file`
<jgart>we need `file` from `/gnu/store/uuid.../bin/file`
<jgart>dissent, not to be confused with `/usr/bin/file`
<jgart>I wish there was a less tedious way for bash programs...
<dissent>right. FHS is out the window.
<jgart>but for now, you have to go through and read all of fff and find those places that you need to patch up with substitute*
<jgart>substitute* is a macro found in guix/build/utils.scm if you want to read more about it
<dissent>jgart, going to put a pin in this one for now. going to have to do some travelling tomorrow and will pick it up on thurs.
<dissent>haha i thought this was going to be easy.
<jgart>You picked a hard one ha
<dissent>jgart, how difficult do you think pqiv will be?
<jgart>There might be something in the manual for substitute*
*jgart hasn't checked
<jgart>dissent, way easier/less tedious since you won't have to patch anything like with fff
<jgart>dissent, see here for a summary of what might be needed for the guix package: https://github.com/NixOS/nixpkgs/blob/nixos-unstable/pkgs/applications/graphics/pqiv/default.nix#L22
<jgart>dissent, the above advice of reading nix expressions to get an idea will definitely not work for go or rust packages in guix
<dissent>jgart, yeah i had a look at some of the rust packaging. was thinking to add bat-extras but that one might also be painful.
<jgart>dissent, you might need to patch this or call the configure script manually as I did with trayer-srg: https://github.com/phillipberndt/pqiv/blob/c49c5f6db23a7a42587daf4cc16d104f30b92352/configure
<jgart>see trayer-srg patch on the issue tracker
<jgart>dissent, https://issues.guix.gnu.org/52151
<jpoiret>jgart: re fff. Just like bashtop, I don't really like programs written in bash
<jpoiret>always read like obscure incantions to me
<jpoiret>and patching them for guix is pretty annoying
<jpoiret>maybe someone could write a bash parser in guile, that would make it easier :))
<jpoiret>(otherwise have fun trying to substitute* "dd", only to rewrite every other line)
<jackhill>jpoiret: like https://savannah.nongnu.org/projects/gash/ ? I think that's targeted at bootstrapping though.
<jgart>yup I agree, we need a better way to package shell. I'd like to have fff in guix but it's annoying to have to patch shell code
<jpoiret>jackhill: i didn't know gash had a bash parser (although it's pretty logical when you think about it)
<apteryx>wrapping in with coreutils should go a long way
<jgart>apteryx, can you point to an example of "wrapping in with coreutils"
<jpoiret>but anyways, all those "fancy" tools written in bash don't really look reliable to me
<jgart>I think I might know what you mean but it might be clearer...
<apteryx>jgart: emacs is wrapped in such a way
<jackhill>jpoiret: well, it might not cover all of bash, just enough to do what it needs, but could be a start
<jpoiret>jgart: see https://issues.guix.gnu.org/51798#2 for bashtop (not finished though)
<jgart>I remember having a conversation with alphapapa in which he was surprised at the work required to package shell for guix
<jgart>That conversation is somewhere on github...
<jpoiret>well, that's because when you write shell scripts, you implicitely assume all your dependencies' binaries are findable in the PATH
<jpoiret>for compiled code, we have pkg-config, include dirs, RPATH, etc...
<jgart>apteryx, jpoiret, found it: https://github.com/alphapapa/bashcaster/issues/6
<jgart>from July
<jpoiret>tbh, when C code hardcodes some system("stupid-binary", ...) we also have to patch it by hand
<jgart>> I don't understand this. I have studied Guix a little ...
<slyfox>yeah, there should be no major difference in patching binary paths
<jpoiret>the difference is that bash scripts rely way more on external binaries
<jpoiret>I think that to explain Guix, you first have to explain the basics of the FHS and its shortcomings, maybe that could clear up why we need to hardcode things
<jackhill>behold the horror of when I tried to patch everything: https://issues.guix.gnu.org/47983 I think for the next revision I'll set path, or in this case since it's a launch script, re-write it in Guile.
<jpoiret>ouch. Yeah, that was what i was worried about when doing so for bashtop. Maybe the gash parser is good enough to patch simple binary calls though
<jackhill>it's a very interesting idea that would make a lot of things easier if reliable
<dissent>sounds like fff is not so necessary xD
<KE0VVT>ArneBab: I cannot use (import (language wisp)).