IRC channel logs


back to list of logs

<lfam>Reviewing helps, no matter who does it
<singpolyma>lfam: well, it's probably bad form to commit your own stuff right? So I assumed committers would have that status so they could review. But I guess I was wrong
<lfam>Historically, committers were invited when the burden of reviewing their contributions became too much work for not enough benefit (the work was good enough)
<lfam>It's a little different now. Even the most seasoned contributors are expected to submit their work for review
<lfam>And although we are all just volunteers, there is some expectation that committers will assist with review, at least a little bit
<dissent>hey guix, is there a way for guix packages installed on a foreign distro to "talk" to the packages installed with the native package manager?
<singpolyma>dissent: depends on the kind of talk
<dissent>In other words, if I install font-iosevka with guix on debian, can xmonad (installed with apt) see that font?
<singpolyma>If the right symlinks or env vars are in place
<podiki[m]>maybe a symlink from your home folder fonts (forget the path); fonts shouldn't be too hard
<podiki[m]>lfam: thanks for the insight
<podiki[m]>I've been thinking when I would feel comfortable enough to try for commit access; but now you have me thinking really what I need to do is review other's patches
<lfam>podiki[m]: It would be interesting to hear what would improve things from your point of view
<lfam>I have to go afk to cook now, but I will read the logs or any emails you send to the lists
<podiki[m]>I think low hanging fruit is getting updates and easy fixes committed faster (and usually are, but they can get lost)
<podiki[m]>lfam: enjoy!
<podiki[m]>maybe organization; as was noted recently having feeds from the issues page would be handy
<dissent>ah, I see, pretty easy to do. thanks.
<podiki[m]>then I could subscribe to keywords and packages I'm more familiar with and have worked on, like flatpak, mesa, haskell, etc.
<nckx>Did something big change about Guix's
<podiki[m]>besides the glibc for /gnu/store/... reading?
<podiki[m]>there was a recent bug report on that front for non-x86
<florhizome[m]><lfam> "We ask people to apply for..." <- I‘d rather abolish debbugs then apply for using it as of rn ;p
<florhizome[m]>btw, where do I find shepherds config file in guix System?
<nckx>podiki[m]: Regarding stripping it, apparently.
<lilyp>In /gnu/store :P
<nckx>echo 'echo /gnu/store' > /bin/whereis
<lilyp>florhizome[m]: Jokes aside, there is a boot script in your guix system generation which loads shepherd by name
<lilyp>warning, nothing's pretty printed
<the_tubular>Did zfs just landed in official guix ...?
<the_tubular>Nvm, seems to be just an update
<florhizome[m]>lilyp you mean shepherd.conf
<lilyp>for instance, my /run/current-system/boot ends with this: (execl "/gnu/store/b5wzv9rqxsn2lybhy52ywwy2ygskxx6z-shepherd-0.8.1/bin/shepherd" "shepherd" "--config" "/gnu/store/jjdr1q236nvhiaqxdvh64vi7iig89c7k-shepherd.conf")
<lilyp>and a bunch of closing parens, but you get the point
<florhizome[m]>yikes it just lists the compiled service–conf.go s
<florhizome[m]>Yeah I looked into top
<florhizome[m]>htop lol
<florhizome[m]>* grep /gnu/store/*–shepherd
<nckx>podiki[m]: What exactly was the bug report about? Valgrind?
<nckx>I got absolutely nowhere trying to pass --extra-debuginfo-path=. I don't even know what it expects to find there (there is no ld-linux-x86-64*debug in #$glibc:debug). Behold, the recommended Debian equivalent:
<nckx>It turned into one of those ‘I'm sorry I asked’ deals rather quickly.
<Kolev>I am fatigued.
<podiki[m]>nckx: I thought there was something more similar sounding, but only say this one (cmake and ld cache)
<Kolev>mako: Failed to connect to user bus: No such file or directory
<lfam>florizhome[m]: To be clear, people "apply for" Git commit access. It's nothing related to debbugs
<mekeor[m]>hey guix. is there something similar to gitlab (particularly regarding CI/CD) that would be easy to write a guix-package for?
<singpolyma>mekeor[m]: you want to package a CI system?
<florhizome[m]>mekeor: People have been wanting to package source hut services. Nix modules exist, so you could look at that.
<florhizome[m]>a guix integration for their ci exists.
<jgart>mekeor[m], there is already laminar
<jgart>mekeor[m], would that interest you?
<jgart>you can also help us package
<florhizome[m]>q :
<florhizome[m]>The shepherd is also just a guile library, right?
<florhizome[m]>so I could test a new service just from the repl?
<jgart>florhizome[m], yes, you should be able to test a service from the repl
<jgart>I haven't done that yet though
<florhizome[m]>that sounds too easy lol
<jgart>but I imagine "in theory" it should be possible
<jgart>same way you can build a guix package from the repl
<florhizome[m]>well you need sudo to start a service
<jgart>then maybe start a repl owned by root?
<jgart>just thinking aloud here
<florhizome[m]>I think you can just load a service
<florhizome[m]>Then you might be able to start it
<florhizome[m]>I have been reading a lot about the different init systems
<florhizome[m]>shepherd is just left out in these discussions..
<florhizome[m]>guix doesn’t document very well how it uses shepherd, why it’s good and how it fares in respective to others
<florhizome[m]>„It’s all just guile“ is pretty nondescriptive for ppl who are not v interested in guile
<lilyp>"It's all just Guile" is nothing but our plug towards people who are already invested in Guile/Guix.
<lilyp>Shepherd does have its own history dating back to ye olde thymes.
<lilyp>And a manual, albeit a sparse one.
<lilyp>In terms of features though, it gets overshadowed by systemd which is why it's in a weird spot.
<lilyp>A lot of peeps who have a weird hate boner for systemd would happily erect that for shepherd if they knew about it.
<drakonis>shepherd is hurd's init repurposed for guix usage
<drakonis>which is cool and fun
<the_tubular>I like seeing guix-home config here. It gives me a lot of ideas :)
<guser__>Hello, someone have problems after upgrading glibc to 2.33 ?
<the_tubular>I'm excited to see the first emacs config made entirely with guix-home
<the_tubular>I also have a very little bash snippet that I should work on with guix-home
<guser__>there is a way so I can perform a mass reinstall on packages? Idk my system is not consistent anymore
<drakonis>not consistent?
<guser__>yes it segfault when running tmux even if a remove and reinstall it
<drakonis>guix pull?
<guser__>If i downgrade glibc it segfault most of binaries, like ls, etc
<drakonis>what's your config mind you?
<guser__>Im very noob guix user, Its all default but I have a lot of packages installed
<guser__>I just used "guix install, guix remove and gc sometimes
<drakonis> please paste it here
<guser__>also performs guix system reconfigure , after sometime
<guser__>YOu mean my /etc/config.scm ?
<drakonis>yes, sure.
<drakonis>also did you try upgrading everything instead of upgrading one package at a time?
<guser__>yes I always did like a i see when installing the system at the first time
<guser__>guix pull and later guix upgrade
<guser__>wait ai will upload my config
<drakonis>that does certainly look quite normal.
<guser__>Yes I just remeber to change this file one time since i installed GuixSD
<guser__>it was just to include cups
<drakonis>are you installing the glibc library to your user environment?
<guser__>but was lots of months ago
<drakonis>i don't think it might be a wise choice?
<guser__>I had it installed since a long time, it never presented problems untill it reached 2.33
<drakonis>try uninstalling glibc and logging out?
<guser__>Also, removing it is a good idea
<the_tubular>If you try and guix weather are the packages the same as in the build farm ?
*nckx cannae parse.
<Kabouik>If I run `guix environment blah`, where is the `blah` executable? I looked into the dir defined into GUIX_ENVIRONMENT but it's not there
<Kabouik>I know guix environment is deprecated but there's no guix shell in the Guix package manager I could install from Debian repositories
<nckx>Kabouik: It's in $PATH.
<Kabouik>But where exactly? My $PATH includes /gnu/store/xxx/sbin but `blah` is not there
<nckx>Does blah provide a bin/blah or sbin/blah?
<SeerLite[m]>Note that you need --ad-hoc to get the actual executable. Old guix environment gives you the inputs instead of the binary by default
<nckx>guix environment hello won't give you hello.
<nckx>By design.
<nckx>the_tubular: Could you rephrase?
<Kabouik>Ok, thanks. Yeah exactly, I was used to guix shell on my GuixSD test machine, but here I only have guix package manager on another machine and it seems to be an older version with just environment
<the_tubular>I was wondering if he built the package or used substitutes.
<nckx>guix weather never builds.
<nckx>(Nor download substitutes.)
<nckx>It checks whether substitutes are available from any of the given or default substitute servers, that is all.
<nckx>the_tubular: OK, I get it, never mind.
<the_tubular>Ohh I had guix challenge in mind I think
<Kabouik>By the way can I upgrade guix package manager from guix package manager, if the version in the Debian repo is old and does not include shell subcommand?
<nckx>I thought it was a general question.
<the_tubular>Nah, I'm only lurking to copy people's config ;)
<nckx>Kabouik: You should always be able to ‘guix pull’, and this will put an up-to-date guix in .config/guix/current/bin, but you will have to ensure that is at the front of your $PATH somehow.
<Kabouik>`--ad-hoc` was the key SeerLite[m], thanks
<Kabouik>I'll try that nckx!
<nckx>the_tubular: I didn't realise you were asking a person and not the room, and got all kinds of confused…
<the_tubular>Ohh alright ^^
*nckx ‘it's late’.
<the_tubular>sigfault are scary
<the_tubular>I was just trying to help
<Kabouik>Currently `guix` installed from Debian repo is in /usr/bin though, so if I understand well, I should use it temporarily just to `guix pull`, then add `~/.config/guix/current/bin` to my PATH, after which I can uninstall the old version from Debian repos. Is that correct?
<the_tubular>But I've never been able to fix my own sigfault so I shouldn't help people with theirs :(
<nckx>Yeah, it reminds me of the bad old Exherbo days when I managed to get into a similar state with glibc. A forgotten static binary saved the day but not until I'd panicked the legally required amount.
<the_tubular>Yeah messing with glibc is spooky
<jlicht>hey guix!
<drakonis>guser__: removing glibc improved anything?
<drakonis>jlicht: ahoy!
<nckx>Kabouik: For example, but it's likely that the /usr/bin version is currently providing the daemon service.
<nckx>Hi jlicht.
<jlicht>Kabouik: stalking you via the online logs, but don't remove the debian provided guix!
<Kabouik>Ha! Why?
<jlicht>as n_cks mentioned, you will be removing your guix daemon ;-)
<Kabouik>I actually was not aware there was a daemon and am not fully sure of what it does
<Kabouik>I thought there was just the guix command to invoke the package manager
<Kabouik>Which obviously was wrong
<jlicht>it manages package builds and garbage collection among other things
<jlicht>if it changes something in /gnu/store, it goes through the daemon
<Kabouik>I see, and is that not an issue if it's an old version while the package manager is updated thanks to guix pull?
<Kabouik>For instance, will it correctly garbage-collect for the shell subcommand that is not available in the guix version provided in Debian repos?
<jlicht>usually, not really. There are some exceptions, specifically with a recent bug fix w.r.t. a problem with the giant texlive substitute (if I'm not mistaken). Generally the daemon is pretty stable though.
<jlicht>the gc process should be independent from any 'guix client' considerations, such as `guix shell`.
<Kabouik>Okay, I was wondering
***lukedashjr is now known as luke-jr
***califax- is now known as califax
***aya is now known as gyara
<apteryx>cbaines: correction for the 14 days I mentioned about sorting out our IO problems on Berlin, it's rather 40 days, and that's a worst case scenario.
<gnoo>how do i view the status of dhcp-client-service-type? herd status {dhcpd,isc-dhcp,dhclient,dhcpcd} does not work
<PurpleSym>podiki: Sorry, I’ve been sitting on your xmonad patches. I was going to revise your patchset, so it creates xmonad-next. If you want, you can do it yourself too.
<podiki[m]>PurpleSym: no worries! very late here so I'm off for now, but if I have a chance tomorrow to revise them I will (I'm back at my main guix computer so i can try to use it too)
<PurpleSym>Alright, have a good night!
<podiki[m]>thanks! have a good day/night too
<utkarshsingh>How can we share screenshots?
<mothacehe>hola guix!
<jgart>utkarshsingh, google drive? jk
<jgart>utkarshsingh, maybe
<utkarshsingh>jgart: Thank you, got it!
<utkarshsingh>I'm currently using Guix with GNOME, and even though I'm using GDM, I'm being presented with login through TTY. Is this desired?
<gnoo>ice-9/boot-9.scm:1685:16: In procedure raise-exception:
<gnoo>error: ungexp: unbound variable
<utkarshsingh>Screenshots: <> and <>
<rekado>gnoo: you need to include the (guix gexp) module
<gnoo>what causes the above errors?
<gnoo>thanks, rekado
<rekado>utkarshsingh: gdm may not be able to start.
<utkarshsingh>rekado: Yes! There is delay to start GDM, due to various failing services.
<ytc>hello. i'm using gnu guix system with linux-libre-lts kernel on librebooted x200.
<ytc>but my ethernet driver isn't working. (Intel 82567LM Gigabit Network)
<ytc>how can i solve this? is there anybody who has the same issue?
<ytc>i know this isn't about guix itself. but i thought i could find x200 users here.
<rekado>utkarshsingh: the GDM account logs to files in /var/lib/gdm, I think. Maybe look around there.
<rekado>ytc: does anything appear in the system logs? e.g. dmesg or /var/log/messages?
<ytc>rekado: [ 3.838589] e1000e 0000:00:19.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
<ytc>e1000e is the module that should be working.
<civodul>Hello Guix!
<sneek>Welcome back civodul, you have 1 message!
<sneek>civodul, notmaximed says: git-fetch patches appear ready according to zimoun and me:
<mothacehe>hey civodul!
<rekado>ytc: this log entry doesn’t look bad to me.
<rekado>ytc: does the network interface show up in the output of ‘ip a’?
<ytc>rekado: there are just "lo" and "wlp2s0".
<rekado>hmm, odd
<ytc>are you using x200 too?
<rekado>I used to have an x200s
<rekado>its backlight melted down and shortly after that it came apart at the seams.
<rekado>but I really really liked that machine
<rekado>worked fine with Guix System.
<ytc>this is a kernel problem. i've once seen e1000e module was loaded in an old kernel (4.xx) while testing slackware.
<rekado>ytc: you can change the kernel in your operating-system declaration and reconfigure
<rekado>we have a few kernels you can pick from
<rekado>take a look at (gnu packages linux) for a selection
<ytc>but i would be embarrassed if i report a bug for a 14 year old laptop.
<rekado>or I guess: guix search linux-libre
<rekado>don’t be embarrassed about that
<rekado>I still have a Thinkpad T60 in active use
<rekado>these are great machines
<rekado>would be a shame not to use them until they give up
<rekado>civodul: it’s been a while since our last CI infrastructure hackathon, but there are still a few issues that keep the aarch64 build nodes on my desk. Should I describe the issues I need help with on guix-devel or should I open issues for each of them?
<gnoo>how can i use a file provided by a package in /etc/example.confg as an argument to (config-file)?
<rekado>I like these guys, but I think I need the desk surface for other clutter soon. The broken headphones in wait of repairs also deserve a more central spot on my desk.
<ytc>rekado: how can i set the 4.4.297 kernel in the /etc/config.scm file?
<rekado>ytc: you can add the (kernel …) field and provide the name of the variable bound to that version
<rekado>I see 4.4.298 in my version of Guix; that’s bound to linux-libre-4.4
<rekado>so (kernel linux-libre-4.4) should be enough
<rekado>you may also need to import the module defining it, so add (use-modules (gnu packages linux)) to the top of the file.
<rekado>good luck with these changes! I gotta go now
<attila_lendvai>is anyone using qbittorrent? since the c-u-f merge it's not working in a weird way: can connect to the trackers, gets a peer list, but peers are constantly showing up and getting immediately dropped from the peer list of the running torrents
<attila_lendvai>i mean, probably, because there's no new torrent blocking happening, and the issue start about the same time
<utkarshsingh>rekado: Yes, this might be of some interest: <>
<utkarshsingh>From /var/log/gdm/greeter.log
<ss2>hello, I recently submitted a patch to get plugins in Thunar working: I’m still trying to figure it out. It looks like that thunar can’t find the plugins, but XDG_DATA_DIR looks fine, and when installed, the plugins are in the thunarx-3 directory. Don’t know further.
<attila_lendvai>hrm, my ssh-agent keeps respawning as observable from constantly showing up on a new pid
<attila_lendvai>damn, scratch that, user error (it was the grep)
<federico>hello guix!
<civodul>hi federico!
<civodul>mothacehe: "guix system vm" produces "-m 2048" now (i think it was "-m 512" or so before, no?)
<mothacehe>uh that's debug leftover sorry
<attila_lendvai>civodul, yep, i've seen that in a diff
<mothacehe>i'll fix it now
<civodul>no big deal, but i think it's better to keep reasonable defaults
<civodul>that'll give us a warning when Guix starts demanding too much :-)
<mothacehe>hehe, right. Fixed now :)
***jetomit_ is now known as jetomit
***federico is now known as fproverbio
<fproverbio>civodul: i forgot to change the nick :)
<fproverbio>did anyone experience any segfaults with qemu-system-x86_64 after running "guix system vm"? i don't know if it's the "-vga qxl" option that's causing it or not
<fproverbio>for reference i usually generate a vm from a custom configuration file (i'm trying to use it as a disposable browser with no access to /home/
<mothacehe>fproverbio: no segfault here, probably something to report on bug-guix ml
<fproverbio>to be fair, spinning up virtual machines with virt-manager works fine
<fproverbio>if i call "$(guix system vm browser.scm --image-size=10G) -m 4096 -enable-kvm -vga qxl" it segfaults after going through gdm login
<mothacehe>qemu itself is segfaulting?
<fproverbio>i'm trying to replicate the issue i had yesterday
<fproverbio>one sec
<fproverbio>mothacehe: nevermind, works fine after a garbage collect
<fproverbio>if i encounter the problem again i'll file a bug report
<jpoiret>i've had some segfaults here and there i think
<fproverbio>jpoiret: same here, cannot replicate the issue now, i've tried three times with three gc before issuing the command
<roptat>hi guix!
<attila_lendvai>FTR, i have reported the qbittorrent/libtorrent issue as
<roptat>looks like %output is not defined when cross-compiling? "Unbound variable: %output"
<roptat>what should I use instead
<civodul>roptat: hi! what build system is that?
<civodul>%output (singular) has been somewhat deprecated since forever, it's rarely used
<roptat>in libaio
<civodul>actually there are 351 uses of singular %output
<civodul>anyway, you can work around it by using (assoc-ref %outputs "out") or with a gexp and #$output
<roptat>ah, thanks
<attila_lendvai>FYI, on a fresh install, i can't immediately run guix system reconfigure after a guix pull, because it fails with some error due to swap-space being undefined.
<abrenon>hello guix
<mroh>"System Crafters" just published "5 Reasons to try guix in 2022": ;)
<mroh>wait... only 5? ;)
<cbaines>apteryx, ok, I am interested in where that 40 days number comes from?
<fproverbio>mroh: it creates interest for guix-illiterate people like me :)
<fproverbio>well 34 minutes, i didn't expect this
<daviwil>mroh: It's just a number that sounds good in a title :)
<daviwil>Thanks for sharing it!
<roptat>civodul, so it may work but libaio has >5000 dependents...
<civodul>roptat: then you can probably make it conditional on cross-compilation
<civodul>as in: ,@(if (%current-target-system) ...)
<roptat>not very clean ^^'
<civodul>that's the trick to avoid rebuilds, but yeah!
<civodul>mroh: oh fun!
<civodul>daviwil: well done :-)
<attila_lendvai>wrt licencing: can i just grab a patch from nixos and add to guix?
<daviwil>civodul: Thanks! Planning to do a lot ofn
<daviwil>Argh, phone keyboard
<daviwil>anyway was trying to say I'm planning to do a lot of Guix promotion this year :)
<mroh>\o/ thank you!
<civodul>daviwil: very nice, much appreciated! :-)
<roptat>attila_lendvai, probably, what's the license on that patch?
<attila_lendvai>roptat, nothing. it's the packaging of an app (gpaste).
<vldn[m]>mhh my guix trys to build wine but guix weather shows that subs are avaiable?
<roptat>so it's the license of nixos
<attila_lendvai>roptat, which means, it's ok, right?
<roptat>I think so, but you need to add a comment/proper license
<fproverbio>daviwil: good video! just finished it
<fproverbio>daviwil: from my perspective of a newbie, it is often hard to grasp the true power ad flexibility of guix, thus the "now what?" video idea is very appreciated ^^
<monadgauge>does guix home have support for systemd services on a foreign distro? the manual seems to imply that the answer is no, but i'd like to make sure
<roptat>no, it's very new it doesn't support a lot of stuff yet
<roptat>although it can still install arbitrary files in your home, so you could do that to manage systemd configuration
<attila_lendvai>roptat, the nixpkgs repo is marked as MIT. what does "add a comment/proper licence"? is it enough if i mention these facts in a comment in the .scm file?
<attila_lendvai>or shall i just quietly proceed and not make life harder for anyone...? :)
<roptat>if it's a .patch file, add it as a comment at the top of the file, otherwise add a comment to the .scm file before the instructions you copy, with a link to the original
<attila_lendvai>roptat, ok, got it, thanks!
<monadgauge>roptat: thanks!
<attila_lendvai>the unpack phase includes the applying of the (patches ...) entry, right?
<daviwil>fproverbio: Thanks! It's also very hard to summarize the value of Guix to other people because it can serve so many purposes. The best one can really do is try and demonstrate the functionality to help it click for people
<civodul>monadgauge: also, "guix home" allows you to run Shepherd services, whether or not you're on Guix System
<monadgauge>civodul: interesting, can these services interfere with the foreign distro ones? i'm not very well versed in this side of system management
<civodul>monadgauge: no, unless of course you're running the same service twice, for instance
<cbaines>civodul, I spotted in the maintainer meeting notes that you're looking at adding hardware to bayfront. Is there a plan for what to do with that new storage?
<civodul>cbaines: hi! the top priority will be backups, so we can manage more or less zero downtime for the essential services
<civodul>but before we get there, we'll have to pick storage devices and get them in place...
<cbaines>civodul, do you have an estimate of how much storage space is required for those backups?
<civodul>cbaines: i don't have that offhand, is it in the minutes? (haven't seen it yet)
<civodul>i think we threw some figures during the discussion
<cbaines>There's an increase of 1.3TiB mentioned, but I'm not sure what the baseline for that is
<apteryx>cbaines: 200 GiB used by world rebuilds, at the rate we were doing world rebuilds two weeks ago
<apteryx>and about 9 TiB free
<cbaines>apteryx, and is that 200 GiB space in the berlin store, or guix publish cache, or something else?
<apteryx>cbaines: I'm not sure, but probably mostly in the store
<cbaines>apteryx, ok. So I spotted the 1.3TiB in relation to storage space on bordeaux (which I'm assuming means bayfront)
<cbaines>I'm asking about this mostly as I'm uncertian about the discussion previously in the week, as it seemed like there at least part of a plan to try to serve substitutes from bayfront in some manor (and I'm not sure how that would work)
<roptat>attila_lendvai, no the patches from the origin record are applied before the unpack phase, even before the derivation is started: the source for the package already has these patches applied (guix build -S will already have them)
***stikonas_ is now known as stikonas
<attila_lendvai>roptat, thanks! add-after 'patch was running after the build, so i have changed it to add-before 'build
*attila_lendvai tests gpaste
<lilyp>Does someone know the ETAs for node builds?
<utkarshsingh>Can someone share Guix manual in Info format?
<lilyp>you should have it locally, using `info guix'
<utkarshsingh>lilyp: I want it on an non-Guix system.
<lilyp>With or without installing Guix?
<utkarshsingh>I'm having some difficulties with default desktop system services.
<lilyp>The docs are usually one of the first things built in a checkout.
<utkarshsingh>lilyp: Without Guix, as I'm testing GuixSD in an VM.
<utkarshsingh>I want a copy for my host machine.
<lilyp>And you can't run `info guix' inside the VM, because it's hosed, do I read you correctly?
<utkarshsingh>lilyp: No! Acutally I'm not familiar with Guix and my host machine has a nice custom setup for Info docs through Emacs.
<lilyp>Okay, point taken.
<utkarshsingh>Everthing is fine inside the Guix VM.
<utkarshsingh>I would be really nice if <> can also list Info files.
<lilyp>Haha, yes.
<utkarshsingh>lilyp: Btw, thank you for your work in Common Lisp.
<lilyp>I think the workaround would be cloning the repo on your host, doing bootstrap and configure, then `make info'.
<lilyp>I do work in Common Lisp?
<mroh>utkarshsingh: perhaps, try something like cp $(info -w guix) /pathToYourHostMachine/
<lilyp>👆️ that would also work and give you the most accurate info file
<utkarshsingh>lilyp: Aren't you the author of
<utkarshsingh>mroh: Got it, thanks!
<lilyp>Not even close. From what I can gather from Gitlab, it's a collective of three people, none of whom are me.
<lilyp>Authoring something sounds way more exciting that what I'm doing, which is waiting for node to finish building (:
<utkarshsingh>lilyp: Oops! Apologies then.
<utkarshsingh>Also thank you.
<lilyp>No problem, I'm here to help
<abrenon>I don't know what I did but I think I messed up my guix system
<abrenon>evince won't start anymore, chromium crashed trying to open or even download a mere .csv file (I haven't tried other formats yet)
<abrenon>my install was a bit late on updates, I pulled then reconfigured yesterday, but couldn't upgrade my user's profile packages due to bad weather
<abrenon>(plus the missing package wasn't building locally, and haven't got the time to figure out why)
<lilyp>bad weather meaning substitute availability or meaning your build got hosed in a thunderstorm?
<abrenon>is that supposed to be able to create discrepancies where missing lib versions may arise ?
<abrenon>no substitute availability
<abrenon>(hi lilyp !)
<robin>sneek, later tell utkarshsingh: i think the netfarm author hangs out in #lispcafe, nick 'hayley', fyi (she's also a sicl hacker possibly?)
<sneek>Will do.
<robin>sneek, botsnack
<abrenon>for instance, trying to open evince yields this
<lilyp>abrenon are you currently running GNOME 3, 41, or something in between?
<abrenon>hmmm not sure what you mean, there are probably a couple gnome packages in there but I spawn xfce4-session after logging to GDM, if that answers at least a bit your question
<lilyp>Now that could be part of the issue or at least mask it.
<lilyp>For the record, evince is a user package and xfce in the system, right?
<abrenon>I've done more tests: I can successfully run evince from a guix shell
<abrenon>xfce4-screenshoot is also affected by my weird GLIBC_2_33 not found error
<lilyp>Okay, so you need to complete your `guix package -u'
<abrenon>I'm almost ready to venture as far as to say that chromium crashed when it tried to run the file chooser dialog
<abrenon>what do you mean "to complete" it ? I never ran the thing
<lilyp>that's likely, since the file chooser is also gtk-based
<abrenon>yep : )
<lilyp>you are running into an issue where Guix' isolation is too weak
<abrenon>that's something I hadn't realized: I thought my user profile and system were independent
<abrenon>apparently ^^
<lilyp>yep, they're not that independent
<abrenon>but I'm like… "can that actually happen" ?
<abrenon>I thought it was pure magic and I could rely on it
<lilyp>absolutely, that's why I have everything GNOME in the system
<abrenon>like, yesterday, I spawned a 3 years old GHC repl and that went perfectly fine
<abrenon>and now… ^^
<abrenon>so anyway, had I been able to actually update my user profile, I wouldn't even have seen the issue
<abrenon>but I can't update because one of the program I use hasn't been built on the substitutes farm, and it fails to build here : /
<lilyp>can you use --do-not-upgrade?
<lilyp>or if you have manifests, pin the evil package with inferiors
<abrenon>I could… do that ?
<abrenon>so I have to upgrade, but actually not : S
<abrenon>it's really a matter of rebuilding the profile with the right dependencies ?
<lilyp>you want the gtk stuff to match system gtk
<abrenon>makes sense : )
<lilyp>everything that you don't upgrade will still be broken
<robin>(never heard of utena or telekons though they sound interesting...utena sounds a bit like spritely goblins perhaps -- network-transparent ocap security for racket and guile)
<lilyp>I know evince is not in that list and I hope chromium will not be either
<abrenon>hehe no it was just tiny little gtg (Get Things GNOME !)
<abrenon>and when I saw that I thought: well, how heavy can that be ? I'll just build it
<abrenon>and then I was sad
<lilyp>You're welcome to submit a patch to update it (assuming it still works with GNOME 41)
<lilyp>A lot of extensions also broke; I fixed some of them.
<abrenon>that's nice (but also a little bit optimistic of you, I fail to understand the error message and how it can make sense with the files left in /tmp with a build -K)
<abrenon>wait, how does one use --do-not-upgrade ?
<abrenon>I've done guix package -m desktop.scm --do-not-upgrade=gtg and it still fails because of "gtg-0.5"
<lilyp>for manifests, you need to specify the old gtg as an inferior package
*abrenon is reading about inferiors
<abrenon>: )
<abrenon>(that can't combine ?… ^^)
<lilyp>(or you could just comment it out for now, because it's broken)
<lilyp>you can, but then you'd have to use the `guix upgrade' command
<abrenon>"a separate GUIX process" ?… that sounds like too much work, you're right I?ll just comment it out
<abrenon>it's building texlive-texmf
<abrenon>should I brace myself ?
<lilyp>nah, texmf is fine
<abrenon>…and huge : )
<abrenon>it doesn't show in guix weather though, why is it building locally ?
<apteryx>Hello Guix! what does kill -0 do? I'm trying to debug this Shepherd test failure:
<civodul>apteryx: it's like kill(2) with 0 as the signal number: it allows you to test whether a process exists
<civodul>oh, and hi!
<abrenon>hi civodul
<civodul>abrenon: texlive-texmf is from the monolithic 'texlive' package, it's huge
<civodul>the recommendation is to use the "modular" texlive, i.e., 'texlive-tiny' + all the texlive-* packages you many need
<civodul>the difficulty lies in finding which package brings what you need...
<abrenon>which is why, out of lack of time and utter cluelessness, I gave up and installed "the whole thing"®
<lilyp>Is modular texlive possible now?
<jpoiret>is fixing the "Error in finalization thread: Success" worth the patch?
<lilyp>It was broken for pretty much everyone before the big merge
<nckx>Who here hates our traditions?
<apteryx>civodul: thank you (and hello!)
<nckx>Morning Guix.
<apteryx>jpoiret: yes, please
<abrenon>morning nckx
<jpoiret>i'm saying this because i ran into the same exact thing while working on the installer and now know how to avoid it
<nckx>jpoiret: Sounds good. Which patch is that?
<jpoiret>none yet :)
<apteryx>jpoiret: awesome, and thank you for working on the installer!
<jpoiret>although, warning: it needs to call a C-only libguile function through foreign-library-function
<abrenon>lilyp thank you very much for your help ! graphical applications stopped failing after the upgrade completed
<abrenon>now I can start wondering about why gtg fails
<apteryx>civodul: to find what packages are needed perhaps 'tlmgr' from texlive-bin can help
<apteryx>you can query the texlive database for things
<abrenon>but not today unfortunately
<abrenon>apteryx: thanks for the tip !
<abrenon>bye everyone !!
<nckx>I missed the beginning. Was that basically <> again?
<jpoiret>why would glibc not work properly compared to other dynlinked libraries in Guix?
<apteryx>civodul: so 'kill -0 $pid' is some kind of poor man's 'waitpid' (combined with a loop) for shell?
<apteryx>I'm not totally sure of its purpose in Shepherd's test/ while ! test -f "$pid" ; do kill -0 "$shepherd_pid" ; sleep 0.3 ; done
<nckx>jpoiret: I wonder the same thing.
<nckx>Glibc is ‘special’, sure, mostly for legitimate reasons, but I don't see why it should be a priori unguixable.
<apteryx>glibc has this plugin concept that can break, but I thought that should covered for on Guix System by our use of the nscd daemon.
<apteryx>so that loop in the shepherd's test is waiting for shepherd to create the pid file, and kill -0 "$shepherd_pid" must be used to fail in case shepherd crashed
<apteryx>(to avoid waiting forever)
<apteryx>I guess these tests shell scripts run with 'set -e'
<rekado>lilyp: modular texlive has been working for years.
<rekado>it’s been broken with the texlive upgrade, but that’s fixed on wip-texlive
<rekado>I’d like to accumulate some more fixes there before building it all out and merging it back into ‘master’.
<rekado>if there’s a problem with the modular texlive on that branch I’d appreciate bug reports and patches.
<civodul>apteryx: we could use the shell's 'wait' builtin instead, but i think there's no way to have it time out after some time as passed (so it'd wait forever if the feature under test is broken)
<civodul>the purpose of the "while" loop you mention is to wait for the PID file to show up and to terminate if the shepherd process died without writing its PID file
<civodul>(remember these tests run with -x)
<cbaines>mdadm-static seems to fail to build, this might relate to the recent changes in the mdadm package
<sash-kan>hi all! i want to build gcc for hurd:
<sash-kan>what am i doing wrong?
<jpoiret>can you try the `gcc-toolchain` package instead? i'm not sure this is the cause of the error
<nckx>cbaines: Downgrading mdadm to 4.1 ‘fixes’ the ld error :-/ I'll try to not do that, first.
<civodul>sash-kan: the "gcc-toolchain" package is not amenable to cross-compilation, but the underlying "gcc" is (i know, it's confusing)
<civodul>concretely, this works: guix build --target=i586-pc-gnu -e '(@ (gnu packages gcc) gcc-10)' -n
<civodul>(the result is a native GNU/Hurd compiler)
<apteryx>civodul: I think you meant run with '-e' (exit on error), but yes, I understand now, thanks!
<apteryx>would someone know of a way to induce a high load on my system (CPU) in an attempt to reproduce a nondeterministic problem that I suspect is related to load?
<apteryx>a stress test or perhaps some Linux-specific trick to fake busy-ness
<rekado>I often found myself wanting to use search-input-file, but I’d like to specify a concrete input and not search for a file among the union of inputs
<rekado>do we have something like that?
<apteryx>(string-append (this-package-input input) "/some/thing") ?
<apteryx>with the G-Expness taken care of
<cbaines>nckx, cool, thanks for looking in to it, I only got as far as being confused by the gexp related issues
<sash-kan>civodul: thank you! it works.
<cbaines>apteryx, the stress package may help
<nckx>cbaines: Those were relatively straightforward to fix but I'm stuck at <>
<robin>cbaines types faster than me :) seconding 'stress'
<nckx>I don't even see the error. By the way, this is what success looks like. To me: identical:
<nckx>Ah, LDLIBS += -ludev
<apteryx>cbaines: thanks!
<robin>(there's an unpackaged 'stress-ng' as well but no idea what the differences are)
<rekado>apteryx: I want it to fail when the second argument to string-append doesn’t exist
<rekado>that’s what I appreciate about search-input-file
<nckx>cbaines: Fixed!
<civodul>rekado: (search-input-file '(("whatever" . #$(this-package-input ...))) ...) ?
<civodul>not pretty
<apteryx>would file-append do this? I don't think it fails when the file doesn't exist, right? Perhaps it should?
<apteryx>that'd be a big incompatible change though, so probably no.
<civodul>maybe it should, but it can't :-)
<apteryx>file-append* could ;-)
<civodul>i mean it cannot do that until the thing is built
*nckx greans.
<nckx>*oans, even.
<nckx>IWBN if not yet another thing would be added to the already very long list of things.
<civodul>too many things!
<nckx>We are adding (very pretty, useful) tiles to our doorstep, one tile at a time.
<apteryx>cbaines: I was also pointed to stress-ng:; we don't seem to have that one packaged though.
<cbaines>nckx, awesome, thanks
<xelxebar>Uhhh, guix pull is segfaulting on me :/
<xelxebar>building /gnu/store/2cl2hiz6c0q2sxm328bkj0ck1hqr9i2d-compute-guix-derivation.drv...
<xelxebar>Computing Guix derivation for 'x86_64-linux'... -guix pull: error: You found a bug: the program '/gnu/store/q36qxlh76jr9ip84rlmrfkskg0628gcr-compute-guix-derivation'
<xelxebar>failed to compute the derivation for Guix (version: "2860bb2779dbc557ab5362b531d9f497f34b41d8"; system: "x86_64-linux";
<xelxebar>host version: "9235dd136e70dfa97684aff4e9af4c0ce366ad68"; pull-version: 1).
<xelxebar>Please report the COMPLETE output above by email to <>.
<xelxebar>(Sometimes it gets as far as that though)
<apteryx>xelxebar: is it reproducible?
<xelxebar>apteryx: Sort of? Attempting to pull about 7 times, 2 of those gave the above message and the other five all segfaulted.
<nckx>apteryx: Is that the Launchpad one? I think I have a package for that…
<apteryx>upstream is this:
<nckx>~cking was what I was thinking of, that's the one.
<irfus>xelxebar: do you have any external channels enabled?
<civodul>xelxebar: FWIW "guix time-machine --commit=2860bb2779dbc557ab5362b531d9f497f34b41d8 -- describe" works for me on x86_64-linux
<civodul>where do you see a segfault BTW?
<nckx>I also just pulled successfully.
<nckx>With a few channels.
<xelxebar>I have a couple extra channels. It segfaults right after "Updating channel ..." on each of those.
<nckx>If this is another glibc@2.33 issue I'm going to groan again. You don't happen to have glibc explicitly installed anywhere (e.g., guix package --list-installed)?
<civodul>xelxebar: could you grab a backtrace from gdb and post that along with the complete output of the command?
<xelxebar>nckx: No glibc installed explicitly
<xelxebar>civodul: Was actually working on that, but now the pulls are succeeding...
<nckx>The bastards.
<xelxebar>Official fix: Attempt to gather troubleshooting info.
<xelxebar>Speaking of annoying bugs, I discovered that shepherd triggers a kernel panic if /etc contains symlinks/files at paths where it wants to create symlinks.
<nckx>Sorry for not reporting that yet but I ran into it this week and had other priorities, like getting the server back up.
<nckx>You can boot with --repl and delete each offending existing file but it's tedious.
<nckx>The activation service.
<nckx>And shepherd's lack of service isolation and subsequent exit leaves the kernel without a PID 1.
<xelxebar>Oh, good. It's a known issue :D
<lilyp>Is there a `guix graph' tool to find every package that has e.g. gcc as input?
<lilyp>Or to be more useful a gcc newer than gcc 10 :)
<apteryx>that'd be 'git grep' ;-)
***iyzsong- is now known as iyzsong
***jetomit_ is now known as jetomit
<lilyp>well, my use case is somewhat different
<lilyp>it's something like `guix refresh --full --grep REGEXP'
<lilyp>where full gives me the full list of dependents
<jpoiret>(guix build utils) doesn't export &invoke-error :(
<mikko>possibly a stupid question but how do i get sort of the base configuration that i can start editing? i'm just trying out guix with the provided QEMU image so i sort of skipped the installation step, and it seems there is no /etc/config.scm
<gnoo>there should be in ~/.cache/guix/checkout(s?)/...
<jpoiret>you can find one at /run/current-system/configuration.scm
<mikko>ah, thanks
<gnoo>okay so it was in ~/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/gnu/system/examples
<gnoo>tremc package looks broken
<gnoo>i click on a torrent and it like, exists? or something in between?
<nckx>Does it log anything?
<gnoo>`find' doesn't show anything so probably not, i'll try a screenshot
<nckx>But nothing to std{out,err} if you run it from a terminal?
<gnoo>it's a tui program
<nckx>I use it.
<gnoo>oh, ok
<nckx>Maybe mine is outdated.
<nckx>I mean, it definitely is :) I mean maybe that's why it works.
<gnoo>from the stdout
<nckx>decodestring is deprecated.
<gnoo>and after it crashes, the terminal needs to be closed or it won't work properly
<nckx>Here we go:
<nckx>I'll apply it.
<gnoo>also, do you think guix could have transmission that supports serial downloading? not enabled by default, of course, just for some selected torrents
<gnoo>there's patch from over 10 years so it might not apply at all >_>
<nckx>You could submit a patched transmission-serial variant to guix-patches@, whether it will be accepted is up to the reactions.
<nckx>Personally, I'm a bit hesitant.
<podiki[m]> did we get a spam? we're not driving traffic!
<gnoo>i think it's a nice addition
<nckx>podiki[m]: Wonderful.
<podiki[m]>but they give us their word with their help we can turn it around! I got a chuckle at least
<nckx>Hm, how do we close this without pinging them :-/
<nckx>Can we?
<nckx>gnoo: Can you update tremc & try again? I can't do so at the moment.
<gnoo>ok, running guix pull,
<podiki[m]>someone with debbugs access can directly remove it maybe? or alter the author address? not sure what they would do wit the automated closure email they would get
<nckx>I've sent that question to help-debbugs@. Please nobody respond to
<nckx>Oh, coincidence.
<nckx>Enjoy my relevant reply!
<nckx>The debbugs moderation situation is atroshe.
<nckx>I.e., there really is none. I can reject messages sent out to subscribers, but the tracker & Web UI sit *before* that filtering.
<The_tubular>podiki[m] wtf is that issue lol
<podiki[m]>yeah I was curious about that appearing on issues frontend when other lists are moderated first for new posters
<nckx>So are these. It's silly.
<podiki[m]>(I do enjoy that front end though)
<nckx>So I just logged into the admin interface, there it was, waiting. I discarded the mail and added the sender to the naughty list.
<nckx>podiki[m]: Not ‘our’ (Guix) front-end. My gripe applies to, which issues.guix just mirrors with a lot of lipstick.
<gnoo>transmission-daemon is producing this line a lot, is it normal? IPv4 DHT announce failed (firewalled, 269 nodes): Invalid argument (tr-dht.c:737)
<nckx>I think so gnoo, but ask in (a hypothetical) #transmission if you need an authoritative answer.
<podiki[m]>nckx: gotcha. it is a good shade of lipstick to boot.
<The_tubular>Is adding an emacs package to guix hard ?
<nckx>podiki[m]: Agreed.
<gnoo>The_tubular: you can look at existing emacs packages in repos
<The_tubular>Yeah, that was my plan. but my guess was that it would be easier than any compiled program
<gnoo>there's a emacs-build-system so it looks easy
<gnoo>try 'guix edit emacs-helm-pass', i don't use it but that was the first one i found
<podiki[m]>there's an elpa importer too (with support for melpa too), but I haven't tried it
<podiki[m]>`guix import elpa -a melpa <package>`
<gnoo>nckx: it works! thanks.
<The_tubular>"elpa -a melpa" ... ?
<gnoo>The_tubular: elpa is a generic name, melpa is also an elpa archive
<The_tubular>I know that, that syntax looks weird though
<gnoo>-a just specifies which one to use, gnu elpa or nongnu elpa or melpa or melpa-stable
<gnoo>see (info "(guix) Invoking guix import")
<podiki[m]>the -a is short for --archive
<The_tubular>Got it
<podiki[m]>yes, as gnoo said
<nckx>I think I'll take this moment to randomly point out that guix/contributor/$you! cloaks are a thing for those who want one. Possibly also guix/user/$you! cloaks because why the hell not. Enquire within for details. Offer void where prohibited. Not valid on Palm Sunday. May contain nuts.
<nckx>Don't let civodul hog all the pretty cloaks!
<jacereda>In case anyone is using a macbook with dual GPU, I've submitted to allow switching from the discrete to the integrated GPU. My machine was by default using the discrete GPU and draining the battery in no time. The difference in battery consumption is night and day on my laptop.
<podiki[m]>nice! dealing with turning/on off discrete graphics on my (non mac) laptop was a pain (certain non-free drivers being the problem)
<jacereda>This is only valid for some macbooks mentioned in the README though
<jacereda>In case anyone is willing to review that, please take a look also to as well, that's another missing piece for macbooks
<jpoiret>damned, any change to (guix build utils) would cause a world rebuild, right?
<jpoiret>is using @@ an acceptable tradeoff here?
<lilyp>I missed the discussion, what's the context?
<nckx>So (thank you, staff) but I'll give it another while, but I wonder if Guix's front-end assumes that the bug DB is functionally append-only, which feels wonderfully ironic.
<lilyp>maybe it does, or maybe it just caches the results for a long time
<nckx>We will see.
<lilyp>I have to say, though, we need more traffic on our bug tracker.
<nckx>If not, maybe it's as simple as passing --delete to rsync, the advanced back-end powering this product.
<lilyp>We should start writing more bugs just to see that number go up :)
<lilyp>But we need to be careful -- too many bugs and people will hate us and leave.
<lilyp>So let's write an artificial intelligence that automatically injects bugs to maximize tracker contention.
<nckx>We can just quietly start wrapping bugs at #65535, reusing closed/deleted ones. Nobody will notice!
<nckx>(Actually, our bug numbers are for *all of GNU*. Few people realise this. There are no 53,000 Guix bugs, not by far.)
<nckx>I'll rephrase that as ‘few people of the type who write omg you guiz hav 50000 boogs realise this’, as that is the provable claim.
<lilyp>Even if we had 50k bugs, I'm pretty sure there's singular projects that have more.
<lilyp>And that's scary.
<lilyp>As far as it being a frontend to all of debbugs is concerned, I think only Guix users actually know that and make active use of it.
<nckx>I've deliberately avoided passing issues.guix links to non-Guix bugs. It feels… wrong, althoug there's absolutely no rational reason, I know.
<nckx>jpoiret: I think so, but I don't know what you're building. *If* it's something that would make it worth exporting X, *then* it's worth the temporary ugliness of @@, is my reasoning. But only then.
<jpoiret>i'd want to raise &invoke-error in the installer
<lilyp>nckx: Absolutely. "When in Rome" and everything.
<jpoiret>basically, i'm rewriting system* to be able to pipe the output of a command and display it in real time while also logging it
<nckx>I don't know what the policy of using (guix build …) in the installer is. If it's already used—hm, should we go straight for porting to INVOKE here? Or is that too much/too limited?
<nckx>lilyp: Yeah. More s/wrong/rude/, I guess.
<nckx>We're not trying to fork GNU. /me runs.
*nckx really AFK.
<podiki[m]>lfam: thanks for the changes to openrgb and push, still getting the hang of gexps/synopsis/etc.! (for some reason didn't get an email from debbugs)
<rekado>nckx: it’s our rsync invocation.
<rekado>we don’t do --delet.
<rekado>--delete even
<nckx>rekado: OK, just glad it's the obvious for once. Does this invocation exist on disc or only in the fevered history of your screen session? I'd like to learn more.
<nckx>Please subscribe me to your newsletter.
***michel-slm[m] is now known as michel
<jpoiret>nckx: wdym by porting to invoke?
<lilyp>i.e. use invoke rather than system* to make that call
<nckx>I'm not sure if it's a good idea, to be clear, but I don't see any error handling from any of the installer system* calls I casually grepped.
<apteryx>civodul, mbakke: you are now officially released of your Guix co-maintainers' roles!
<nckx>We seem to call system* and then, whelp, that probably worked, on we go.
<jpoiret>oh but I'm replacing all those calls by a new™ run-command-in-installer
<jpoiret>that captures the stdout and stderr
*apteryx hears the distant "psssh" of a cold beer
<apteryx>I couldn't reproduce the shepherd's test issue, even stressing all kind of loads with the 'stress' utility. Hmph.
<apteryx>(the tests/ test)
<jpoiret>hmmm, guix downloading substitutes when its stdout not a terminal is pretty ugly
<jpoiret>getting a lot of dots somehow
<lilyp>it also isn't the best if you decide to resize the window
<civodul>apteryx: yay, thank you! :-)
*civodul goes to web site, books one-way trip to a tropical island
<vivien>You can’t have unicode in store file names :(
<rekado>nckx: you are now subscribed to tree news
<rekado>did you know that the lower branches of conifers support a nutrient-rich layer of canopy soil? That soil supports a unique ecosystem of canopy-dwelling arachnids that cannot be found anywhere else.
<rekado>how do trees know how to grow their roots and branches? A big part of the answer is plant hormones called auxins that accumulate in the bottom half of branches and roots, inhibiting or enhancing growth. It’s little more than gravity and growth hormones!
<rekado>nckx: oh, sorry, wrong newsletter
<rekado>yes, the rsync command is just right there in the root user’s shell history; currently executed in a screen session
<rekado>(you have been unsubscribed from tree news)
<nckx>Aw. I didn't mind tree news. I'm subscribed to worse.
*vagrantc misses tree life
<civodul>apteryx: there's an unresolved "[0]" in :-)
<vagrantc>that tropical island must have good networking access
<nckx>Is it the DFSG island? What a wonderful free-software place it must be.
<civodul>so free!
<civodul>(DFSG or FSDG? hmm!)
<drakonis>DFSG island eh?
<nckx>rekado: I'll let you ‘edit’ it then :)
<nckx>We have collectively decided to maroon civodul there for his own good.
<drakonis>so i've heard.
<rekado>nckx: it is done.
<nckx>Thank you!
<nckx>That was fast:
<apteryx>civodul: oh! thanks for the heads up, I'll fix it
<vagrantc>no GCC manuals on DFSG island ... but interestingly can find them on FSDG island!
<civodul>fortunately, Guile and Guix manuals are on both islands!
<Noclip[m]>Is network access always disabled in the compilation environment?
<vagrantc>otherwise you can inject code from unknown sources
<Noclip[m]>Is that optional?
<vagrantc>accidentally or otherwise ... which breaks the functional paradigm that guix operates under
<vagrantc>it is by design
<sam_>right, it affects determinism, also makes it harder to download things in advance / work in offline environments
<sam_>(which is to do with determinismm)
<Noclip[m]>(I'm aware of the reasons for network access being an issue.)
<jpoiret>it is not optional
<sam_>generally network access is always easier and if it were optional then nobody would do the harder route :p
<vagrantc>the closest thing that would allow you network acccess is doing a manual build of the software via "guix shell"
<Noclip[m]>Is it possible to get anything into the compilation environment without having it's SHA256 checked before?
<singpolyma>Noclip[m]: yes, you can use --with-source
<sam_>sounds vaguely X-Y though
<Noclip[m]>singpolyma: Ah well, I was only referring to the package definition.
<vivien>In (gnu services networking), for the dhcp-client-service-type, I read: ;; XXX: Running with '-nw' ("no wait") avoids blocking for a minute when
<vivien> ;; networking is unavailable, but also means that the interface is not up
<vivien> ;; yet when 'start' completes. To wait for the interface to be ready, one
<vivien> ;; should instead monitor udev events.
<Noclip[m]>As far as I know non-deterministic dependencies aren't checked (cause they cannot be checked).
<vivien>How do I monitor udev events?
<florhizome[m]>I’m not sure if I should report this or just send a patch for the one package that I experienced it:
<florhizome[m]>you can set TERMINFO_DIRS in search–paths so that the terminfo file for a terminal emulator will be definitely found. So far alacrity does this, which means a problem I had with foot was solved by installing alacritty.
<florhizome[m]>this should be relevant for a lot of other terminal emulators though, that have custom terminfos
<nckx>vivien: udevadm monitor?
<nckx>I don't see it logging link events but that might just be me holding it wrong.
<vivien>I’m discovering the program right now :)
<nckx>florhizome[m]: Both are OK. I prefer the patch.
<vivien>OK, let me try to go offline to see if something happens
<nckx>dissent: Does <> happen with the latest Guix master version of tremc?
<viivien>nckx, it seems that udevadm monitor does not care about network events
<florhizome[m]>nckx not today though I just got boosted
<nckx>You're supposed to get boosted in your non-typing arm.
<viivien>Why don’t they boost the legs though
<Kolev>nckx: Everyone's typing arm is the left arm, if they are using QWERTY.
<viivien>Who needs legs to code
<Kolev>viivien: Emacs users.
<nckx>You should learn one-handed Dvorak before you get your shot.
<Kolev>I tried to learn to type with one hand. It is hard.
<nckx>It is! Respect to those who can do it at speed.
<viivien>(and generally not very useful if you have 2 hands)
<cehteh>haha i got my shot in the left arm and next day i coudlnt move the right arm above shoulder height
<nckx>viivien: I'm operating under the assumption that that comment is correct. I'm not personally sure that it is…
<cehteh>.. 3rd day it was as it supposed to be, left arm hurted too
<nckx>cehteh: Excellent troll.
<Kolev>I haven't been able to get a booster shot, but I was down after my regular shots.
<nckx>I had a painful left arm and fell like a used rag for a few days but I was already quite ill before I got shot.
<cehteh>nckx: actually happend, but 3rd day evening it was all ok and gone
<nckx>I meant the shot, not you :)
<nckx>You got trolled.
<nckx>By big pharma.
<nckx>It's all part of their plan to mildly confuse us.
<viivien>nckx, ip monitor seems to better suit my needs
<Noclip[m]>nckx: I don't think I've ever seen that (outside of some hacker-memes ...).
<nckx>I wonder if udev is a typo for netlink.
<nckx>Ah, perhaps we are saying the same thing viivien.
<nckx>I'm not deeply familiar with this stuff.
<viivien>sudo ip monitor | grep REACHABLE seems very nice
<nckx>Yeah, I think this validates my (completely lucky) typo/thinko hypothesis.
<nckx>It uses RTNETLINK.
<viivien>Is it reasonable to herd restart a bunch of services if I get an output in ip monitor?
<nckx>Noclip[m]: Seen what?
<viivien>Or is there a more guixy way to go?
<Noclip[m]>nckx: Seen someone type with one hand.
<viivien>I’m sure there are 1-handed people out there that occasionally use computers
<nckx>Well, the *modern* way would be for these services to dynamically adjust to a changing world, not be configure-on-start monoliths that have to be brought down each time $something changes… It would depend on the service, of course, but it's rather an obselete design premise.
<viivien>If I were to implement a modern service that does that, what API should I use?
<viivien>(my google skills are not sufficient for me to find an answer for that question)
<jpoiret> my work here is (not) done
<jpoiret>by the way, see for the Error in finalization thread: Success workaround
<jpoiret>time to get some sleep now