<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? <dissent>In other words, if I install font-iosevka with guix on debian, can xmonad (installed with apt) see that font? <podiki[m]>maybe a symlink from your home folder fonts (forget the path); fonts shouldn't be too hard <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]>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. <podiki[m]>besides the glibc for /gnu/store/... ld.so.cache 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 <nckx>podiki[m]: Regarding stripping it, apparently. <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 <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 <nckx>podiki[m]: What exactly was the bug report about? Valgrind? <nckx>It turned into one of those ‘I'm sorry I asked’ deals rather quickly. <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? <florhizome[m]>mekeor: People have been wanting to package source hut services. Nix modules exist, so you could look at that. <jgart>mekeor[m], there is already laminar <jgart>mekeor[m], would that interest you? <jgart>you can also help us package builds.sr.ht <jgart>florhizome[m], yes, you should be able to test a service from the repl <jgart>I haven't done that yet though <jgart>but I imagine "in theory" it should be possible <jgart>same way you can build a guix package from the repl <jgart>then maybe start a repl owned by root? <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 <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 <guser__>yes it segfault when running tmux even if a remove and reinstall it <guser__>If i downgrade glibc it segfault most of binaries, like ls, etc <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 <guser__>also performs guix system reconfigure , after sometime <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__>Yes I just remeber to change this file one time since i installed GuixSD <drakonis>are you installing the glibc library to your user environment? <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 <the_tubular>If you try and guix weather are the packages the same as in the build farm ? <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 <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>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. <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. <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 <nckx>the_tubular: I didn't realise you were asking a person and not the room, and got all kinds of confused… <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. <drakonis>guser__: removing glibc improved anything? <nckx>Kabouik: For example, but it's likely that the /usr/bin version is currently providing the daemon service. <jlicht>Kabouik: stalking you via the online logs, but don't remove the debian provided guix! <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 <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`. ***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) <jgart>utkarshsingh, google drive? jk <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 <rekado>gnoo: you need to include the (guix gexp) module <gnoo>what causes the above errors? <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. <sneek>Welcome back civodul, you have 1 message! <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". <ytc>are you using x200 too? <rekado>its backlight melted down and shortly after that it came apart at the seams. <rekado>but I really really liked that machine <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>I still have a Thinkpad T60 in active use <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 <ss2>hello, I recently submitted a patch to get plugins in Thunar working: https://issues.guix.gnu.org/53008. 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 <civodul>mothacehe: "guix system vm" produces "-m 2048" now (i think it was "-m 512" or so before, no?) <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 :-) ***jetomit_ is now known as jetomit
***federico is now known as fproverbio
<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 <fproverbio>i'm trying to replicate the issue i had yesterday <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>looks like %output is not defined when cross-compiling? "Unbound variable: %output" <civodul>roptat: hi! what build system is that? <civodul>%output (singular) has been somewhat deprecated since forever, it's rarely used <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 <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. <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 :) <daviwil>mroh: It's just a number that sounds good in a title :) <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) ...) <civodul>that's the trick to avoid rebuilds, but yeah! <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>anyway was trying to say I'm planning to do a lot of Guix promotion this year :) <civodul>daviwil: very nice, much appreciated! :-) <roptat>attila_lendvai, probably, what's the license on that patch? <vldn[m]>mhh my guix trys to build wine but guix weather shows that subs are avaiable? <roptat>I think so, but you need to add a comment/proper license <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>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 <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 ci.guix.gnu.org 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? <lilyp>you should have it locally, using `info guix' <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. <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>I think the workaround would be cloning the repo on your host, doing bootstrap and configure, then `make info'. <mroh>utkarshsingh: perhaps, try something like cp $(info -w guix) /pathToYourHostMachine/ <lilyp>👆️ that would also work and give you the most accurate info file <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 (: <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 ? <robin>sneek, later tell utkarshsingh: i think the netfarm author hangs out in #lispcafe, nick 'hayley', fyi (she's also a sicl hacker possibly?) <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 <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 <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>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>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 <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 <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 <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 doesn't show in guix weather though, why is it building locally ? <civodul>apteryx: it's like kill(2) with 0 as the signal number: it allows you to test whether a process exists <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? <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? <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 <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/no-home.sh: 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 no-home.sh 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>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 <cbaines>mdadm-static seems to fail to build, this might relate to the recent changes in the mdadm package <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 <apteryx>(string-append (this-package-input input) "/some/thing") ? <cbaines>nckx, cool, thanks for looking in to it, I only got as far as being confused by the gexp related issues <cbaines>apteryx, the stress package may help <robin>cbaines types faster than me :) seconding 'stress' <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 <civodul>rekado: (search-input-file '(("whatever" . #$(this-package-input ...))) ...) ? <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>i mean it cannot do that until the thing is built <nckx>IWBN if not yet another thing would be added to the already very long list of things. <nckx>We are adding (very pretty, useful) tiles to our doorstep, one tile at a time. <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 <bug-guix@gnu.org>. <xelxebar>(Sometimes it gets as far as that though) <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… <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 <nckx>I also just pulled successfully. <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>civodul: Was actually working on that, but now the pulls are succeeding... <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>And shepherd's lack of service isolation and subsequent exit leaves the kernel without a PID 1. <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 :) ***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 <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? <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? <nckx>I mean, it definitely is :) I mean maybe that's why it works. <nckx>decodestring is deprecated. <gnoo>and after it crashes, the terminal needs to be closed or it won't work properly <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. <gnoo>i think it's a nice addition <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>gnoo: Can you update tremc & try again? I can't do so at the moment. <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 issues.guix.gnu.org/53051 <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. <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. <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 bugs.gnu.org/53051, 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. <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 <gnoo>The_tubular: elpa is a generic name, melpa is also an elpa archive <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") <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! <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 <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? <lilyp>maybe it does, or maybe it just caches the results for a long time <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>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. <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. <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
<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. <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 *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. <jpoiret>hmmm, guix downloading substitutes when its stdout not a terminal is pretty ugly <lilyp>it also isn't the best if you decide to resize the window *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 <vagrantc>that tropical island must have good networking access <nckx>Is it the DFSG island? What a wonderful free-software place it must be. <nckx>rekado: I'll let you ‘edit’ it then :) <nckx>We have collectively decided to maroon civodul there for his own good. <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 <vagrantc>accidentally or otherwise ... which breaks the functional paradigm that guix operates under <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.) <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? <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). <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 <viivien>nckx, it seems that udevadm monitor does not care about network events <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. <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>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. <viivien>Is it reasonable to herd restart a bunch of services if I get an output in ip monitor? <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) 
