<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
<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?
<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:
<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.
<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>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>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
<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>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)'
<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
<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
<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
<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
<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.
<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…)
<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
<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
<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>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
<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>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.
<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
<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.
<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).