<lechner>sneek / later tell oat / I believe CSM allows you to boot from disks partitioned with fdisk while some modern EFI implementation require GPT (gdisk). either way, GPT is far superior with respect to disk size. it also keeps a backup elsewhere on the dist
<sneek>oat, lechner says: / I believe CSM allows you to boot from disks partitioned with fdisk while some modern EFI implementation require GPT (gdisk). either way, GPT is far superior with respect to disk size. it also keeps a backup elsewhere on the dist
<euandreh>lechner: I believe the issue isn't about ordering or depedency, as I am already able to install guile-heredoc locally on my system.
<euandreh>The thing is: when Guix is pulling from a channel, how can I tell it: hey, before pulling, load this module
<euandreh>hmmmm, it does, I bet this is what I am after
<apteryx>pro tip: do not use exec* in your mcron jobs if you want to see the annotated exit status
<oriansj>lechner: not anywhere that I can see. So it is either guix system reconfigure input validation is off the reservation or the syntax had changed between those 2 versions. I have no idea of which
<oat>Hello rekado: How many times have you used Guix?
<oriansj>in related news I finally figured out how to get iwd to work (still has rough edges but): I needed to add the following under services: (dbus-service) and (simple-service 'iwd-dbus dbus-root-service-type (list iwd))
<oriansj>and then I manually had root run: /gnu/store/crdv76dqr7vdhicikqdf1896xhhq2d43-profile/libexec/iwd (I still need to figure out how to make that a shepherd service so I can stop manually starting it)
<oriansj>and just adding only those 2 lines magically broken DNS lookups??
<lechner>oriansj / what are the contents of your /etc/resolv.conf, please?
<oriansj>(this has been very educational if not a bit painful)
<lechner>oriansj / do you have a DNS resolver running on 192.168.10.1? there are benefits to local resolution, but in a pinch you could add a line reading "nameserver 18.104.22.168"
<lechner>oat / i believe that CSM is an implementation-specific BIOS emulation mode. none of my equipment has it. i find it hard to believe that graphics equipment runs more slowly under X or Wayland because Linux does not rely on the emulated layer, but anything is possible. for example, CSM could limit the number of interrupts and force some Linux drivers into polling
<oat>oriansj: Thanks for sharing. It's actually a useful file, congratulations.
<oat>lechner: Something happens when I install from the CSM the resolution was lower than UEFI. It's possible that BIOS enables something in the graphics hardware.
<lechner>oat / maybe the CSM layer causes the card to advertise lower capabilities, which then causes a misidentification in X/mesa/Wayland. you could check the logs. the CSM may also alter your northbridge configuration or bus speed, which is something our graphics software might not detect. all of that can be investigated, but i think you are better off going with UEFI
<minima>hi, i use 'plain-file' to build a file out of a string; is there any smarter alternative to 'plain-file' when dealing with a scheme expression as opposed to a string? this is the particular context i'm referring to: https://bpa.st/6Z4A
<nckx>ACTION considers ‘GET /guix/$revision/file-list.db’ a ‘query’. Sending actual per-file requests to the server would be silly.
<reyman>how did you do when a compiler search llvm-ar into CLANG, gnu/store/zfs41ixykm4z9162gajgs1ndc6bsbcqr-clang-13.0.1/bin/llvm-ar and not into gnu/store/llvm/bin/llvm-ar ?
<elevenkb>Hey there, I'm trying to package foliate (a GTK epub reader), but I get an error when I try to evaluate the definition in a repl, `unknown file:#f:#f: encountered raw symbol in macro output in subform socket of (current-location-vector)".
<nckx>reyman: I'm also not familiar enough with clang to give a specific answer (and the answer will probably depend on the compiler in question, more than it does on clang). But the general answer is ‘patch the compiler, *somewhere*, to look in the right place’.
<nckx>elevenkb: Does ~/.config/guix/current contain what you mean? The final answer is ‘in the store’, but guix/current always points to the right place.
<nckx>reyman: Good plan. Sorry, I can't say exactly what needs to be patch—or even if patching is the best option—without diving into the package myself. If using clang-toolchain as an input helps get you a rough working version, that's fine for now.
<elevenkb>nckx: I was just pointing out how the info manual section for Guix titled "The Perfect Setup" explains that you just have to add your checkout of guix to `'geiser-load-path'; presumably this means that you don't have to fiddle around with `pre-inst-env` to launch a repl.
<nckx>Sorry, that elevenkb: line was supposed to be for PotentialUser-20.
<oriansj>^in the future I hope to convert it to a guix setup but my wife would be upset if I caused an extended local network outage. So I am only converting the systems she doesn't use at this time to get the practice needed before I start attacking more critical infrastructure.
<ph03n1xaimverncc>@[unmatched-paren] Thanks a lot for helping me out yesterday. I was setting up a server. You're such a geniunely helpful person and I am highly grateful to you. I could learn a lot from you. This community is awesome and I appreciate being a part of this. Thank a lot again!
<ph03n1xaimverncc>Guix is amazing for servers and desktop. I'm on guix on a thinkpad (newer one, waiting to get my hands on an old OG thinkpad)
<lechner>elevenkb / i have never used gjs but executables not finding things is pretty common in Guix
<lechner>elevenkb / the reference to Main.js either happens with the wrong leading path or none at all. the usual rememdies are to amend the path, or if that is not possible change the directory. there may also be solutions via environment variables
<elevenkb>thanks lechner. issue is that my understanding of how the search path works suggests that this just _cannot_ be happening :p
<lechner>cbaines / nckx / abrenon / regarding apt-file, i am not sure a database is needed. how many DISTINCT (as in psql) relative paths do our substitute servers provide? it would be the superset of all relative paths under the hashed folders in /gnu/store, but counting a path only once even if it appears in multiple versions (which is likely)
<ardumont>also, implementation-wise, maybe just having something that indexes information on the user's machine would be enough?
<ardumont>(afaict, that's what nix-index does for example, there is ~/.cache/nix-index/files sqlite db in there)
<mirai>can someone eli5 what "declarative counterpart of ___" means? (in the context of gexps)
<civodul>mirai: the "declarative counterpart of PROC" is an object (record) that represents the action that PROC would perform
<civodul>e.g., a <computed-file> record denotes what 'gexp->derivation' does
<civodul>often that's not a super useful piece of info :-)
<civodul>@ardumont indexing can be quite costly though, if you want to map files to actual package names/versions
<stevenroose>So I would like to take a program that is in the guix main channel, but install a few different version of it. I can find the commit hashes of where the different versions were released, how would I go about this?
<stevenroose>Should I create custom package manifests for like program-1.0, program-2.0 and use the manifest syntax to fix the channel to the commit and then somehow install the programs from manifest?
<civodul>ardumont: i often use guix shell -CP or -CPN
<civodul>that's convenient when hacking on things that spawn processes and might leave them behind
<civodul>you know you can always exit 'guix shell' and everything's gone
<Michal_Atlas[m]><stevenroose> "So I would like to take a..." <- There's a package transformation for this, look through the manual. Something like --with-commit should allow you to straight up just install th package with that version, no editing manifests required.
<ardumont>Michal_Atlas[m]: yes, somewhat related to this, but my script are bash one for now ;)
<lechner>ardumont / civodul / Hi, and thanks for the local index idea! when yearning for apt-file I'm mostly interested in executables that aren't available on my equipment. stripped of versions, the information may not change often and, when compressed, may be small compared to our other downloads so that it could potentially be searched locally, at least on demand and for the time being
<nckx>ardumont: That's what people do now: ‘ls /gnu/store/*-*-*/bin/foo’ or ‘find /gnu/store >db’. Nicer, but not much nicer.
<unmatched-paren>i suppose you could have something like ``guix find --no-refresh'' to disable re-downloading the database for that invocation
<nckx>I'm sure whatever model is chosen will provide opportunity to add fine-tuning options.
<lechner>tricon / nckx / unmatched-paren / cbaines / having lived under apt-file for years, i believe this is a nearly perfect use case for GraphQL's microqueries. for Guix, the download database approach is particularly wasteful because we recompile so often
<nckx>Anyway, it's clear there are just 2 approaches here; whether one approach uses graphql or SQL like queries or regexes to type into the virtual /search.php text box in the sky is, to me, an almost irrelevant detail.
<nckx>It would be cooler if there's some fancy modern algorithm that could bridge the two, but I don't know of any beyond ‘grep a huge local db that goes stale quickly, then go to the HTML search box in the sky’.
<mirai>won't that cause inefficiencies by importing the same module for each call to serialize-type ?
<lechner>ununmatched-paren / i am not sure it is overengineered. it is less centralized. you need an executable, and your peers tell you what they have to offer. it could even include the substitute servers
<unmatched-paren>lechner: no, no, i'm talking about the "parse the makefiles" idea :)
<nckx>lechner: Let's keep it tied to substitute servers. We eventually want to decentralise those (there is already very gross ‘P2P’ support over avahi) anyway, and the file-search function would move along with that. It shouldn't be a separate service.
<lechner>people can opt in. submitters would offer a list of hashes first. my service would return those it does not yet have
<lechner>and then receive whichever information participants are willing to share
<nckx>ACTION looks at their ath9k cowering in the corner. Hush, come back, it's OK, it was a joke; nobody does more than 10 MB/s.
<nckx>lechner: The next step would be to get rid of the ‘locally’. Which is what you'd be building with your extremely specialised distributed-file-list-service, so it makes sense to keep that & substitute distribution (and signature athorisation) together.
<whereiseveryone>sneek: later tell nckx how many cold hard belgian franks they pay for the substitute service?
<lechner>nckx / why would i discriminate if someone has an executable that i want but which is not available from the substitute servers? i'd even allow participants to send a pending bug number, so people can throw in their support and upvote the patch
<nckx>I feel like I'm 11 again and Sophie's angry with me and sending her reps.
<nckx>ACTION still has a few Belgian franks in their pen-drawer, but they wouldn't even cover their own cost of physically converting them. I'm not sure if you had an actual question about hosting costs, whereiseveryone, so I can't answer seriously.
<whereiseveryone>I'm looking to host a substitute server again but trying to find a cheap way to do it
<nckx>lechner: I think you misunderstand what I mean, because I don't understand what you mean (oh dear).
<lechner>efraim / has anyone seen a FAT section with 1024 bytes?
<lechner>nckx / people could also remind their peers to submit private patches, or packages in their private channels. the docs discourage private channels, and i could help
<nckx>whereiseveryone: Probably not; little is cheap in Belgium, certainly not power & land & bandwidth.
<whereiseveryone>unless I accept public donations to cover the costs of a substitute server for guixrus but not sure how I feel about that. Just don't want to pay $20 a month right now for a powerhorse
<nckx>lechner: You are clearly off inventing something no longer related merely to ‘which package provides ls’, and that's great, but it's also not related to what I was discussing.
<whereiseveryone>the US government should just provide Guix substitute servers covered by our tax dollars
<lechner>nckx / i don't get it. i would provide exactly that answer
<nckx>whereiseveryone: My server landing page used to literally say ‘I pay Belgian prices for this’, for that reason :)
<jgart[m]>I remember a common lisper/nix user telling me that they didn't see the point in packaging a particular version of a series of packages but instead just generating the package versions you need for your particular project and then "locking them" in
<jgart[m]>I won't touch any more rust until I fix or create a new etc/committer.scm that does what I envision it doing
<nckx>jgart[m]: There are channels that package an automated part of the world, with the expected trade-offs (some stuff is just uselessly broken, but there *is* more stuff). I think that's the right model: a well-curated core; channels for bots. Maybe our core is too big if it's unmaintainable, but I still think the model's OK.
<jgart[m]>and the importer needs to not print unknown-license! blah blah
<jgart[m]>nckx: Oh that was probably me imagining that irc supports markdown code brackets
<jackhill>jgart[m]: probably. Or maybe shell out to jpm? Perhaps the former. Importer is out of scope, I think, for the current patchset. I plan to submit it once I get a build system a a few example packages, leaving importing as separate work later.
<jackhill>jgart[m]: I probably should have stuck closer to you definition to start with, but banging my head against it is a good way to understand. What I have so far: https://paste.debian.net/1262304/ I'm not sure yet about needing to wipe out the default configs.
<jackhill>heh, glad to hear that it's not just us.
<jackhill>I like the idea of using copy-build-system. Left to my own devices I probably would have started with gnu-, but copy- seems more appropriate
<jackhill>jgart[m]: are you sure the guixrus jpm package works? I don't think it is for me.
<jackhill>jgart[m]: one problem/fix: setenv doens't need the = like make flags
<podiki[m]>I believe this came up before but not seeing a bug report..."sudo herd rules udev" does not work yet referenced in the manual
<podiki[m]>I can submit a bug report, but anyone have any leads? or workaround in the meantime?
<podiki[m]>there's /run/current-system/etc/udev/rules.d to answer that
<podiki[m]>it has come up before but as far as I know there's not good proposal on how to do that exactly, though some definite uses that people want (say encryption keys for boot so only one password)
<lechner>to rephrase, is there anything in the store that anyone would be uncomfortable sharing?
<podiki[m]>there shouldn't be (I'm allowing that something might have sneaked in that shouldn't have, but I don't know of any)
<podiki[m]>afterall, we have publicly available substitutes that anyone can download
<mirai>is there a way to "warn" and deprecate a field when using define-configuration?
<singpolyma>I would love a solution to this, but admittedly have not spent much time trying to think of a solution myself yet
<apteryx>and no it shouldn't be needed; I didn't know that inherited all the phases from linux-libre
<podiki[m]>apteryx: I haven't looked at the code either, but that was my guess
<podiki[m]>why is that phase slow anyway, it can only run single-threaded for some reason? (not a big deal for a kernel compile though it is a decent chunk of time)
<mirai>apteryx: but there's also 'playlist-dir' and possibly the 'address' field as well, should I copy-paste the "(define-with-syntax-properties (warn-target-field-deprecation" from bootloader thrice and tweak the message?