<iska>What's the status on plasma? is the wip-plasma branch usable? <drakonis>its from 2021 but i'm not sure if its ready for primetime <iska>just wondering if it's even usable <rekado>and I don’t think anyone here is working on it either. <Gooberpatrol66>Does anyone have working hibernation with encrypted root on guix-system? <apteryx>rekado: I think someone was working on KDE stuff recently, including plasma <sneek>apteryx, you have 3 messages! <sneek>apteryx, muradm says: hi, in (gnu services security) you added generate-doc, how do you call it without *-fields symbols exported? <sneek>apteryx, muradm says: nevermind, figured it out, thanks <sneek>apteryx, muradm says: could you please have a look at 57575 <apteryx>sneek: later tell muradm re generate-doc, I cann it from Geiser when in the scope of the (gnu services security) module <apteryx>Gooberpatrol66: oh right, it was phodina <iska>hmm, apparently gnome-boxes is outdated <Cairn>Has anyone else had trouble with yt-dlp recently? Can you download a video from youtube? <Cairn>I takes several minutes for it actually start downloading the video for me. And once it's there, it downloads it in quick bursts separated by lengthy pauses. Takes probably about 10 minutes to download a single video that used to take seconds. ***jacobk is now known as jacobk_
***jacobk_ is now known as jacobk
<oriansj>Cairn: youtube itself can do rate limiting and there is nothing you can do about it. <Cairn>oriansj: Is that IP-specific? Or do you mean they've changed their API? <oriansj>Cairn: I think that is an API change they have rolled out over the last 2 months. <oriansj>it is hard to get more than 1.3x the play rate of a video <ulfvonbelow>that's a little odd considering the official player supports 2x playback speed <oriansj>ulfvonbelow: and drops frames like crazy <Cairn>oriansj: Could you try downloading a video? I feel like something *this slow* would be a bigger deal to the yt-dlp people. <oriansj>Cairn: it might be a big deal but if Youtube is doing per IP rate limiting there isn't anything the yt-dlp people can do about it. <oriansj>So unless you spin up multiple cloud instances with unique IPs downloading separate videos, there isn't much of a speedup for getting any video in particular but you can mirror a channel in question or download a list of videos faster <Cairn>I understand, but it doesn't seem to be widely agreed upon. At least in the issue tracker, there's no consensus. <Cairn>You wouldn't mind just trying a download, would you? <Cairn>ulfvonbelow: And does it start downloading immediately? Or does it take about 5 minutes to start the download? <ulfvonbelow>there's around 5 seconds while yt-dlp loads and extracts metadata, after that it starts immediately <ulfvonbelow>maybe google just really hates your ip-hopping neighbor <Cairn>I don't have any trouble with youtube itself, is the thing. <Cairn>It's ok though. I'll just put it on my list of nonsense that I need to figure out. <oriansj>or think of this as another reminder of why you should limit your youtube use <ulfvonbelow>the usual caveats of centralized and proprietary systems - you have little control, and what little control you do have is hard-fought <oriansj>Cairn: it is a form of social media which is designed to extract maximum attention from you to increase ad revenue <oriansj>so it tends to try to exploit your cognative weaknesses to drive engagement. <Cairn>oriansj: I block ads and the recommendation bar. I don't have an account. I use it virtually the same as I use archive.org. <Cairn>Although I agree with the sentiment. <Cairn>I'm certainly not going to deprive myself access to one of the largest collections of human culture on video. <ulfvonbelow>one thing you could maybe try is using yt-dlp with an invidious instance, maybe it'll proxy the download for you? <Cairn>ulfvonbelow: Let me try that <Cairn>I appear to get the same issue <bdju>could someone look into updating the fzf package? there's some breakage with its zsh history search feature that was fixed in an update <bdju>gnu/packages.scm:545:4: In procedure specification->package+output: <bdju>Throw to key `quit' with args `(1)'. <bdju>what is this about? trying to do upgrades <bdju>oh wait maybe it's related to an unknown package above <bdju>removed fortune-mod but then it choked on mono <efraim>mono was removed from Guix, there were too many vendored binaries in the source with no way to build them <unmatched-paren>cyber-chris[m]: looks like it hasn't been merged into master yet (and if you guix pull, you are usingaster, not 1.3, which is very outdated) <phodina[m]>Does someone know how to tell meson not to look for package with `-devel` suffix? <phodina[m]> * Does someone know how to tell meson not to look for package with `-devel` suffix? <phodina[m]>I've added the package to the list of inputs and `pkg-config` also detects the package. However, for some reason meson queries the `pkg-config` for `PKG-devel`. <cbaines>it's still not particularly clear from that page what is potentially broken by the changes, but it's getting there <ulfvonbelow>by the way, I found out what was up with my nginx cert issues - I was using cert.pem instead of fullchain.pem <abcdw>rekado: guix build rust-once-cell fails for me with error: no matching package named `windows-sys` found required by package `parking_lot_core v0.9.3`. <klm>unmatched-paren: c.scm seems like a good choice! <klm>How does watching/subscribing on debbugs.org work? Are people notified when you reply to an issue they have participated in? <abcdw>rekado: I'm not very fluent in rust, so I just temporary reverted af39bd88a27e33c43df8324202cfebaeeb77437a locally and now everything builds for me, but it's very likely other people affected too, can you take a look at it, please? <efraim>it's alright if rust-once-cell@1 doesn't actually build, unless you're working on python-cryptography-next <ulfvonbelow>when I try to run "guix system init", I get guix system: error: '/gnu/store/026mmk7vmp51225akcxxw2fqqpb7cqcx-grub-efi-2.06/sbin/grub-install --boot-directory /tmp/mnt/boot --bootloader-id=Guix --efi-directory /tmp/mnt/boot/efi' exited with status 1; output follows: <ulfvonbelow>followed by: /gnu/store/026mmk7vmp51225akcxxw2fqqpb7cqcx-grub-efi-2.06/sbin/grub-install: error: /gnu/store/026mmk7vmp51225akcxxw2fqqpb7cqcx-grub-efi-2.06/lib/grub/i386-pc/modinfo.sh doesn't exist. Please specify --target or --directory. <abrenon>what would be the easiest way to take the output of a build from a machine I have SSH access to and use it on my local machine as if I had built here ? <tex_milan>Hello Guixers! I am trying to package a rust app, or update existing rust app, and always hit the problem that rust-nightly features are required. Even ("RUSTC_BOOTSTRAP" "1") doesn't help. Since nightly is frequently required, is there any attempt to solve this for Guix? BTW, it would be nice to be able to specify only the top package (the application) and let it use rust's package manager to download all dependencies. <sneek>tex_milan, you have 1 message! <sneek>tex_milan, podiki[m] says: as a proof of concept I built and ran eww in the fhs container I'm working on <ulfvonbelow>... is grub trying to autodetect whether the system I'm running on uses efi and assuming it should try to operate based on that, rather than whether I specified to use efi or not? <ulfvonbelow>I'm trying to init a hard drive that I will then remove from my computer and install into a different computer <unwox>tex_milan: downloading dependencies through rust's package manager is side effect which guix avoids as much as possible <Luk6655>Hi, does guix use any cache when downloading files during package build? I mean files downloaded with (method url-fetch) during package build for example. <cbaines>I don't think that's right davidl, that cache isn't involved in package builds <davidl>Luk6655: actually, thats just a cache for guix itself. <davidl>cbaines: right. was just noticing that. <cbaines>Luk6655, maybe the important thing to note here is that files aren't downloaded during package builds. <cbaines>if that were the case, it would damage the reliability and reproducibility of the builds <cbaines>downloads from the internet are handled as fixed output derivations, the outputs of which can then be used by other derivations, like the ones relating to a package <davidl>I think the (sha256 (base32 string is sometimes found somewhere, preventing new downloads. <cbaines>so, these files won't be donwloaded again unless they were removed from the store <iska>commit af39bd88a27e33c43df8324202cfebaeeb77437a should be deleted, rust-once-cell@1.13.0 fails to build <Kabouik>I need to alter my GRUB configuration to add that line: `fbcon=rotate:1 video=DSI-1:panel_orientation=right_side_up`. Does that go directly into (bootloader (bootloader-configuration)) or am I missing a "subsection" (sorry, I don't remember how they're called)? <Kabouik>I don't know how to get a list of all available subsections, so I only know those that are listed in the Guix manual example, I am not sure that this is exhaustive <sneek>muradm, apteryx says: re generate-doc, I cann it from Geiser when in the scope of the (gnu services security) module <Luk6655>cbaines: :-) well they are downloaded prior to building a package. I wonder, does (method url-fetch) support file:// uri's? I have some multi GB files I would prefer not to have to redownload, but to point it to a local path instead <cbaines>Luk6655, are you sure you want those multi GB files in the store? <Luk6655>Do I have an option not to? they contain the source of what I'm trying to package <Luk6655>this is what the manual says about file:// "Alternatively, when URL starts with file://, return the corresponding file name in the store." <Luk6655>I don't quite understand this bit, I would like to replace the uri-fetch with reading from a local archive drive mounted somewhere, but this suggests there is some way to store a tar archive containing software source in the store itself? <cbaines>Luk6655, I think what that means is that the client side of guix will send the data to the guix-daemon, so that the file ends up in the store <Luk6655>I see, so it refers to target save location probably <cbaines>well, I think that documentation you're reading is the docstring for url-fetch* in (guix download) <cbaines>and it's describing the return type of the procedure <cbaines>if you call it with a URL that it needs to download, it'll return a fixed output derivation <cbaines>whereas, if you call it with a file:// URL, it'll read the file and send the data to the guix-daemon there and then, returning you a string which is the filename in the store <Luk6655>still, it is pretty confusing to me: it describes url-fetch with a parameter of url, and if url starts with file:// it returns a location in the store? How does it know where to download it from then? <Luk6655>it would if we removed "in th store" from it <Luk6655>unless there is some check that allows to read files only from the store, not from anywhere else on the filesystem <Luk6655>which then raises the question how that file ends up in the store in the first place... <cbaines>when you're constructing derivations, everything needs to be described. <Luk6655>unless, what is meant is that: it will read the file from anywhere on the filesystem, place it in the store, and return its location in the store <Luk6655>re-reading the whole section, I think this is right, thanks <cbaines>at this point, I'd maybe stop reading the manual and read the code instead <cbaines>have a look at url-fetch* and around where it calls interned-file and the definition of that in (guix store) <Luk6655>hmm, yes I do for some things, but when things are in the manual it seems a much more straightforward source, especially that my guile is not great despite reading every source I could find <cbaines>avoiding reading Guile code is not going to make reading Guile code any easier :) <Luk6655>I've dealt with poorly documented systems a lot in the past (usually hardware and api references auto-translated from chinese, from manuals that didn't make much sense even in original chinese). In those cases I always found reading the code(usually in C/C++) much easier. However, when I founf guix I thought to myself: "Look how well this is documented, all those long manuals. A Guix manual, A Guile Manual, A Scheme course etc etc." <Luk6655>I guess this is why, looking at the sheer volume of stuff written I'm not jumping straight to the source (yet). Perhaps I should. <Luk6655>Still I can't claim to have read everything. It is on my list of things to do... even despite some obsolete info. <Luk6655>for example one thing that I don;t understand about guile is why sometimes we refer to stuff as (use-module (some module)) and other times (in definitions) it is #:use-module (some module), same with other variables <civodul>Luk6655: #:use-module allows you to specify imports within a define-module form <civodul>whereas 'use-modules' is used in contexts where you're not defining a module <Luk6655>yes, that's where I saw it used, but is #: some generic operator that means something. I see it there in define-module, but also within build phases section where phases are referred to as (#:phases phases) <Luk6655>perhaps a key parameter? that's how it was described in function definitions <AwesomeAdam54321>Luk6655: I think #: is a key, so it's like in Python: function(var1="text", var2=5) where there's #:var1 and #:var2 <apteryx>efraim nckx in case you are available, in 30 minutes time would be our monthly meeting <efraim>apteryx: thanks for the reminder. luckily I'm at home, let me clear the schedule with the wife. today's turned really really busy <Luk6655>yes, I think what would be really helpful in understanding how guile code works is some sort of debugger, where the user can stop the interpreter at any stage and analyse variables, their types etc. Perhaps this is doable with repl. <apteryx>efraim: o/ sounds good, if you can make it <Luk6655>there is a whole debugging section in the guile manual, hopefully it has the answers I'm looking for <cbaines>I've also got around to sending an email to guix-devel about this <rekado>abcdw: that’s odd. I’ve built everything on a branch, and made sure things work fine by building icecat. <rekado>abcdw: reverting individual changes like that is probably not a good idea, because other rust packages depend on this upgrade <rekado>reverting just one of the changes likely breaks the other packages, so I don’t recommend it. <efraim>apteryx: I'm in, but I can only stay 50 minutes <Luk6655>quick question, if two packages with different versions are available, how do we select one? I tried packagename==X.Y.Z, --version X.Y.Z etc <Luk6655>nevermind, @ works, just not with search <civodul>you can safely remove mips64el-linux and powerpc-linux :-) <cbaines>antipode, there are many missing bits and sharp edges. Issue 57560 is closed, so I think that case where the issue is unknown about is just not handled properly yet <cbaines>but yeah, I'm glad you like it civodul :) <cbaines>and putting beauty aside, I'm hopeful the design can be improved to make the information clearer and more actionable <apteryx>weird. 'guix refresh gnome-keyring' leads me to 42.0... but there's 42.1 available. <efraim>apteryx: it could be related to olden times when in 3.x, if the x was odd it was a beta release <efraim>I gave civodul feedback to help set that up many years ago <apteryx>do you know where such logic lives in the code? <florhizome[m]>i have this problem a couple times where, in cmake–build–system, the build is just interrupted without any more explicit message after a certain target is built and make leaves that directory but doesn’t commence. <abrenon>I get an architecture error I don't understand when trying to guix copy a package I freshly built on another machine which has the same architecture as mine, x86_64 <abrenon>"implementation cannot deal with > 32-bit integers" : what can that mean ? I don't see why the remote machine would have cross-compiled a 32bits binary without my asking for it <pkill9>i run `pipewire`, then `pipewrise-pulse`, then run pavucontrol, but I see no output devices or anything, and I run `mpv <audiofile>` and it stays stuck <iska>pkill9: I think pipewire-pulse should start with pipewire <pkill9>applications just start pulseaudio if I do that <civodul>efraim, apteryx: it's in (guix import gnome); maybe we need to tweak the logic in there? <efraim>yep, back from 2017. looks like the even-minor-version? check might not be needed anymore <civodul>i see even-minor-version?, which i guess is no longer appropriate <florhizome[m]>pkill9 here is what I have to make pipewire work on gnome wayland: <florhizome[m]>System config: install udev rules, disable pulseaudio autostart <florhizome[m]>Home config: shepherd services to start pipewire, pipewire–pulse and wireplumber I think <civodul>efraim: i guess we just need to remove even-minor-version? and keep the code that was taken on even-minor-version? => #t <florhizome[m]>i can’t tell you how important udev rules are I had them in the config for longer since i was going to test this <pkill9>florhizome[m]: sweet thanks, it's working without pusleaudio now <abrenon>adding verbosity doesn't yield any additional info about the issue <abrenon>which "implementation" is at stake here ? guix copy's ? <pkill9>evenw orks with my bluetooth speakers ootb <pkill9>those are the three things to rremember <florhizome[m]>pkill9 what did it for you ? the udev rules or pulse config to no autospawn? Glad to hear :) <pkill9>pipewire, pipewire-pulse, and wireplumber <pkill9>now I wonder why it is not as simple as simple runnign pipewire <pkill9>florhizome[m]: just running those three thigns in that order <iska>pkill9: I'd love if you gave the config file <pkill9>I've decided it's my mission to improve the guix desktop experience <florhizome[m]>disabling pulse is just when you use services that automatically use it like gnome DE <pkill9>I should note that I'm not running gnome <pkill9>florhizome[m]: what do the udev rules do? <florhizome[m]>Gnome or DEs in guix spawn pulse not as a service but via dbus which made disabling it hard to find. <florhizome[m]>this is one of the examples why I think DEs should be user/home services not systemwide… <abrenon>the implementation of import-paths in guix/store.scm mentions signing the items, could that be the actual issue here ? (I haven't seen anything about signing on guix copy's manual page but ?) <abrenon>could the error message be inappropriate, a leftover from a copy-paste or something ? <pkill9>florhizome[m]: i agree, that's one of the reasons I prefer running sway, I can start it just by running an executable <pkill9>and update it in my profile as and when i choose, etc, like any other program <abrenon>is there a simpler way than guix copy to take a build product out of a machine ? <apteryx>cbaines: do you still need storage on bordeaux? <pkill9>oh i should also note I was running pipewire in a guix environment, i.e. ot installed, so maybe if I instlal it then pipewire-pulse will automatically start with pipewire due to installed dbus signals or whatever they're called <muradm>sneek: later tell apteryx, thanks, i also could use './pre-inst-env guix repl' for running: ',in (gnu services security) (generate-doc)' <florhizome[m]>pkill9 i justice noted that because at this point we could commit do a pipewire home service I guess but it would need to have instructions for people using DEs <unwox>pkill9: you need a session manager in order for pipewire to work correctly. were you missing wireplumber in your earlier tries? ***wielaard is now known as mjw
<abrenon>but I don't understand how a key can be revoked afterwards ? <civodul>abrenon: hi! you would remove the key from /etc/guix/acl <civodul>it's not super-friendly, but it's human-readable <abrenon>yeah, definitely, but if on one of the machines it's merely root-owned (so no-problem), however on another it points to somewhere in the store, so I assume it's read-only, isn't it ? <cbaines>apteryx, not urgently, the two systems storing copies of all the nars have a few TB of free disk space. For reliability it would be good to have an additional online source of the nars though, as hatysa doesn't actually serve them, it just acts as a backup. <apteryx>cbaines: OK; I've sent an email to sysadmins so that we can discuss of what we want to do with them <sneek>apteryx, you have 1 message! <sneek>apteryx, muradm says: thanks, i also could use './pre-inst-env guix repl' for running: ',in (gnu services security) (generate-doc)' <abrenon>I find 4 different -acl files in my store <cbaines>apteryx, OK, I'm not sure I have all the context, but I'll read the email when it arrives <abrenon>civodul: sorry I'm confused: of course you meant /etc/guix/acl, that's what you wrote and that's how I understood it, but on my guix system this file is a symlink to some /gnu/store/…-acl <abrenon>and I just lost access again due to my repeated attempts at copying <apteryx>abrenon: I'm guessing that happens when you're using the declarative style (configuring the guix-daemon's autorized keys from your config.scm) <abrenon>indeed, on the other machine which is a ubuntu where I tested guix' install script, I never ran guix system <apteryx>so if you configure it from there, there's no need to manually remove any keys. the keys used are those specified by the authorized-keys field of the guix-service-type <abrenon>hmmm… so in that case I guess there's no way for me to quickly import a package just once : / <apteryx>perhaps a bind mount shadowing /etc/guix/acl; not sure if the store allows for it <abrenon>wooooh that'd be neat Imma try that : Þ <abrenon>and of course it worked !! thank you so much <abrenon>I didn't even have to bind mount : it's a mere symlink, in a folder, /etc/guix, which is perfectly regular and root-writeable, so I was able to change everything I wanted there before restoring everything back to normal <abrenon>so actually my questions have been irrelevant since civodul's answer to just edit the file <civodul>abrenon: oh right, sorry; it's a symlink on Guix System, but see guix-configuration as apteryx hinted <abrenon>anyway I take that success as a hint that the error message I got about "implementation" and 32 bits was actually about my lack of authorizing the remote host <civodul>rekado: i'm adding 'shepherd-requirements' to <nginx-configuration>; we'll manually fill it in in berlin.scm <abrenon>if that is the case, the error message is confusing at best <civodul>abrenon: oh it could be that this is still reported in a suboptimal way :-/ <civodul>if you're trying to set up offloading, see "guix offload test" <abrenon>not even setting it up properly, I merely installed guix on a computer at work to ease deployment of my packages and thought I could use that as a bonus to compile that huge binary package which has been lacking substitutes for a couple days <abrenon>I hadn't ever looked at guix copy or guix archive before today, it's really amazing how everything is totally cool in guix <antipode>It appears to be some gdb build failure but I cannot reproduce locally and I'm not finding gdb-related errors in the mixed log. <civodul>it wouldn't hurt to allow it for any failed build <antipode>If automatically (well, upon request, but without checks) is ok, how about making the 'restart' button not require special permissions? <antipode>Maybe too prone to crawlers though, given that it's a link <civodul>well, allowing restart-if-failed is fine IMO; allowing restart less so <civodul>maybe in practice that'd be fine though ***ChanServ sets mode: +o litharge
***litharge sets mode: +b *!*@2001:470:69fc:105::2:7a24
***steven02[m] was kicked by litharge (You are banned from this channel)
***litharge sets mode: -o litharge
<Luk6655>Is there some way to run package build phase by phase manually, to tweak and retry only a failing phase etc? <Luk6655>civodul: thanks, yes, I'm aware of the ability to go into the environment, source all the variables and just poke from bash... I was hoping for something that can help debug guile build code, but I understand nothing like this exists, right? <cbaines>civodul, for https://qa.guix.gnu.org/issue/57458, I think data.qa.guix.gnu.org is missing the master revision used in the comparison, it only keeps the most recent 100 revisions for each branch, so I'll raise that to 500. <cbaines>civodul, as for the second issue about the "failed" builds where the logs suggest they didn't fail, yeah, I spotted that as well. It turned out to be a bug in the build coordinator. The agent was crashing and this was misinterpreted as a build failure. I've fixed that now, but there will still be some misleading data. <cbaines>there's no button to run builds yet, but you can SSH to bayfront and run: guix-build-coordinator build /gnu/store/....drv <podiki[m]>re: the automated patch builds/comparison: very cool stuff! great work cbaines <unwox>this looks really cool, great work :) <civodul>substitutes available before the thing is even pushed, sounds like scifi :-) <civodul>apteryx, efraim: i fixed (guix import gnome), it was slightly more subtle <abrenon>how can a server have substitutes for one output of a given package but not the others ? I thought all had to be built at once <the_tubular> Dumb question of the day, what's the point of the /gnu/ directory ? <abrenon>you mean "why it's not store directly under / ?" ? <AwesomeAdam54321>the_tubular: So that people know it's a store to store the things that make up a GNU system; /gnu/store <AwesomeAdam54321>if the store directory was kept somewhere else, it wouldn't be as descriptive <Cairn>the_tubular: Pretty sure it's safe to rename it anything you want. At least it shouldn't be considered a hard-coded value. <Cairn>So you could always change it. I've wondered about the extra directory layer as well. <Cairn>TIL Nix uses the same structure. I guess that'd make a lot of sense then. <abrenon>I love freeing 28G at once by running guix gc <iska>I should probably do that as well.. <pkill9>out of curiosity, why are the var files not stored in /gnu/var like nix? <pkill9>since it would keep everything together <civodul>pkill9: FSVO "everything" though, because "everything else" is in /var :-) <civodul>abrenon: for some values of "everything" <civodul>uh, Savannah seems to be down or super slow <abrenon>I knew it had to be one or the other : ) ***mark__ is now known as mjw
<Luk6655>Is there some function in guile to process a file by removing the front part of the file (until a certain string is found), or does one have to write some->stream sort of file <Luk6655>I mean does one have to write one's own function using file->stream <dthompson>Luk6655: you don't need to use a stream to do this, just guile's own port procedures. I can't think of anything built-in that does what you want, but there might be something I don't know about. <Luk6655>does it matter this is a pretty large file? (It would fit in memory - few GB), but it would be better not to have to load the entire file, does this matter for the choice of ports vs streams? <antipode>Luk6655: A port does not load the entire thing in memory. <Luk6655>ok, thanks I'll read about the ports <antipode>A port is basically just a reference to the file together with the current position inside the file and optionally a small buffer. <antipode>With streams, do you mean (ice-9 streams)? <Luk6655>the description is titled srfi-41 stream library <antipode>(ice-9 streams) and (srfi srfi-41) are the same basic concept, though apparently (ice-9 streams) is deprecated. <Luk6655>I'm looking for some example where there would be an input and output port used at the same time, basically sending stuff from input to output with some processing <Luk6655>although I have an idea how to do it with looping over input hopefully <zamfofex>Hello, everyone! I decided I wanted to continue my Hurd endeavors. I want to set up a substitute server for the Hurd, and eventually hopefully make it public. <zamfofex>Right now, I’m trying to figure out the best way to make the packages from a childhurd available as substitutes. I remember having trouble setting up Cuirass with a childhurd before, so maybe there is some other way for me to try. <zamfofex>Conversely, I have been thinking maybe it’d be possible to skip a VM entirely, and set up Cuirass on the Hurd running directly on a VPS. Does anyone know whether it’s possible to run Cuirass directly on the Hurd? <zamfofex>(Sorry for interrupting the ongoing conversation…) <klm>rekado: Are you Liliana? I've updated <https://issues.guix.gnu.org/57361#6>, but I don't know whose notified and I don't mean to nag. Is the usual process just to CC everyone involved on the debbug-emails? <antipode>sneek: later tell civodul: It failed, again. This time, with more information. The gdb failure is caused by the dejagnu failure for which an upstream-recommended work-around is available at https://issues.guix.gnu.org/57316 <klm>antipode: haha, of course! that would have been a better guess. <antipode>klm: Everyone involved on that particular issue, yes. <antipode>I believe responding to a NNNNN@debbugs.gnu.org to count as implicit permission to put those responders in CC (as long as its relevant, and assuming they didn't opt-out) <klm>antipode: Ok thanks, I'll do that next time. Meanwhile, I'll wait for lilyp to show up here <davidl>Luk6655: I can send you an example of how to remove the last part after some string is found, which you can probably adapt. <dthompson>a link to savannah made it to the HN front page so that could be part of the issue <dthompson>more accurately, a link to a mailing list archive where rms includes a link to savannah. <apteryx>dthompson: what are you referring to? <ulfvonbelow>apparently the default target for grub-efi is i386-pc, but the only architecture under lib/grub is x86_64-efi, and the grub-efi bootloader never specifies --target <apteryx>any idea why on some system, in a 'guix shell --container', Make's $(CURDIR) can be referred to (e.g. on Guix System) while on some other Uthing system it doesn't? (file not found) <apteryx>in other words, sometimes Linux is able to map an absolute path in the container, but not always... <boji>Hey guys, what can I find for flatpacks in repo? <boji>tried a few ones but no luck yet <apteryx>boji: 'guix' or 'people' is preferred to 'guys' here; I'm not sure what you are asking about, but perhaps it's a question for #flatpak? <zamfofex>apteryx: I think Lucovic mentioned that Savannah seemed to be either down or really slow. <boji>apteryx: thanks for reply, no offense ment. Was searching for software that i can open flatpacks with, few ones that I knew from before arent in repo, so was asking for suggestion of software that can be found in repo :) <apteryx>ah! opening flatpak archives, as running them, or just consulting their content? <boji>For now just runing would be good as I familiarize myself with guix and linux in general <apteryx>there is a 'flatpak' package in guix <apteryx>if it works like any other package manager, it probably has an 'install' command. <boji>Excellent, installed it thanks :D <zamfofex>I just recently wrote an explanation of some features of Guix I like to someone who isn’t familiar with Guix! I was wondering what y’all might think of it (i.e. remarks, thoughts, etc.) <zamfofex>(The URL is a screenshot of what I wrote.) <lilyp>zamfofex: obligatory gcc-toolchain@10 😜️ <apteryx>hmm, 'guix shell --container --expose=/usr/bin/env -m manifest.scm' leaves me with sh: /usr/bin/env: No such file or directory on some foreign distribution <lilyp>is this on /usr-merged foreign distros or is there no such pattern? <zamfofex>I think the issue is that your ‘env’ executable refers to your system’s linker, which is not available on the container. <apteryx>there doesn't seem to be any symbolic links involved <apteryx>zamfofex: I think you've nailed it! thanks. <apteryx>this ugly incantation works, by sharing a Guix-provided 'env' as /usr/bin/env: $ guix shell -C --expose=$(guix build coreutils | tail -1)/bin/env=/usr/bin/env -m manifest.scm file <zamfofex>I feel like it would be nice to be able to set up symlinks in the container with some option. I came to need that in the past. In apteryx’s case, the workaround worked, but I remember running into a problem when the executable depended on a file from a different package. In that case, I needed to also explicitly list the package as an argument to ‘guix shell’ so that it would make its dependencies available in the container. <lilyp>I think this would be easier with --link-profile <zamfofex>Well, no, I think, because you can’t tell it to create a link, even among files/paths in the container. <zamfofex>So you can have e.g. ‘~/.guix-profile/bin/env’ in the container, but you can’t tell it to create a link to it at ‘/usr/bin/env’. <efraim>looks like I'll need to create my own disk format for creating a disk image for riscv64-linux, it looks like it does really want the named partitions, not just the disk offsets <dthompson>apteryx: (a little behind here) there were complaints about savannah running slowly and it's possible that an rms mailing list post being featured on the front page of hacker news was the cause. <dthompson>s/complaints/observations/ no one was complaining <abcdw>rekado: guix time-machine -- build rust-once-cell fails for me and a few more people as well with: http://ix.io/49Pb <apteryx>dthompson: ah, thanks for explaining <dthompson>np, should have given more context in the first place <zamfofex>About my Hurd endeavors: I guess no‐one here immediately knows whether Cuirass could run on the Hurd directly, so I suppose I ought to just try it. 🤔 Though I wonder if there is an installer for Guix on the Hurd, or if it’s only available for Linux. I don’t know, though, any kind of advice would be appreciated, honestly. I just don’t want to spend a lot of time on something hopeless. <antipode>zamfofex: There is "guix system vm --system=i586-gnu" <antipode>I don't think the installer is currently cross-compilable <antipode>(at least, there have been some patches to make parts of it cross-compilable) <antipode>So currently I think making an installer would be hard unless you already have a hurd (childhurd?) <sneek>Welcome back civodul, you have 1 message! <sneek>civodul, antipode says: It failed, again. This time, with more information. The gdb failure is caused by the dejagnu failure for which an upstream-recommended work-around is available at https://issues.guix.gnu.org/57316 <rekado>abcdw: the problem is with rust-parking-lot-core 0.9.3 <zamfofex>civodul: I see! To make sure I understand, by “isolated builds”, you mean “builds running in an isolated container”? <antipode>civodul: On the guix-daemon (but not Hurd), I've noticed in the past there is some dead code, what would you think of a patch removing it, to bring a little more clarity to the C++ code? <civodul>zamfofex: yes, exactly (some call it "hermetic builds" these days) <zamfofex>Though is there any reason that this ought to block being able to provide substitutes for the Hurd? I mean, I understand then a build might not be reproducible, but supposing I assume that packages are going to be diligent (or that I don’t care about reproducibility), is there anything that ought to prevent me from providing substitutes? <civodul>antipode: i'm all for it (i did a pass based on a coverage report a few years ago, but maybe there's more) <antipode>If only I remembered _where_ the dead code was ... <civodul>zamfofex: i don't know if it should be considered a blocker; i guess we could try and build things a bit further even if it's not clean, but we'll have to keep in mind that it'll haunt us (e.g., builds will succeed one day and fail another day, because the env is too loosely controlled) <civodul>antipode: you can build+link with --coverage, run "make check", run "lcov", and check the report <zamfofex>I can understand if you don’t want to provide substutes for yet yet because of it, but I wish I could figure out a way to do so myself, at least, since it seems no‐one has done it yet. <civodul>zamfofex: yes, i agree we need to move forward somehow (and i'm sorry i left patches of yours fall through the cracks!) <zamfofex>civodul: Also, would it be possible to have Hurd translators (or their packages?) be added as implicit inputs to packages and invoked automatically then? Only for packages specifically, I mean, where if something else (other than a package) wants to use them, it’d need to explictly invoke them. <antipode>civodul: Was adding to AM_CXXFLAGS sufficient? <civodul>antipode: you can prolly do: make CXXFLAGS=--coverage LDFLAGS=--coverage <civodul>zamfofex: that's the whole question: should they be (implicit) inputs? or should they be pulled in and spawned by the daemon? or just a subset of them? <zamfofex>Is there any advantage to having them be spawned automatically by the daemon without being explicit inputs? It seems less elegant. <zamfofex>Or implicit inputs (of packages), I mean. <antipode>Seems to work, now waiting for "make check" to complete for accurate coverage data <zamfofex>civodul: I see. That doesn’t really answer my question, though. The section brings up useful characteristics of requiring the translators to be defined as inputs, but none against it except “most builds would require it”. <civodul>zamfofex: sorry; no there's no advantage to having the daemon spawn them; however it might be difficult to do things cleanly, because you might end up into chicken-and-egg (TOFU-and-soja?) issues <civodul>like, you need pipe(2) to be working right from the start <civodul>but you don't have pipe unless you've brought a Hurd build (providing pflocal) as an input <zamfofex>I see. To me then, ideally, the choice should be to reduce the number of things the daemon makes available in the build environment as much as possible without causing difficulties, then to progressively work on reducing them further going forwards. <muradm>is there a base linux kernel config of necessary features for guix which can be used as base for custom linux kernel config? <rekado>hmm, my yasnippets in magit are no longer loaded automatically <muradm>i see %default-extra-linux-options but this looks very tiny <rekado>abcdw: I fixed the rust-once-cell problem, will push in a moment <rekado>abcdw: is 956a79b9b2ba555bf41aafe0c44b9a68a8d6c37a your commit? I think it might be the reason why my “add” and “update” snippet is no longer expanded in magit. <zamfofex>civodul: Also, on the patch you linked, is there any reason sometimes you wrote e.g. ‘#ifdef __GNU__’ and others just ‘#if __GNU__’? Shouldn’t it always be the former, ideally? <civodul>zamfofex: both work, but you're right <rekado>I’m generating a global script with special-files-service-type; I want to run this once when the system starts. <rekado>what can I do to make sure it is run after special-files-service-type has created it? ***justache is now known as justache_test
***justache_test is now known as justache
<acrow>Looking for a shortened search for how to convert an existing rsa public key to the spki format required by /etc/pki/acl? I've got it in guile-ssh but how to export it in spki format? IOW, I'm looking for something like (public-key->spki-string my-pub-key). 