IRC channel logs


back to list of logs

<civodul>brettgilio: neat :-)
<Brendan[m]2>civodul should nojr have both of those lines in their .bash_profile?
<nojr>Brendan[m]2: ok, but which value should GUIX_PROFILE have?
<Brendan[m]2>well, im looking at those lines, and they don't export the variables, but i think just set them for that one command, so it might be right to have both of them
<Brendan[m]2>brettgilio looks the same as drews blog, did you use his code?
<brettgilio>brendyyn: nope
<civodul>Brendan[m]2, nojr: yes, it's ok to have these 4 lines
<brettgilio>our websites actually look very different imo
<civodul>GUIX_PROFILE is not an env var here, just a shell bar
<brettgilio>shell bar. where can i find one those?
<nojr>‘~/.bash_profile’ (or equivalent file
<nojr>if you do not use Bash) so that environment variables are set next time
<nojr>you spawn a shell.
<Brendan[m]2>hmmm whats better, making a config file as a store item and embedding its path in a services config, or defining as an etc service so it appears in /etc and is loaded in the traditional way?
<erkin>rekado: That's a shame. :-(
<erkin>Should I open a new issue for it?
<FlakyConnectionU>Hello! I just wanted to say that I'm still alive and go-ethereum builds with a metric ton of hacks ;-)
<FlakyConnectionU>I'll try to reproduce everything on a clean environment and start fixing things soon
<erkin>Is there a template for Guix scripts?
<joshuaBPMan>erkin: You could look in the guix src code.. . I think it's guix/scripts
<erkin>Yeah, that's what I'm doing.
<erkin>I was wondering if there's a standard way to do it.
<joshuaBPMan>erkin: that's a bit beyond my expertise. :(
<erkin>It's all right. :-)
<apteryx>anyone else having ibus + Emacs 27 characters issues? e.g, <dead-grave> is undefined when attempting to type French accent grave.
***catonano_ is now known as catonano
<ryanprior>apteryx: I don't have French ibus or Emacs 27 setup, but I just tested Chinese ibus input + Emacs 28 and it worked fine, for whatever precious little that's worth :\
*Brendan[m]2 wonders where ryanprior got emacs 28 from
<Brendan[m]2>i see, there is emacs-next
<ryanprior>I use Guix emacs-next (28) on my personal laptop, Emacs 27 on my work laptop.
<ryanprior>But I don't type Chinese input on my work laptop so no ibus on there.
<Brendan[m]2>i also found a gccmacs channel, but when i tested it, i didnt notice emacs running or loading any faster like it claimed
<ryanprior>I'm gonna wait for them to land that upstream, and it sounds like I won't have to wait forever either
<Brendan[m]2>you mean upstream emacs, or upstream the package definition into guix?
<ryanprior>The biggest thing I'm looking forward to is actually the native GTK3 support so I can have 60fps smooth pixel scrolling like has been previously available on nonfree platforms.
<ryanprior>Oh I mean upstream Emacs.
<Brendan[m]2>ya it sounds exciting
<Brendan[m]2>i guess it spells an end to guile-emacs as a future?
<ryanprior>No reason it should. In fact, once people start wanting to write faster more ambitious stuff for Emacs, the facilities that Guile provides (threading, hygenic macros, etc) will become even more important.
*Brendan[m]2 diverges to yet another random topic
<ryanprior>It definitely looks like elisp will beat guile in the race to make Emacs fast.
<Brendan[m]2>Question: should we always use umask before creating a directory instead of using mkdir and then chmod?
<Brendan[m]2>i heard it can cause insecurities because there is a brief moment in time where the permissions are unsafe (in some circumstances)
<xelxebar>Brendan[m]2: Yes! Setting permissions after creating a file/directory does open a up a race condition where a potential attacker could sneak in before your chmod call.
<apteryx>ryanprior: thanks for testing! In my case it has to do with: GTK_IM_MODULE=xim. Unsetting this environment variable fixes it (but also prevents IBus from working).
<bdju>reloading the sway config still seems to cause a crash :(
<bdju>ran into it over a month ago but was hoping it went away with a reboot like my icecat crashes
<bdju>I know this isn't much of a report but I don't really get what's going on myself
<bdju>okay got new info. when I freshly started my session, reloading the config didn't cause a crash. on autostart I have two named alacritty terminals and emacs. one error I saw mentioned rust, so I thought maybe it was alacritty or waybar causing it
<bdju>then I re-attached to my tmux session I had running locally, reloaded the config again, and then I *did* get a crash
<bdju>here's an error I got at the TTY after that latest crash: Removed session c14.WARNING **: 21:37:40.993: cannot open display: :0interfaces { code: 32, kind: BrokenPipe, message: Broken pipe }', src/libcore/ (null)) (dpms 0)
<bdju>I manually retyped what I saw and then echo'd it to a text file so I wouldn't lose it. it should be right but if something is slightly off, that'd be why.
<bdju>I have a lot going on in my tmux session, but of the things that would've been visible, it's just bashtop, ncmpcpp, pulsemixer, and two plain shells. but then there are other windows of stuff besides that in the tmux session
<wleslie>if I `guix install guile` and then run guile, I get `no code for module (ice-9 readline)`
<wleslie>is there something I can install to get a guile that geiser can work with?
<wleslie>yak level -2 is cryptic guix lint output: In procedure variable-ref: Unbound variable: #<variable 7f610a0d5350 value: #<undefined>>
<Brendan[m]2>wleslie guix install guile-readline
<wleslie>thanks! works great.
<Brendan[m]2>wleslie its likely you set readline loading in ~/.guile and forgot about it
<wleslie>yes I assumed that's what happened
<Brendan[m]2>which service ultimately sets XDG_RUNTIME_DIR
<Brendan[m]2>looks like guix isnt entirely functional config wire. ive got a few things littering /etc now like sddm.conf which i dont have installed anymore
<xelxebar>bdju: I've never poked at sway, but the broken pipe message reminds me of problems I had with xmonad and not connecting it up with the xmobar status bar correctly.
<xelxebar>Do you have any logs (like /var/log/sway.log) that could be more informative?
<bdju>xelxebar: not that I know of. I had debug and verbose flags enabled for the last crash and still the only meaningful thing I saw was that one line
<bdju>nothing in /var/log looks relevant
<xelxebar>bdju: How are you starting way? If you use startx, then adding >sway.log 2>&1 to your sway invocation might capture something helpful
<Brendan[m]2>sway is for wayland not x so it doesnt use startx
<xelxebar>Oh. Duh.
<Brendan[m]2>you just run sway -d 2 > ~/.swaysession-errors
<Brendan[m]2>that will fill up a few 100MiB in a couple hours though
<Brendan[m]2>you just run sway -d 2> ~/.swaysession-errors
<Brendan[m]2>i run it with dbus-run-session actually
<bdju>xelxebar: I'd just been doing `exec sway` or for the last time, `exec sway -dV`. I'll keep the log thing in mind for next time I have a moment to restart.
<Brendan[m]2>how can i inspect the output of shepherd-service? is there a file on the disk somewhere which the resultant code?
<Brendan[m]2>I notice we don't make use of and /etc/securetty
<Brendan[m]2>does it matter?
<civodul>Hello Guix!
<wleslie>good GMT morning civodul!
<botsnack>Hello :)
<civodul>it looks like a day without The Matrix
<civodul>*the Matrix users
<wleslie>they took the red pill not 25 minutes ago
<civodul>heh, that happens
<civodul>quite often actually
<janneke>hey civodul, wleslie, botsnack :)
<efraim>Is there a way to figure out where an environment variable is coming from?
<wleslie>so I'm up to the next step. I have xbinutils -> xgcc -> newlib -> libstdc++ and now I'm adding -> crtfiles. I'm assuming that if I compile them with the xgcc and add them to the toolchain union package they will get used instead of the standard crt files?
<wleslie>feels like a bit of mutability in our old process I'll have to work around.
<xelxebar>--target=arm-arm-none-eabi ... That looks fishy...
<xelxebar>wleslie: Sorry... unrelated :/
<wleslie>ok phew. that's how the embedded toolchain works, apparently
<efraim>looks like kirigami should propagate qtgraphicaleffects, the build log shows during the configure phase that it's a runtime dependency
<xelxebar>For some reason cmake's compiler detection is screwing up badly when building for a non-native --system via qemu-binfmt-service.
<PotentialUser-12>running into this error:failed to connect to `/var/guix/daemon-socket/socket': No such file or directory
<xelxebar>Is your daemon started?
<PotentialUser-12>not sure. I was following the video tutorial on how to install guix they don't mention daemon
<xelxebar>Aaaarrrghhqjkxqjkxqjx... Trying to libreboot this one machine has lead to imprudent amounts of shaved yaks...
<xelxebar>PotentialUser-12: Try checking: pgrep -a guix-daemon
<xelxebar>PotentialUser-12: If you are installing on a foreign distro for the first time, you will need to create some build users and a build group as well as setup your service manager to start the daemon.
<civodul>PotentialUser-12: the video probably mentions "systemctl start guix-daemon" or similar
<civodul>which starts the daemon
<kmicu>You’re doing amazing job dannym Thank you!
<xelxebar>civodul: Would you happen to know cmake at all? Debugging this build error is draining what little life I have left in my soul.
<civodul>xelxebar: not really, and trying to stay away from it :-)
<xelxebar>Probably the smart thing.
<Brendan[m]4>why is there both agetty service, as well as a mingetty service?
<Brendan[m]4>in base-services
<Brendan[m]4>i mean, they seem like they both do similar things.
<leoprikler>agetty seems to be for tty7
<leoprikler>since tty1-6 have already been mingetty'd
<Brendan[m]4>it says (tty #f), does that mean its automatically launched for all non mingetty tty's?
<Brendan[m]4>i discovered today that its possible to run two getty's at the same time on the same tty and the it results in them competing to capture key presses. took me a while to come to terms with the fact that really happened
<Brendan[m]4>on my laptop, im unable to go to tty7 at all
<Brendan[m]4>How would i replicate this systemd config in a shepherd service then: Conflicts=getty@tty1.service
<leoprikler>info "(shepherd)Slots of services"
<nckx>Morning Guixbots.
<nckx>Brendan[m]4: Where you the one with the lost VM keypresses? If so, glad you solved that mystery.
<nckx>Brendan[m]4: <hmmm whats better, making a config file as a store item> yes, this. IM(TSH)O global /etc stuff should only exist for stuff that is used by a large collection of disparate users, like /etc/services, not e.g. food.conf.
<Brendan[m]4>nckx yeah that was me
<Brendan[m]4>nckx what about the difference between /etc... and having stuff in /run/current-system/profile/etc/...
<Brendan[m]4>it seems the latter is just all the crap from packages in the systems profile
<nckx>It's a union of all the /gnu/store/*/etcs that make up the profile.
<nckx>So yeah, ‘random crap’ is a significant component since what ends up there isn't always thoroughly checked (as it's often unused).
<Brendan[m]4>i notice there are things like dhclient.conf.example
<nckx>If I'd packaged dhclient I probably would have moved it to /share/doc/.../examples or so, but it's harmless there. Maybe a matter of taste.
<Brendan[m]4>makes me uneasy. i wonder if build-systems should just purge /etc by default in the output
<efraim>guix system disk-image -L ../guix-config/ ../guix-config/pine64.scm is failing for me on aarch64.
<efraim>i'll see what I can do to make it work
<mothacehe>efraim: did you use '-t pine64-raw'? What's the error?
<efraim>mothacehe: the full command was time guix environment guix -- ./pre-inst-env guix system disk-image -L ../guix-config/ ../guix-config/pine64.scm --cores=2
<mothacehe>ok, you also need to specify the image type
<mothacehe>`--list-image-types` for the list
<efraim>oops, looks like my pine64 is a bit behind, closest it offers is raw
<efraim>that'll take some time to catch-up the ~260 commits and then I'll try building it again
<mothacehe>fine :) let me know how it goes!
<mothacehe>you'll also find a pine64-barebones-os in (gnu system images pine64)
<mothacehe>that you can inherit from
<g_bor[m]>sneek: seen erkin
<sneek>erkin?, pretty sure was seen in #guix 10 hours ago, saying: It's all right. :-).
<g_bor[m]>sneek: botsnack
<efraim>mothacehe: is the bootloader supposed to be /dev/vda in pine64-barebones-os?
<mothacehe>efraim: the bootloader will be written at the start of the disk-image, the target specificed ("/dev/vda") is ignored.
<efraim>so I'll leave mine as /dev/mmcblk0 for the eventual reconfigure
<mothacehe>yes, could be a better default for pine64-barebones-os
<mothacehe>if you want to test the disk-image its available here:
<mothacehe>I should really compress it
<efraim>mothacehe: does it matter that that's using pine64-lts and I have a pine64-plus?
<mothacehe> yes I think it's now the same bootloader
<mothacehe>changing the bootloader to u-boot-pine64-plus-bootloader should hopefully work
<efraim>that certainly changes the meaning ;p
<efraim>guix system: error: gnu/packages/freedesktop.scm:373:2: elogind@243.4: build system `meson' does not support cross builds
<efraim>interesting, it tries to cross compile by default
<mothacehe>yes indeed
<mothacehe>we maybe need to come up with a hack disabling cross-compiling on native architectures
<mothacehe>cross-compilation target is set in arm64-disk-image of (gnu system image)
<efraim>I see it also assumes ext4, i'll change that for my image
<mothacehe>yes but for now only ext and vfat are supported in "make-partition-image"
<bonz060>Hi guix! With `guix import pypi` can you specify a package version? I'd like to do something like `guix import pypi rpy2@2.7.6`
<efraim>`guix import pypi rpy2/2.7.6`
<bonz060>efraim: Thanks!
<efraim>bonz060: although there is a python2-rpy2@2.7.6 in gn/packages/python.scm
<bonz060>efraim: I saw that. I want the python3 version of the same. Currenly migrating to gn2 to python3 ;)
<efraim>ah, fun times :)
<efraim>I'd steal that one and then have the python2 version inherit from it
<bonz060>That's what I wanted to do; but there was a comment on the `#:python` input that went along the lines: "; apparently incompatible with Python 3"
<efraim>I'd try it anyway, it was in guix proper as 2.7.6 as a python3 package
<bonz060>Ah yes. I can build it successfully. I want to build gn2 with it, and then test it out on the python3 branch. Fingers crossed.
<civodul>efraim: the "rpy2/2.7.6" syntax works by chance, no?
<guix-vits>sneek tell me all U know, meow!
<sneek>Welcome back guix-vits, you have 1 message!
<sneek>guix-vits, str1ngs says: . I pushed a new ibuffer-lines branch to savannah. if you can pull and checkout ibuffer-lines and test nomad's ibuffer. let me know if there are any issues. see for details
<sneek>me, guix-vits says: all U know, meow!
<guix-vits>sneek: ttthank U ssrir!
*guix-vits /nick hidden-treasure
<janneke>new post: =>
<davexunit>janneke: awesome article.
<davexunit>typo: s/use sight/lose sight/
<civodul>davexunit: just pushed a fix, thanks!
<janneke>davexunit: thanks!
<jlicht>hey guix!
<jlicht>civodul: you beat me by 52 seconds for the typo in guix-artwork. Congrats on the all the h{u,a}rd work paying off :D
<civodul>i think we owe it to the stubbornness, dedication, and tireless hard work of janneke :-)
<mothacehe>congrats janneke :)
<janneke>thanks for the kind words, civodul and mothacehe -- and especially for your wizardly help, a wonderful journey!
<davexunit>sounds like trying the hurd is easy now. I'll try to find some time to fire up a vm soon
<civodul>i find it pretty fun: you add (service hurd-vm-service-type), reconfigure, and log in
<civodul>the system is very minimal but enough to be exciting IMO :-)
<davexunit>my only guix system right now is my little digitalocean vps
<janneke>and we even have a good excuse for making it this fun; it's practical too: we're using in in the build farm
<davexunit>my main computer at the moment is my work issued laptop running ubuntu. my thinkpad died awhile back and my many repair attempts were unsuccessful. need to get a new guix machine.
<civodul>you sure do ;-)
<davexunit>I was sooo close with the thinkpad. had it corebooted and everything.
<joshuaBP`>janneke: awesome work!
***rekado_ is now known as rekado
<jlicht>janneke: The work you do is always one of the things that makes me genuinely excited about the future of technology. Hats off to everyone who contributed :)
<janneke>thank you, joshuaBP` and jlicht! it makes me happy too :)
<nly>nice blog about thee hurrrd
<roptat>hi guix!
<roptat>janneke, nice!
<janneke>hi roptat, thanks!
***Server sets mode: +cnt
<roptat>should we add a page to the website to list external resources that talk about Guix?
<roptat>like fosdem presentations, carl's bitcoin security presentation, ...
<janneke>could be nice, #lilypond has a "publications" page
<civodul>would be nice
<civodul>FOSDEM talks are usually at but it's kinda indirect
<tecosaur>Is it possible for me to include shell commands that set up things (e.g. installing zinit + plugins) in a system config file?
<apteryx>tecosaur: the idiomatic way to accomplish this would be to package those things, and include them in your system-installed packages, I think.
<tecosaur>I suspect this may not be the "Guix" way of doing things, since everything seems to end up in dirs like /gnu/store/n1c9jiv2njnvdfz58v71fvzq0hkgiv...
<tecosaur>In which case perhaps the way to do would be to generate a ~/.zshrc template which uses the gnu store location of zinit
<leoprikler>as apteryx pointed out, the guix way would be to package them
<leoprikler>zsh reads functions from some well known directories, and IIRC ~/.guix-profile/share/zsh... gets patched into them
<leoprikler>if not, just add it to your fpath
<jlicht>tecosaur: alternatively you could have a look at guix-home-manager
<tecosaur>Oh? [googles]
<jlicht>it's nowhere near finished, but it takes over you entire home directory
<apteryx>dannym: thanks for fixing
<efraim>sneek: later tell mothacehe building the arm image natively worked and the board boots up! Now I just need to find growfs
<sneek>Got it.
<efraim>sneek: botsnack
<tecosaur>I see. ATM what I have is this:
<apteryx>I have those little Elisp procedures, to parse a Debbugs issue buffer and return the corresponding Guix issue link, if anyone is interested: It puts the link into your Emacs kill ring, ready to be yanked.
<tecosaur>That looks nice and neat :)
<apteryx>It could be made smarter by also working in the main *Guix Bugs* buffer, by picking up the entry under the pointer.
<tecosaur>Oh, would it be rude of me to ask for some help getting that zinit package definition working?
<apteryx>ask away
<tecosaur>Well, from what I can tell at the moment my package definition will fetch the source as required
<tecosaur>which has me a little stuck
<roptat>tecosaur, the unpack build system doesn't exist, you probably want gnu-build-system?
<roptat>also there's no MIT license, you probably mean the expat license :)
<tecosaur>Thanks and thanks again
<roptat>you're missing an import for (guix licenses) as well as (guix build-system nu)
<tecosaur>Much appreciated
<roptat>also, you should not use the generated tarball at github, because they tend to not be stable
<roptat>instead, you should use the git-fetch method
<tecosaur>Thanks for the tip
<roptat>oh, if there's nothing to build, you could use the copy-build-system
<roptat>in (guix build-system copy)
<apteryx>Does anyone know about Kerberos? Would it make sense to enable its TLS support by adding openssl as an input (core-updates).
<rekado>apteryx: yes.
<GNUtoo>I tried guix system disk-image --system=armhf-linux -e '((@ (gnu system install) os-with-u-boot) (@ (gnu system install) installation-os) "A20-OLinuXino-Lime2")' on an ARM board this time
<GNUtoo>and I've a vailed build log at /var/log/guix/drvs/4h/b6lg9byfhs3mx0vgxg4xz5axl0pv3i-gcc-cross-sans-libc-xtensa-elf-7.5.0.drv.bz2
<GNUtoo>with the following:
<GNUtoo>ah ok sorry, I didn't see the message well last time I looked
<GNUtoo>cp: error writing 'gcc-cross': No space left on device
<GNUtoo>now I saw that
<GNUtoo>I probably need to increase the size of the /tmp dir that's all
<civodul>GNUtoo: yeah, these things are very disk hungry
<GNUtoo>not disk hungry, RAM hungry
<GNUtoo> /tmp is set to 50% of the RAM
<civodul>oh i see
<GNUtoo>So I did that:
<GNUtoo>I added TMPDIR=/gnu/tmp in Environment in the systemd unit
<GNUtoo>and did mkdir /gnu/tmp before
<civodul>ok, makes sense
<GNUtoo>yesterday I didn't see the failure because I didn't go up enough in the build log (split screen)
<GNUtoo>*the real failure
<GNUtoo>like I saw only some C compilation error about } somewhere but that was printed after the space issue
*GNUtoo bbl
<apteryx>civodul: do you know what could cause this kind of error: ? I pushed a commit or core-updates that touched (guix build utils). But I don't see how that could cause that.
<apteryx>here's a more complete paste that hints at (guix build utils):
<apteryx>I reckon it's probably reproducible by checkout out current core-updates, then issueing: ./pre-inst-env guix build --no-substitutes --rounds=2 hello -K
<civodul>apteryx: yes, it's a reproducibility error, and i'm afraid it's expected: there are still sources of non-reproducibility in .go files :-/
<leoprikler>wait, so everything about reproducible builds up until now has been a lie?
***zacts_ is now known as zacts
<civodul>well, there's a saying here that the shoemaker is the one who has the most broken shoes
<civodul>i think it very much applies here
<apteryx>civodul: OK, thanks for the info. Seems it's not tracked in the Guix tracker; do you know of an issue in the Guile tracker?
*apteryx checks
<cbaines>The instance of the Guix Data Service I was using to try and track package reproducibility is creaking back in to life, I think this information is sort of up to date
<civodul>cbaines: yay, that's really cool
<cbaines>nckx is still doing a pretty great job at actually building packages
<apteryx>seems it's not tracked in Guile either. I'll add an issue in Guix.
<civodul> even :-)
<civodul>we should reopen it
<civodul>+ unarchive
<apteryx>unarchive + reopen (then wait a couple hours (days?))
<apteryx>This would be a Guile 3 regression?
<civodul>i'm not sure, i don't think so
<civodul>i think it happens when building things in parallel
<civodul>because that changes the serial number of some gensyms
<tecosaur>Hmmm. Reconfiguring is giving me an error
<tecosaur>"guix system: warning: cannot determine provenance for current system"
<tecosaur>It ends with the line:
<rekado>that’s not an error
<tecosaur>It has "Backtrace:" underneath it though
<tecosaur>ending with
<rekado>can you paste the full error?
<tecosaur>I think this is the relevant part of my config
<tecosaur>Oh wait
<tecosaur>nvm, sorry
<tecosaur>I forgot to put the . in my alist - ooops
<apteryx>civodul: I sent the commands to reopen the issue, and appended the diffoscope output I see to it.
<pretzel>On "an earlier post" points to (404) should that point to instead?
<civodul>pretzel: indeed, thanks!
<emacsen>this may be a dumb question... I can't google it. What is the guix "meta-package" equivilent. Ie "I install X and that installs A B C"
<civodul>hey emacsen
<civodul>emacsen: we use "propagated inputs" for that
<civodul>"gcc-toolchain" is roughly a meta-package, for instance
<emacsen>I'll crack open the git repo, I don't see that mentioned explicitly in the reference manula
<emacsen>erm manual
<civodul>yeah, there's no "meta-package" concept as such
<civodul>but one can achieve something equivalent
<emacsen>I guess by listing all the dependencies
<emacsen>fair enough
<emacsen>leoprikler, yes, sorry
<leoprikler>if you're very desperate and need everything in one directory, you could also look into union-build
<emacsen>leoprikler, what do you mean by desperate?
<leoprikler>desperate in the sense, that you need the outputs of the subpackages in one folder
<leoprikler>there are some use cases for that, see e.g. texlive-union or sdl-union
<emacsen>leoprikler, yes, that's sort of what I have in mind
<blackbeard>hi! Can I, and how, run Icecat inside a guix container?
<blackbeard>manual says I need a PID, but i don't know how to create a PID
<leoprikler>yes, guix environment --container --ad-hoc icecat -E XAUTHORITY -E 'XDG_*' should do the trick
<blackbeard>leoprikler: oh awesome!!
<blackbeard>this should improve privacy right? i know it is beta but that's ok
<leoprikler>you should probably not expose the current working directory (home in most cases)
<blackbeard>will it isolate icecat from accessing my /home directory
<blackbeard>if I use a different directory like if i run that command inside /home/blackbeard/icecat/
<leoprikler>either that or --no-cwd
<leoprikler>you may additionally have to --expose certain paths to make it usable, but other than that you should be safe
<blackbeard>just ~/Downloads should be fine right? ohh maybe i also need ~/.mozilla
<leoprikler>if you want to save downloads you would have to --share
<blackbeard>oh ok so --share ~/Downloads instead of --expose or both?
<blackbeard>guix is so awesome :)
<leoprikler>--share ~/.mozilla on first run and if changing settings, otherwise just --expose is fine
<blackbeard>ah nice
<leoprikler>for Downloads, I'd suggest sharing and saving to something in /tmp and then manually moving stuff around
<leoprikler>that way no one will find your old downloads ;)
<leoprikler>alternatively using external tools such as wget and curl where possible
<blackbeard>i just need my printer to work :( unfortunately it requires proprietary software
<blackbeard>leoprikler: ah yes, i didn't actually plan to download stuff I thought that icecat may need it to work
<leoprikler>Nah, it should be fine without it
<blackbeard>wonderful :)
<leoprikler>especially if you're not downloading stuff
<blackbeard>then only .mozilla for my config and addons right?
<rndd>hi guix! \0/
<blackbeard>do you think guix is secure enough even if it doesn't have SELinux or AppArmor
<emacsen>blackbeard, secure enough for what?
<blackbeard>yeah, kinda of a dumb question I admit
<blackbeard>just regular stuff like browsing the internet
<roptat>mh... I'm getting some weird warnings when trying to build the website
<blackbeard>not executing anything
<emacsen>blackbeard, I'm not saying it's a dumb question, but it's a bit hard to answer.
<roptat>In procedure load-thunk-from-memory: incompatible bytecode version
<roptat>but I'm in a pure environment: guix environment --ad-hoc guile@3.0.2 guile-json guile-syntax-highlight haunt guix --pure
<leoprikler>perhaps you built some of it with 3.0.4 earlier?
<roptat>that's not about stuff compiled locally, but /gnu/store/mm4h6x1d0j66d3my8fr152fzy40cfx81-profile/lib/guile/3.0/site-ccache/guix/ci.go etc
<roptat>so, from the guix package
<roptat>which is supposed to be built with guile 3.0.2
<roptat>(but I also get the same warnings with simply "guile")
<PotentialUser-38>jackhill, ryanprior and nckx: please don't scream in horror :-)
<tecosaur>Is there a good way for me to modify global env vars?
<roptat>in guix packages, you can use search-pathes
<roptat>it means that the package will use this env var, so guix will make sure it's defined when the package is in use
<PotentialUser-38>That's the outcome of my first Guix crash course, crash included. I would like to receive your opinion and comments before daring to submit a public patch.
<rndd>PotentialUser-38, damn, it's epic
<PotentialUser-38>...(and hacky) thanks!
<pineapples>nckx: Have we found that someone™ else who would be willing to maintain knot-resolver? Today I discovered that DNS responses are not validated with DNSSEC (I'd say it's a security issue), and the service itself fails to start at all in its default %kresd.conf configuration :(
<leoprikler>super hacky
<leoprikler>is there no sane way to build go packages?
<PotentialUser-38>Well, the target package did not even use the standard build mechanism, and that's why the package definition overrides some of the build steps.
<PotentialUser-38>For standard packages, the only sane way (for the current Guix) would be by adding every [nested] as a package.
<PotentialUser-38>leoprinkler: removing Guix from your question, no, there is no sane way of building a Go package :-)
<leoprikler>Notice, how I didn't specify "on Guix" ;)
<leoprikler>It seems to be the same dependency hell as node-build-system
<leoprikler>but imho downloading stuff during build is very not in the spirit of guix
<pineapples>I didn't notice there was an absence of Go packages. Am I missing on something?
<PotentialUser-38>I know that on-build downloads are against the Guix philosophy, but at least they're deterministic and hashed. :-) Probably not a good long-term solution anyways.
<PotentialUser-38>pineapples: Guix repository only has some core packages, but there is a mare magnum of other third-party packages and their dependencies.
<PotentialUser-38>If you want to build a minimally complex Go package, you'll need to gather first dozens of dependencies with a cluster munition of nested packages
<MSavoritias[m]2>is it the same with rust? I have seen dozens of rust packages added
<PotentialUser-19>MSavoritias[m]2, rust packages have dependencies specified at the package level
<PotentialUser-19>Through #:cargo-inputs
<MSavoritias[m]2>ah. so the difference is that rust has a clear structure that is documented byt go is all over the place?
<MSavoritias[m]2>And guix can't get out of the depedency hell
<PotentialUser-19>Yes, that's a good explanation, though the Go build system also has room for improvement
<MSavoritias[m]2>is it in the roadmap do you know? that could make our job easier
<MSavoritias[m]2>i don't think node has it in the roadmap though. A shame. It would have been easier to package a lot of stuff
<PotentialUser-19>I've been here for 48 hours, so I'm clueless about the roadmap
<MSavoritias[m]2>make sense :P
<PotentialUser-19>That's the nearest match I could find
<MSavoritias[m]2>ah. I though you meant about the languages themselves.
<PotentialUser-19>No, I meant the go-build-system from and
<PotentialUser-19>About the proper programming language, yes, they're improving through the usage of modules, but there is a bit of collision between their own package manager and any other
<PotentialUser-19>The traditional Go packaging methodology was "vendor a copy of every dependency inside your own project"
<mfg>is there a way to force guix to kill pending builds? they seem to be in an endless loop and i don't know how to debug it.
<civodul>mfg: just hit Ctrl-C
<rekado>blackbeard[m]: if you want to you could enable the SELinux policy and help us debug it.
<rekado>it’s mostly a *daemon* policy, though, but it’s a start
<pineapples>rekado: how can I help?
<mfg>civodul: that's exactly what i did, so i guess it takes some time until they actually vanish from the process list then
<civodul>it should be almost instantaneous
<civodul>mfg: you can run "guix processes" to see what clients are left
<ArneBab>janneke: the link in the cool new hurd blog post to does not work
<civodul>ArneBab: this is fixed in Git but somehow the automatic update hasn't picked it up
*civodul kicks it gently
<civodul>thanks for the heads-up!
<janneke>ArneBab: ty :-)
*janneke also only checked git...duh
<zimoun>Hi Guix!
*janneke mumbles la carte n’est pas le territoire -- or something
<zimoun>erkin: Thanks for your interest. :-)
<mfg>civodul: good to know :)
<civodul>janneke: :-)
***happy_gnu is now known as blackbeard
<nckx>Hullo blackbeard & Guix.
<blackbeard>so now that I am inside the container how do I run icecat, it says DISPLAY is not set
<blackbeard>Error: no DISPLAY environment variable specified
<blackbeard>hello nckx :)
<blackbeard>I ran this command for the environment
***stikonas_ is now known as stikonas
<blackbeard>guix environment --container --ad-hoc icecat -E XAUTHORITY -E 'XDG_*' --no-cwd
<apteryx>perhaps add -E '^DISPLAY$' and --network
<rekado>blackbeard: it’s more complicated than that
<rekado>you also need access to the display manager, the user state directory at /run/user, etc
<blackbeard>apteryx: thanks!
<rekado>but you can’t just --share=/run/user either
<mihi>hello janneke, thanks for the smaller VM images and the blog post :)
<apteryx>blackbeard: here's what worked for me last time, testing gnome-boxes: guix environment --expose=$HOME/.Xauthority -E '^DISPLAY$' --container --network --no-cwd --ad-hoc gnome-boxes
<blackbeard>ohh ok
<blackbeard>apteryx: it almost worked!! I just can't see fonts so I also exposed .fonts
<blackbeard>noo i don't even have a ~/.fonts hahaha
<leoprikler>you probably want to expose .guix-profile/share/fonts as .fonts
<leoprikler>alternatively add some fonts to your container
<zimoun>civodul, roptat, rekado: I am reading the log of yesterday about discoverability, docs and manual. It remembers me discussion I had with Pierre.
<zimoun>The current material is “Dewey Decimal System“ as in libraries and it really difficult to find something whhen one has an approximate wordings but almost optimal when one exactly knows what they are looking for.
<zimoun>Otherwise –know what one wants but approx. wording– the only solution is statistical indexing: other said search engine. It could be an interesting student’s project to index all (with a bit of intelligence) and see if it helps.
<apteryx>to get fonts you need XDG_DATA_DIRS set
<apteryx>you can install glib along with some fonts to have this pulled in
<apteryx>err, the above has been tested for icons. I don't know if fonts can also be found via the XDG_DATA_DIRS.
<rekado>note also that you may need to first run ‘xauth extract - $DISPLAY > ~/.Xauthority’ to generate the .Xauthority file
<rekado>(I didn’t have one)
<mihi>Getting this on an "unchilded" childhurd: "guix pull: error: Git error: invalid version 0 on git_proxy_options"
<mihi>Just downloaded 'rrixd94wrfkw4kdw519736br0xdhxjp5-hurd-barebones.qcow2', converted it, made networking work and ran "guix pull" (as root).
<mihi>known issue?
<Brendan[m]4>I've been thinking of this cool idea. Suppose we had 3 different people/groups that could run 3 different build servers with --no-substitutes. We could extend guix to loal substitute information from all 3 sources and only download them when all 3 agree on the same hash. if there was any reproducibility error, we would bail out and build from source. this would mean that substitutes could be downloaded such that even a
<Brendan[m]4>given substitute server does not need to be trusted. would this not make guix the most trustable software update mechanism in the world?
<mihi>(but I'm pleasantly surprised that I get a substitute for guile-3.0.2 now, my other older unchilded childhurd never managed to finish building it.
<blackbeard>ok let's see.. it is loading
<zimoun>Brendan[m]4: yes these kind of ideas are in the pipe :-) especially with decentralized susbtitute (IPFS or GNUnet or name-it)
<Brendan[m]4>decentralized is just a transport mechanism, it doesn't ultimately change the trust model
<Brendan[m]4>and i hope if we build decentralised substitutes, its done on a general abstraction. because perhaps even bittorrent (v2?) is a good choice too.
<cbaines>Brendan[m]4, I tried to start working on implementing that a few months ago
<Brendan[m]4>cbaines great work!
<zimoun>Brendan[m]4: one of the point is to be able to share (with trust) what we individually build and avoid to rebuild again and again
<cbaines>Brendan[m]4, well I didn't really get very far, but it's something I'd like to circle back to
<erkin>zimoun: Hello!
<cbaines>The substitute availability situation is getting better, and alongside tooling for assessing substitute server consistency the approach you describe could be really valuable
<zimoun>cbaines, Brendan[m]4: yeah one of the hard question is how to trust (which consensus, etc.)
<zimoun>erkin: hey!
<blackbeard>this is not working
<blackbeard> guix environment --expose=$HOME/.mozilla --expose=$HOME/.guix-profile -E '^DISPLAY$' --container --network --no-cwd --ad-hoc icecat --expose=$HOME/.Xauthority --expose=$XDG_DATA_DIRS
<blackbeard>the problem is with $XDG_DATA_DIRS
<Brendan[m]4>zimoun (i havent yet read the email so your answer may be there), but if everyone can build and share substitutes and "vote" on the correct one then someone could produce many identities and spam the network. i guess perhaps we could start with an invite only ring of keys in guix.
<cbaines>zimoun, I don't think that's too hard, as it's sort of out of scope. Maybe you trust your employer, maybe you trust the FSF, maybe you trust the Guix maintainers. The ability to trust a substitute if more than one party agrees just makes things more secure
<Brendan[m]4>however i feel like still itll always be more practical to build everything on dedicated powerful servers
<zimoun>cbaines: to word differently, what do you us as basis to trust your employer ? FSF? Guix maintainers? etc. Well, the 51% attack etc. I mean, it is not an straightforward solution depending on what you use as basis for trusting. But IMHO
<zimoun>cbaines: BTW, that’s for the reproducibility webpages, I have forgotten their existence :-)
<rekado>blackbeard: what does ‘is not working’ mean exactly?
<cbaines>zimoun, I think that's still a problem, but it's a different problem to the one being addressed by "K of N" trust in substitutes.
<zimoun>rekado: it is possible that the haskell-build-system (merge of wip-haskell) introduces non-reproducibility for Haskell packages… Well, I am tracking the reression for git-annex but efraim pointed out the haskell-build-system
<mihi>Is there some general guix command line switch to get it output a backtrace (or at least a filename) when an error happens? Even without pulling I'm not able to reconfigure my hurd vm. Because it tries to access /proc/partitions. And I'd like to see why it tries to (there is no /proc/partitions on Hurd) and what it needs it for.
<zimoun>cbaines: I agree. And ‘K of N’ could be really nice to have.
<zimoun>rekado: for example if you browse and the next ones, you can see that some are ghc-*
<terpri>mihi, for guix system reconfigure? there is an --on-error=(nothing-special|backtrace|debug) option
<rekado>zimoun: I don’t see how.
<rekado>all we did was remove references (and move files to separate outputs)
<zimoun>rekado: maybe commit 67cb9fa2357026ee42ec5bb0923ec4dc4a43abe2 with parallel builds
<terpri>mihi, and it looks like gnu/build/file-systems.scm is the only place that reads /proc/partitions, in the disk-partitions procedure
<mihi>terpri: thanks :) that option has no effect for me but I'll have a look if "find /gnu/store" can find that file for me :)