<the_tubular> uri: #<<uri> scheme: https userinfo: #f host: "ci.guix.gnu.org" port: #f path: "/nar/zstd/jiacvqykx9d32p83iqs1sfqqccgrmi71-emacs-next-29.0.50-1.0a5477b" query: #f fragment: #f> <civodul>apteryx, nckx: looks like we have some nars that disappeared? <civodul>is there a missing mount point or something?... <civodul>things like 10years.guix.gnu.org and hpc.guix.info are unavailable <civodul>my laptop kinda lost IPv4 networking, but not v6, go figure <civodul>just had to give NetworkManager a kick <podiki[m]>ye olde virtual hit the monitor/jiggle the cable/tap the case :) <civodul>the corresponding files are missing in /var/cache/guix/publish as well <podiki[m]>that page says it is being baked, does that mean there is a build for it then? <civodul>apparently people had the corresponding narinfo cached <civodul>apteryx, nckx: could you check /var/cache and related mount points? <podiki[m]>so now it is missing but the narinfo is from when it was being built? <civodul>podiki[m]: currently for the emacs-next example, neither the narinfo nor the nar are available AFAICS <fnstudio>hi, i've built this home-configuration file (which includes glibc-locales) but when i launch it in a container i get the usual cannot change locale error <fnstudio>e.g. "guile: warning: failed to install locale" <fnstudio>and also "warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)" <fnstudio>hm i might be missing "export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale" <fnstudio>the thing is... i thought this was going to be handled automatically by the bash service, but yeah maybe naive of me <fnstudio>export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale <Gooberpatrol66>Does anything seem wrong with this line of code? (for-each install-file (find-files ".") (string-append %output "/bin")) <Gooberpatrol66>it triggers this error: wrong-type-arg "length" "Wrong type argument in position ~A: ~S" <apteryx>if you are in a gexp (#~), you'll want to use #$output <apteryx>I confirm /var/cache is the old one from the previous pool... hence the missing NARs. <apteryx>I've patched that with "mount --bind /mnt/btrfs-pool-san/@cache /var/cache" <apteryx>then running 'rsync -aPHAX /mnt/btrfs-pool-{ssd,san}/@cache' to make sure nothing that got built meanwhile is missing <apteryx>which package provides the 'gsettings' command? <xelxebar>There has been discussion a few times about a mechanism for providing a reverse search function from files to package names. <xelxebar>Is there something concrete in the works, or is that still in a "brainstorm" state. ***iyzsong-alt is now known as iyzsong
<Salthazar>Hey! anyone know where cargo build flags should go in guix package definitions? <purism>Having a sudden issue: guix install: error: corrupt input while restoring archive from socket <podiki[m]>a random guess, but maybe try again (network/errors with substitutes always look weird to me so maybe that is it) <purism>I'll keep giving it a go, but i've tried this probably 4-5 times now in the past 24 hours. <purism>I think you might be on to something though <purism>I am on a librem 5. It can be rather slow <purism>I should also mention, after this failure, all attempts to use guix result in this error: 'guix install: error: failed to connect to `/var/guix/daemon-socket/socket': Connection refused' <apteryx>what does 'herd status guix-daemon' says as root? <Salthazar>Anyone succesfully used the guix emacs package? <Salthazar>is that with guix on a foreign distro? I always have had issues opening the guix repl <Salthazar>I'm loving the guix + emacs experience though, would be nice to have the guix package working <iyzsong>i use guix system too, and installed emacs and emacs-guix both via guix, with that emacs config it works. <iyzsong>um, emacs-guix doesn't work now for me too... got symbol is void: geiser-repl-company-p <zamfofex>Hello, Guix! I’ve just started to investigate bringing LLVM 15 to Guix, and I’ve noticed an oddity in Guix’s packaging that supposedly explains an issue I was having with Clang in the past. <zamfofex>In particular, the patch for Clang (to remove distro‐specific brnaching in Clang) seems to also make it ignore ‘--sysroot’, at least partially. <zamfofex>Or rather, the parts of the patch that are meant to make it avoid looking into *supposedly* absolute file names. <zamfofex>Though explicitly cherry‐picking out the distro logic out that way also feels redundant, given that it already changes ‘DetectDistro’ to return ‘UnknownDistro’. <zamfofex>I feel like, ideally, it would pass in ‘-DDEFAULT_SYSROOT=...’ to cmake at compile time, and keep Clang’s logic for dealing with the sysroot intact. <zamfofex>Though unfortunately, I don’t think Clang supports multiple sysroots to be passed in or provided as default, which is necessary in Guix because glibc and GCC are at different directories. <zamfofex>Does that all make sense? If there is anyone who is more familiar with the LLVM and Clang here, feel free to correct me. 🙂 <efraim>well I successfully created an image for my pinebook pro and was able to login using the TTY but SDDM wouldn't let me in <abrenon>I liked your monad tutorial with lists and maybe <jpoiret>someone used the installer dump feature for the first time! woot <mothacehe>it worked nice ... but revealed two painful issues <jpoiret>abrenon: instead of sending jpg pics of truncated backtraces, the installer can generate a gzipped directory containing installer logs, dmesg output and the like <mothacehe>when the installer fails, instead of just displaying a backtrace that is hard to report, there is a mechanism to update different files on a server <abrenon>(I didn't know there was a way to generate jpg pics of the failures anyway ^^) <abrenon>ok, so now we have a "phone home" feature ; ) <jpoiret>mothacehe: what are those two issues you're talking about? <jpoiret>i just quickly looked at my mails, i'll have a deeper look later <jpoiret>i was planning to look at the whole http stack today <mothacehe>second is the final phase is restarted there's a mount issue <jpoiret>the substitute issue is getting annoying too <fnstudio>hi, i'm having locale issues in a guix container that i generated via guix home; my home config includes glibc-locales <fnstudio>i've also set $GUIX_LOCPATH as it's usually recommended i.e. '~/.guix-profile/lib/locale' but i can't see any '.guix-profile' folder in the generated container <jpoiret>did you set GUIX_LOCPATH=$GUIX_ENVIRONMENT/lib/locale ? <jpoiret>GUIX_ENVIRONMENT should be available in the container <jpoiret>in any `guix shell` environment, that variable points to the profile that's been activated <fnstudio>hm no, i don't seem to have that as an env var (from within the container spun off via 'guix home container ...') <jpoiret>ah, sorry, i thought it was a guix shell container <jpoiret>the profile should be at .guix-home/profile rather no? <jpoiret>so, GUIX_LOCPATH=~/.guix-home/profile/lib/locale <jpoiret>(i have never used guix home myself) <fnstudio>yeah true, it's there '~/.guix-home/profile/lib/locale' ***Dynom_ is now known as Guest7583
<civodul>fnstudio: i just checked "guix home container" with a Bash config, and that leaves GUIX_LOCPATH unset <fnstudio>jpoiret: that definitely did something! i still see a locale-related error but i have the feeling that's something else - so thank you!! *abrenon is generating use-module lines again <abrenon>did I miss something to automate that ? (I bet there are emacs scripts some of you have made for this purpose) <abrenon>there's definitely something to do here <abrenon>(not right now, 'cause I just need the packages to run my environment, but that'd be nice to implement it) <fnstudio>i made sure elogind is included in my package list, in my home config <fnstudio>if i execute $HOME/.guix-home/on-first-login that re-displays the same warning and suggests i should be running itself (shameless plug ahah) <fnstudio>XDG_RUNTIME_DIR would seem to be regularly set by the way <fnstudio>oh... but the dir it's pointed to doesn't exist <jpoiret>yeah, the container setup doesn't account for all little things <fnstudio>ok, all fine when creating the folder /run/user/1000 <jpoiret>and it will become more of an issue since the home container feature was showcased at the 10 years event :) <kreyren>oh i ain't banned here, fuck you nckx .. yes that was worth it <abrenon>I don't know who you are but this is no place for such things <abrenon>what do you want to discuss that is related to guix ? <jpoiret>i'm not sure that that will help your issues be treated favorably on the mailing lists <kreyren>jpoiret, there ain't no fairness until he's still in charge and able to harrass me ***ChanServ sets mode: +o civodul
<jpoiret>i've only noticed harassment and foul language from you ***kreyren was kicked by civodul (Kicked by civodul)
***ChanServ sets mode: -o civodul
<abrenon>so a package cannot be propagated if it's not publicly defined ? <jpoiret>at least i don't see why it could not, a variable being public doesn't influence whether it can end up in propagated-inputs <jpoiret>you could even have an inline package in a propagated-inputs <abrenon>ok at least I can start searching what I did wrong without bad conscience <Kabouik>Is extracting a pre-built binary from a tarball a valid way to package something on Guix? Of course it's not ideal but I don't know if it would be accepted or not. Asking for this (https://github.com/darkhz/bluetuith/issues/7), where the dev is already deep in the rabbit hole trying to package their application while a prebuilt binary would work relatively easily. <civodul>Kabouik: hi! it would not be accepted; in general, we try hard in Guix to build everything from source, with very few exceptions <jpoiret>mothacehe: did you find the source of the issue? <Kabouik>That's what I thought, couldn't find where it is stated in the manual though (the dev asked) <abrenon>false alert, that's just python being… you know… python <jpoiret>unmount-user-partitions closes the luks device but mount-user-partitions doesn't open it <jpoiret>so the luks device was closed on unmount but never reopened <jpoiret>the easy fix would be to open the device in mount-user-partitions since we have the password <Kabouik>The prebuilt binary does work (at least on my machine) jpoiret, I just tried their v0.1.3 <jpoiret>still, that will 99% not be accepted in Guix <jpoiret>Guix is a source-based distribution, that helps establish a better chain of trust <Kabouik>Absolutely, I understand that, was just looking for confirmation since I haven't found confirmation in the manual <jpoiret>but yes, packaging Go, Rust or JavaScript in Guix is very involved <jpoiret>I've dropped the ball multiple times already :) <zimoun>civodul: maybe it could be if you could report your failures about yesterday in bug#57978. <Kabouik>Yes, from the looks of it, the dev appeared to be enthused about packaging their program for it, then rapidly accumulated a lot of frustration in the process <jpoiret>Kabouik: what is your exact issue when packaging though? <jpoiret>why do you need to replace the build phase? <Kabouik>I didn't replace the build phase, did I? They might though. <Kabouik>I think the issue they faced jpoiret was (1) the usual rabbit hole of extra dependencies to package, some of which probably depending on some other stuff, and (2) our version of Go being too old for some <Kabouik>So they tried to work around this but hit other roadblocks. The pre-built binary works fine on my end so I'm kinda happy, but Bluetuith really fills a niche (a nice and fully functional bluetooth manager from the terminal) so I thought it could be beneficial to have it promoted in "guix search" for those that don't know it <dirtcastle>the question isn't about guix. when you sign a document with gpg, does it encrypt the file everytime? *rekado starts the rsync of email data from debbugs on ci.guix.gnu.org <zimoun>rekado: is the bridge with Message-ID working? ***wielaard is now known as mjw
<rekado>I long lost the overview on what is and isn’t deployed <rekado>zimoun: the mumi package corresponds to the latest commit, so if that’s in fact deployed to issues.guix.* then the message id search should work. <minima>sorry, as opposed to on top of another distro, on a foreign system <rekado>setuid program handling is part of Guix System. <minima>ok, i see, thanks for confirming that rekado <apteryx>a tool to list the last build logs would be useful ***tricon` is now known as tricon
<zimoun>rekado: ah thanks. It was the ’/msgid/’ that I missed. <apteryx>weird, no matter what I do to '/dev/sdg1' on berlin (on the 1TB hard drive previously used for the root partition), the UUID is not refreshed in the blkid output <davidl>jpoiret: Hi, I finally saw your tips re Full disk encryption with grub-efi and LUKS2, but Im still not certain how to deal with if you don't use EFI. I just have 1 partition encrypted and use the "regular" grub-bootloader. Do you know how this can be solved for me? <jpoiret>it depends on whether you want to use a modified grub <jpoiret>i've written a patch for GRUB that will make it work <jpoiret>but it doesn't apply on 2.06 cleanly now, you'll need master grub, which is annoying to get <jpoiret>i haven't been able to build grub master on guix myself <jpoiret>it needs gnulib which it fetches using an internet connection <davidl>hmm ok. Maybe thats too complicated for me currently then <davidl>I think I might just boot using the installer and chroot into the old system until the next grub master is in guix again <jpoiret>let's hope it gets merged in time for the next point release <jpoiret>I can look at getting it to build after i send my installer patches <davidl>thanks for sharing the information on the list though, I was really stuck and clueless and hopeless ^^ <abcdw>jpoiret: is this patch somewhere on mailing list? <jpoiret>this requires at least another patchset, which I think is on master now <civodul>jpoiret: looks like a serious piece of work that you have here! :-) <civodul>apteryx: hi! if you'd like to reconfigure/reboot berlin, we should prolly do it right away while there's someone on site <apteryx>rekado, civodul: I'm kinda stuck waiting on 1. rsync from /var/cache of btrfs-pool-ssd to /var/cache of btrfs-pool-san, and 2. not being able to use /dev/sdg before a reboot (IIUC). <civodul>(if we're done with the "copy kernel + initrd" thing) <civodul>so we have two copies of /var/cache? *civodul is fully familiar with the new setup <apteryx>yes, the old /var/cache which was on the SSD <apteryx>now /var/cache is normally on the SAN, but because the system booted an older generation it mounted and wrote stuff to the old /var/cache... <civodul>alright so we need rsync to complete <apteryx>I thought I could use it for /boot and efi <apteryx>but the kernel won't let me before a reboot (won't actualize UUIDs until a reboot or something for /dev/sdg1) <apteryx>so I'm out of spare drive to set /boot and efi partitions on for the moment <civodul>what does /boot need to be on a separate drive? that's because GRUB can't see the SAN? <apteryx>so we need to put /boot on a seperate drive which is visible to GRUB, and copy anything referenced from the store by grub.cfg to /boot <lechner>apteryx: hi, will 'partprobe' reread the drives? <apteryx>I even 'wipefs -a /dev/sdg' and recreated the partitions, but it's still showing a 'my-root' ext4 in blkid for /dev/sdg1 although it should appear as FAT32 with label ESP <lechner>how about echo 1 > /sys/block/sdX/device/rescan (X is the device letter) <apteryx>still the same: /dev/sdg1: LABEL="my-root" UUID="76954008-06cf-4b91-b0bb-316d8bab0576" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="626af13c-01" <apteryx>I'm also in the process of downgrading the Btrfs RAID for the ssd pool from RAID10 to RAID1, so that to keep the data we'll need to keep just 2 drives instead of 5, but this takes a lot of time too <lechner>if a side note is permitted, i know about the theoretical advantages of btrfs but did not have a good experience with raid recovery on btrfs. now i run btrfs on top of mdadm <apteryx>to have a good experience with raid recovery with btrfs it's best to have one extra drive on the minimum <apteryx>so for raid1 ideally you'd have 3 drives -- one dies, your file system is still mountable RW with 'degraded' option <lechner>yeah, i was unable to operate my btrfs raid array in degraded mode. it got worse when i reconnected the missing drive <lechner>apteryx: if you have access to the equipment you could perhaps hotplug <apteryx>I don't; but yes that'd probably help. rekado? <rekado>you want me to unplug a disk? The spinning disk? <apteryx>yes, if someone is around in the datacenter, that could help. or plug 2 extra rotative drives if there are slots left <apteryx>rekado: to be clear, if someone is available, unplugging and replugging the spinning disk which is in the PERC H730P: sdg 0:2:0:0 disk DELL PERC H730P Adp 4.30 00b47dec29951f722100047215604609 <rekado>you may have some luck disabling the disk in the PERC <rekado>nobody’s in the data centre today, and I think it’s hard to see at a glance which disk corresponds to that particular PERC slot. <rekado>not something I’d feel comfortable asking someone to do on my behalf. <mothacehe> jpoiret: just tested your patchset, works like a charm, nicely done! *apteryx is a bit puzzled as to what (gnu services configuration) 'interpose' and 'serialize-text-config' do <apteryx>ah, interpose returns a list with "\n" introduced (interposed) between each element <apteryx>(interpose (list "one" "two" "three")) -> ("one" "\n" "two" "\n" "three"), or (interpose (list "one" "two" "three") "\n" 'suffix) -> ("one" "\n" "two" "\n" "three" "\n") <apteryx>I'm still not sure when/how to use serialize-text-config <apteryx>it seems I need to apply its result (a gexp) to mixed-text-file anyway? <apteryx>OK, I think I get it. text-config is line-oriented, while mixed-text-file isn't <jpoiret>davidl: it's building right now, i'll keep you updatde <apteryx>so hmm, the text-config type is strictly for a list of file-like objects? I thought it could be just strings too, e.g. (list "[Section]" "key1=value1" "key2=value2" ...) <apteryx>abcdw: any clue as to what text-config is useful for, or examples? I think this got added to support (guix home), if I'm not mistaken. I tried using it with a simple string-only example as shown above, and serialize-text-config doesn't seem to work on that. <mitchell>I am writing a guile application and I want to use (guix records). How should I specify my manifest so that only the guix guile modules get installed but the guix binary does not. Or am I thinking about this the wrong way <rekado>mitchell: you can’t slice it. The ‘guix’ package contains not just the Guile modules but also the scripts. <mitchell>That's a bit annoying. The guix that gets installed will shadow the one made from guix pull. Perhaps it's not a good idea to make guix a dependency just for the records api <rekado>maybe you could just copy the module? <rekado>many of the neat features present in Guix call for being spun out into their own projects, but the call hasn’t been acted on :) <mitchell>It would make some sense to be able to use the modules without bringing in the nix base <civodul>mitchell: i'd also suggest copying (guix records) into your code base, it's a reasonable tradeoff <civodul>eventually it'll become its own library like rekado writes, but for now it's convenient to have it in Guix proper so we can tweak it for our needs <jpoiret>you could use a snippet to copy it, rather than check out an outdated version <jpoiret>well, you could copy the file from the guix source at build time <jpoiret>it's not really a portable solution without guix though :p <mitchell>Yea it lacks a sort of elegance, copying the source code seems like a reasonable thing to do <civodul>another example of that is base64.scm, which has been copied over in several projects... <mitchell>I feel like snippets/patches as applied by guix shouldn't add critical functionality to the code. just tweaks to get it to fit into our ideas of the world. <civodul>not great, but it lets us move forward <jpoiret>do you know of a more elegant solution? <jpoiret>i can't just use origin with git-checkout <civodul>jpoiret: i'd do something like (computed-file "patched-source" #~(begin (copy ... #$(git-checkout ...)) patch stuff ...)) <abcdw>apteryx: it was reworked and now it's pobably accepts a list of strings or file-likes and the content get concatenated with \n, so you can write something like (list "alias super-ls=ls -with-options" (local-file "./my-old-bashrc") ...) <apteryx>abcdw: now as in its current state in master? <apteryx>if so, I wasn't to make use of it with pure strings, because 'serialize-text-config' does some with-input-from-file on strings... which are not files, and fail. <jackhill>Is berlin still down? It looks to be working (at least in some degraded state) for me <abcdw>apteryx: ok, I see, than it should be like (list (plain-file "bashrc-preamble" "# content of bashrc here") (local-file "./bashrc-old") ...) <apteryx>right. that seems an odd requirement for something named 'text-config' <apteryx>I was expecting text-config to be some more convenient way to provide a text file, e.g. not having to take care of "\n" myself and allowing for mixed text and gexps. <apteryx>jackhill: it's still in a far-from-ideal state <jackhill>apteryx: ah, ok. Would you recommend putting off pulling? Best wishes for continued maintenance! <apteryx>there may be an odd substitutes missing while things get sync'd <apteryx>I need some extra eyes with a new dconf-service-type that I'm using here: https://paste.debian.net/1254670/ to support a new 'auto-suspend?' gdm-configuration option. Currently, it doesn't seem to extend at all, /etc/dconf doesn't exist in a VM <apteryx>and guix gc -R /gnu/store/path-to-run-vm.sh | grep dconf doesn't have it either <apteryx>so something is probably badly defined for the extend or compose of dconf-service-type, I'd guess *apteryx sprinkles the code with pk <apteryx>haha, perhaps just inverted logic in gdm-dconf-profiles <Guest3>how do I get the value of a guix variable? Specifically %desktop-services, because it will be different depending on the `desktop-services-for-system` function <apteryx>it's define in (gnu services desktop): %desktop-services <Guest3>I know where it's defined, but the output of the `desktop-services-for-system` function changes depending on the system <Guest3>the function ran when I did a `guix system reconfigure config.scm`, and I want to know what it's output was, maybe it's stored somewhere, maybe I can re-run the `desktop-services-for-system` fn <jpoiret>Guest3: you can load your file in a guix repl and inspect the resulting operating-system object <jpoiret>ie (define os (load "my-config.scm")) then (operating-system-services os) <Guest3>hmm, outputs a lot of stuff (fills my screen), how do I parse the output? <jpoiret>you can explore it with things like (for-each (lambda (service) (format #t "~a~%" (service-type service))) (operating-system-services os)) <Guest3>don't know how to use guile (yet) <Guest3>(i know elisp, but guile has a bunch of weird syntax) <sughosha>Hi, is it possible to avoid building packages again locally even if their substitutes are built successfully? <rekado>sughosha: have you authorized the substitute server? <sughosha>I mean I didn't authorize manually. I thought I can download substitutes by default. <Guest3>(for-each (lambda (service) (format #t "~a~%" (service-type service))) (operating-system-services os)) gives an error 'invalid field specifier in subform service of (service-type service)' <jpoiret>it should be service-kind, not service-type <jpoiret>even better, (service-type-name (service-kind service)) <jpoiret>service is a service object, which has a `kind` field with field accessor `service-kind` <jpoiret>which incidentally happens to give you a service-type record <jpoiret>the general convention is to have SERVICENAME-FIELD for accessors <sughosha>rekado: I noticed that if I mention `--substitute-urls=https://ci.guix.gnu.org` then it downloads the binary substitutes. Is it possible to automate this without mentioning `--substitute-urls` everytime? <sughosha>I am on a complete guix system by the way. <acrow>podiki: Looked at it, but no clue. :( <podiki[m]>it just seems to hang there, did it again on a retry <podiki[m]>I guess that test should be skipped for now, though I haven't looked at the specifics (never had to do anything with the rust compiler package before) <apteryx>abcdw: was serialize-text-config what used to be called snarf-file-as-gexp or something similar? <podiki[m]>apteryx: this is only 1.61, I suppose I could try to skip that version and see if 1.62 builds from 1.60 and succeeds? <podiki[m]>(needed for latest firefox version, which I assume will mean icecat one day) <apteryx>typically each rust depend on features introduces in the version directly before <podiki[m]>oh? are they all pretty dependent on previous version these days? <apteryx>I guess so. As soon as new features come into existence they can be used in the code base. <apteryx>and the rust devs know best what new features there is ;-) <apteryx>which means the bootstrap chain gets longer every 6 weeks <podiki[m]>1.60 was fine at least, not sure what failed exactly since there were multiple threads it said panicked in the log <podiki[m]>wow, even their chat space looks very complicated <apteryx>zulip is pretty come as far as in-browser chat comes. it feels lighter than the others. <podiki[m]>all I know is that at first opening it I see a huge list of channels (I assume) most of which do not make sense for one that knows nothing of rust....but thanks, will ask there if I don't figure something out later ***protomeo is now known as antimeo
<podiki[m]>huh, those errors inthe log are all nearly the same as in rust-1.57, I guess all expected thread panics? but then something hangs at the end <podiki[m]>test sys::unix::process::process_common::tests::test_process_group_no_posix_spawn has been running for over 60 seconds <podiki[m]>posix groups, sigint/sigkill and killing processes...any of this ring a bell for the guix build environment? *apteryx is in search of a dconf guru *apteryx opens dconf's source <lechner>hi, i use setuid-programs for opensmtpd to mark the executable mail tools setgid, but the new gid appears to be effective only for users but not the smtpd daemon itself. as a result, smtpd is unable to use 'sendmail' to process the offline queue (I am not sure why it needs to use sendmail). has anyone seen anything like it? <podiki[m]>not sure what this means for us....skip the test somehow? <podiki[m]>or is it something we can set, seems a hanging process is created that is supposed to be killed, but sigint isn't doing that in the build environment? (some guessing here) <apteryx>it's probably because we lack correct handling of dead processes in the build container <apteryx>they remain zombies. this is worked around ad-hoc with tini in some places, notably tests using python-dbus-mock <podiki[m]>ah, I see a few mentions of sigint and tests in guix <podiki[m]>what would you recommend here? if there isn't an easy workaround, I guess patch to disable the test <podiki[m]>or change signint to sigkill in the test code? <apteryx>podiki[m]: there's an issue in our bug tracker somewhere to better handled killed processes but I can't find it <abcdw>But original implementation of text-config, which accepted strings or gexps, could be combined with slurp-file-gexp like this: (list "# bashrc preamble" (slurp-file-gexp (local-file "./bashrc-old"))) <abcdw>However, Ludovic mentioned that slurp-file-gexp maybe problematic in some case, I still not sure in which. <podiki[m]>apteryx: okay. so will want to add an ignore to that function and note in the package def that this is due to SIGINT handling (so one day someone will fix these) <apteryx>ah, SIGINT is different than what I had on mind (zombie processes). I think it happens sometimes when the tests expect an interactive terminal to be connected to the application. <podiki[m]>so end result is test relying on SIGINT need to be skipped though? (like in python-uvloop) <podiki[m]>gotcha. will give it a try later, hopefully get it right the first time so I don't have to wait for rust to build and fail at the tests :) <podiki[m]>(and then will submit patches for guix I guess once staging is merged? to add the rust versions without updating default) <apteryx>right this is annoying; you might want to troubleshoot in /tmp/guix-build-rust... if it fails <podiki[m]>I'll quit after the various patch phases to see if the substitute looks good, since honestly that's where I would go wrong (though this looks easier than most substitutes) <jesse`>Hi all. Guix recently upgraded my kernel (using `guix pull`) to 5.19, which I found out does not work well with my system. I see the definition of the 5.18 kernel is now gone from linux.scm, so I was wondering, is it possible to keep using the 5.18 kernel and still upgrade the rest of my system? <podiki[m]>well there's also other versions (like 5.15) if you want <vagrantc>but you can of course define it yourself and use it in some way <jesse`>Ok thanks. I will try 5.15 and see if it works. I was just thinking that linux-libre-5.18 package must still be in my store, so was hoping to refer to it without building <podiki[m]>if you defined it by copying the original definition, probably it would be the same hash and yes be built already. but better to use a supported version if you can <zamfofex>I might be completely off here, but isn’t this what inferiors are for? <pkill9>jesse`: you can also use inferiors to avoid rebuilding the kernal in future upgrades <pkill9>see my confog on my sourcehut for example <pkill9>that is what yhey are for zamfofex <pkill9>actually it's more of a convenoent side effect <podiki[m]>yes, that's an option too (though still on an unsupported kernel version, to be noted) <abcdw>Have a nice evening, everyone! <jesse`>Oh nice, I will look at inferiors then! <jesse`>The 5.19 kernel makes my laptop hang a lot and I get weird visual glitches. Maybe I'll first see if 5.15 works and else go for the inferiors. Thanks <apteryx>neat, I think I've nailed (auto-suspend? #f) for gdm-configuration <podiki[m]>okay, rust-1.61 built with those 2 tests (that use sigint) disabled <lechner>Hi, is anyone having issues with opensmtp refusing to start via herd with recent versions of Guix? <civodul>lechner: hi! i don't use opensmtp, but do you have details in /var/log/messages? <apteryx>it seems fragil to define port-forwarding rules to test an instrumented VM (system test) via SSH, as they could conflict with the host system. Is there an alternative? <civodul>i think that cannot conflict with the host because it's in a separate net namespace <apteryx>ah! then that's nice. I didn't think it was wired that way. <lechner>civodul: it was just a syntax error when transfering the string into config.scm. sorry to bother you, and thanks for the hint where to look for errors ***mark_ is now known as mjw
<yuu[m]>is it ok to `GUIX_PROFILE=$HOME/.config/guix/current`? or any place at $HOME/.config/guix? <minima>I've prepared a Guix home configuration script which builds fine and I can launch in a container <minima>if I try and add guix to the list of dependency though, that seems to break things <minima>the error being: 'guix home: error: profile contains conflicting entries for gnutls' <minima>I'm running Guix on a foreign distro - could that be the reason for the error? <minima>am I trying to guix-installing guix? I have this vague recollection that that is bad on a foreign distro? <minima>never mind, i removed gnutls (which was also listed as a dependency) while keeping guix, and that solved the issue... no more conflicts now, thanks <unmatched-paren>and yeah if you try to have two of the same package in one profile you'll get an error <minima>right, thanks unmatched-paren - this on a foreign distro, correct? <pkill9>to be fair though instqlling guix into the profile isnt the problem here <pkill9>but it's misleading to just assume that it's the cause of all provlems and blanket never do it <minima>thanks unmatched-paren and pkill9 <minima>ok, but now I wonder... should guix be included as a dependency in my home configuration? <minima>the file builds correctly now (with guix as a dep) and i can use it to instantiate a container... but how would that behave when I ultimately reconfigure my home <unmatched-paren>pkill9: sure, it doesn't cause all problems, but i do think it is actually right to say "blanket never do it" <minima>unmatched-paren: excellent, thanks!