***duds-_ is now known as duds-
***Newfangled_ is now known as Newfangled
***Newfangled is now known as GNUfangled
***elais3[m] is now known as elais[m]
***jesopo is now known as jess
<lilyp>should the installer be able to resize partitions? ***jonsger1 is now known as jonsger
<lilyp>well, it currently isn't unless you choose manual config :P <KarlJoad>I have encountered this issue twice now. When I replace the Guix disk with another OS, the Guix disk fails to be bootable anymore. I have to re-`guix system init` the whole system. <KarlJoad>It very well might be my disk, because it is old, but I never had this issue with NixOS. It might be UEFI? <KarlJoad>Also, does anyone use guix home for starting a user-specific emacs server? <KarlJoad>Could you share some of your config with me? I cannot get the server to start. It always restarts several times then dies. <mhj[m]>I’m back to using guix and found that it works excellent in my current setup. I’ve migrated 99% of my applications to purely free software stuff. The only application I still have trouble with is the web browser. I use Firefox but want to migrate to something different. The only problem is the extensions I like. I think icecat has me mostly covered, I just want to move the majority of my stuff out of cloud services and into self-hosting like <mhj[m]>with freedombox or Nextcloud. I’m always reading about data breaches and it’s quite concerning. ***califax- is now known as califax
<KarlJoad>lilyp: So you just call that function inside the home-shepherd-configuration list of services? <lilyp>I use regular shepherd init, so idk how you have to wire that up <KarlJoad>Ahh... I am trying to get guix home to see the service through the home-environment in a user-specific shepherd. <lilyp>I'm really not the right person to talk about this, but have you tried an additional layer of quoting? :P <KarlJoad>I do not think it is a quoting issue. The generated service file makes sense. Although I did just catch a incorrect list, I think. <KarlJoad>lilyp: Does the make-forkexec-constructor function require the command be passed as a list? <jgart>how can I pull only from a given channel? <jgart>for example, only pull from guix past <jgart>or, only pull from guix-science <drakonis>these have dependencies on the mainline repo iirc? <jgart>drakonis, maybe it's a feature that can be added? <drakonis>you can pull a given channel and all that depends on it <jgart>yup, the same you can upgrade only a particular package <jgart>you should be able to upgrade a particular channel <jgart>atleast, I think that would be useful <SeerLite[m]>jgart: You can pin all channels except the one you want to pull <jgart>yup, but I'd like to just say upgrade channel x <jgart>I see that's one way to do it though <jgart>along with more granular channel news <jgart>which package got added in what channel? etc... <drakonis>and which ones got modified but not updated <jgart>ditto for changes (I'd like to see diffed sexps that are not line-oriented) <KarlJoad>lilyp: Just read through some source for the guix home definition of emacs, and it appears the (list ...) is needed. <AwesomeAdam54321>KarlJoad: yes, the make-forkexec-constructor procedure requires the command be passed as a list of strings, that will then be combined into one command <KarlJoad>AwesomeAdam54321: Yep. Just figured that out. That seemed like odd behavior to me. I could not find much reference about that in the manual. <AwesomeAdam54321>KarlJoad: yeah, although to me it looks nicer than having the command be one long string like in make-system-constructor <KarlJoad>It feels nicer, yes. But the fact that make-system-constructor and make-forkexec-constructor have two difference semantics and it not be documented is frustrating. <KarlJoad>The shepherd info page for that stuff makes no distinction about that. ***califax- is now known as califax
<AwesomeAdam54321>KarlJoad: Since I'm already working on contributing to the shepherd manual, I should document the different semantics <KarlJoad>Section 4.4 specifically. Service De- and Constructors <KarlJoad>AwesomeAdam54321: So make-system-destructor is like make-system-constructor in that it takes a string to run, rather than a list of strings? <jgart>AwesomeAdam54321, that would be awesome if you could document that <jgart>why doas stuff need to be downloaded in order to remove a package? <jgart>guix has been downloading stuff for the past couple of minutes in order to remove 5 packages <apteryx>jgart: if you've changed the revision of guix in between, it'll rebuild the profile with new packages, I think <apteryx>wow, 9f526f5dad5f4af69d158c50369e182305147f3b is great ('guix refresh --update' now works with git-fetch sources) <podiki[m]>not explicitly documented in the manual: package-native-inputs or package-propagated-inputs <podiki[m]>though obvious, left me wondering for a moment if package-inputs got all the different inputs <podiki[m]>(and the inferior- and lookup- variants are in the manual) <jgart>podiki[m], what would you like the manual to say about package-native-inputs or package-propagated-inputs? <podiki[m]>jgart: not much, probably just list them along with package-inputs to note there are variants for each type of input <podiki[m]>similar to how the lookup- versions gropu them together <jgart>because the package record is a macro it creates those functions <podiki[m]>how often do you need package-propagated-inputs...not nearly as much as package-inputs I'd guess, but for completeness and to save someone in the future a minute of confusion <jgart>definitely should be documented, I agree <podiki[m]>it would be odd to not have them, but since I didn't see it I used package-inputs (which led to not doing anything) <podiki[m]>yup, just mentioning them all together and a sentence is enough <jgart>podiki[m], there's a ton of helper functions that are public and are not documented either <jgart>that would be a good place to do work too <podiki[m]>actually package-inputs is not even documented, comes in when discussing modify-inputs (which is where you'd want it anyway) <jgart>I'll try collecting them at some point and sharing the list so we can work on documenting them <podiki[m]>obvious enough that just listing them with a few words should be enough <podiki[m]>a lot of it is the more advanced package writing stuff, so people I would guess tend to know where to search for examples or what to look for <jgart>I think there should be a section on common practices for rust packaging with Guix <podiki[m]>"package-inputs & co." under modify-inputs in Package Variants section, for the record <jgart>for example, there's a way that upstream prefers you to decide on whether to bump a version, rename, inherit, etc... and that's not documented <podiki[m]>probably each major language could have at least a style guide or conventions <jgart>the requests made in that review are not documented anywhere <podiki[m]>e.g. python usually propagated inputs (if library), regular if as a binary. it might say something about that already <jgart>so you just have to learn it by reading git history and reverse engineering what people did <jgart>what people did = how they committed rust packages, etc... <podiki[m]>maybe expand the yassnippets more for the emacs (very helpful) <jgart>I've found `guix style` to still have some rough edges <jgart>but, hopefully those will be ironed out soon <podiki[m]>I haven't tried it much, did it once and it messed up my indenting <jgart>it messed up my indentation also <jgart>but it's great that it exists <jgart>we just have to improve it now <apteryx>is the EMU10K1 linux module selected for our x86_64 kernel? <apteryx>grepping the config I see it for other arches, but not x86_64 <jgart>apteryx, re: if you've changed the revision of guix in between, it'll rebuild the profile with new packages: what makes you think that to be the case? <jgart>oh just realized, I should be using a gexps? <rekado>jgart: it happens automatically when python3 is among the inputs <rekado>if it doesn’t happen automatically you can explicitly call the patch-shebangs procedure <dcunit3d>what do i have to do to communicate on debbugs? <jgart>I'll build it again and actually check what got put in the store <rekado>dcunit3d: your first message is always delayed <rekado>it gets better after the first delay <dcunit3d>it's no biggie. it's for the boltd package/service. i have the hardware to test, but i'm unsure of how to do that, per se <rekado>dcunit3d: IIUC they ask to test the patch. You’d need a checkout of the Guix source code, apply the patch(es), and then reconfigure your system with a configuration that uses the bolt-service-type. <dcunit3d>ah ok. is there a faster way to download the patches for a specific debbugs issue? <dcunit3d>does anyone here use google repo for open source? i'm using it to group related git repositories (for various langs/projects), but i'm not exactly using it how it is designed. <dcunit3d>is there a similar tool that's preferred? one that would help for keeping several projects up to date? <rekado>not sure I understand the question; I’m using git worktrees. <dcunit3d>ok, worktrees are similar, but are for maintaining multiple copies of a single git repository, right? repo is related, but keeps track of one snapshot of multiple projects. <jgart>rekado, yeah, it was patched already <jgart>I'll keep that phase in mind for next time <rekado>dcunit3d: I see. Yes, it’s just for different branches of the same repo. I use it to juggle core-updates, staging, wip-*, master, etc in Guix. <dcunit3d>ok. i had seen git worktrees, but i haven't used it yet. i don't think it can be easily worked in with repo, especially if the worktrees are in a bare git repo <dcunit3d>i think for me it would make sense to use repo to track changes, but then worktrees for a copy of Guix where I am building/working <jgart>dcunit3d, didn't realize what you were talking about earlier was about thunderbolt on linux ;) <dcunit3d>yes, i think that bootstrapping content you linked me to will come in handy jgart <jgart>ah ok, you mean for building a package in a guix checkout? <jgart>if so, it looks like you must have already done that <faust45>do i need ethernet connection for guix installation proccess? <roptat>wifi should work if you have a compatible wifi chip <roptat>but if you didn't pay special attention to what you got, it most likely requires a non-free blob which guix doesn't provide <AwesomeAdam54321>If that is the case, you can use a USB wifi adapter if replacing the wifi card isn't possible <faust45>is it possible to skip ethernet conn request in install proccess? <bricewge>Does someone knows why the `opaque-SERVICE-configuration` pattern is for? (for exemple `opqaque-cups-configuration`, `opaque-dovecot-configuration`, etc) <roptat>faust45, not sure, but I think it will try to get internet connection from any device, so ethernet is not mandatory <bricewge>I never noticed this pattern before and I don't understand the goal of such pattern. <roptat>but internet is mandatory, because the installation media doesn't have all the packages you need to install a new system <lilyp>bricewge: the cups one appears to be a simpler record with less configurability <bricewge>Yes but I don't understand why it was needed in this service <bricewge>It could have been written without out it, or am I missing something ? <bricewge>I'm tempted to remove it in cups to add a test of the generated config in a more succinct manner <lilyp>I don't think that'll do: 892f1b7273d57b25940700877a02618fe826cc08 <bricewge>Ok, I get it: `opaque-cups-configuration` is a remplacement to the `cups-configuration` record where you use strings <lilyp>BAM, GOT MY TOUCHPAD WORKING <bricewge>What were you missing to get it to work? <lilyp>it was using the wrong driver <bricewge>I had similar issue with a keyboard in X11, as Guix for the use of the old "evdev" driver <lilyp>okay, why tf does GNOME no longer have right-click context menus? <lilyp>(specifically right click on the header bars) <sneek>nckx, podiki[m] says: I think I found the problem, in short fontconfig (and at least apr-util) propagate expat explicitly, looks like it should be changed to the replacement <nckx>Hi ss2. Has the mail you were talking about yesterday arrived by now? To answer your questions: “who’s admin?” — a small handful of people, numerically I handle most mails but there's a mystery person not too far behind (thanks!); “it posted the same mail a second time” — hm, that should never happen unless it was actually sent twice. Link? “I modified my subscription” — subscriptions don't affect sender moderation at all, but this is little <nckx>known. And yes, moderation (and possible white-listing) is entirely per-address, there's no concept of accounts beyond that. <nckx>bricewge: The point of the opaque records is to provide an escape hatch for users who either know CUPS and don't want to bother learning Guix's Scheme syntax only to rewrite their existing configuration, and/or to allow configurations not (yet) supported by the Scheme wrapping. Guix's CUPS configuration coverage is excellent, so the latter should not be common, but some services have a far more limited Guix configuration record that doesn't include all options. So <nckx>while you *could* write the cups-service without it, it's a very good thing to have and all services should have it IMO. *nckx seems to be writing e-mails in IRC today :-/ <nckx>bricewge: I missed that part of your message: please don't remove it. <bricewge>nckx: Thank your for the explanation! I understand it's an alternative for a `extra-config` but cleaner, as there are minimal default value set by Guix defaults <bricewge>As I didn't understood the reason behind this pattern I wouldn't have remove it and I won't now as I understand why it is. <yarl>Hello, I installed guix binary (aarch64), fairly new to guix and tried `guix environment guix --pure`. Unfortunately, I cannot `ls` : exa not found (and silver not found before getting to bash, but I get to bash anyway). I'm am trying `guix environment guix --pure --ad-hoc exa`. It is compiling rustc right now, I guess I'll have to wait a bit... <yarl>Does these sound normal to you? <nckx>bricewge: OK! Didn't mean to come on too strong, just threw all my thought into one text field 😉 <nckx>*thoughts, I sometimes have more than one. <nckx>Oh, interesting, I usually find myself not as direct as I'd like to be… Thanks for the feedback! <nckx>yarl: --pure means just that: only exa will be available. If you want ls you'll have to add coreutils. You'll notice that even though you get a bash prompt, even bash itself won't be in $PATH unless you add it. <nckx>I don't get an error message about ls when I run exa inside a --pure environment. <nckx>But I didn't do more than run ‘exa’. <yarl>That's my non-guix system that is aliasing ls to exa <nckx>podiki[m]: I don't quite understand why propagation breaks grafting though? I mean: it shouldn't, right? We don't need to replace all propagated foos with foo/fixed, and back, each time we {,un}make a graft… Are profile hooks throwing in some unexpected magic? <lilyp>union-build is the unexpected magic <lilyp>nckx: There has been a bug report, that symlinks are not correctly updated in grafted union builds <singpolyma>I have a use case where I would like a search path set when a library is installed or when it is an input and guix shell -D is used, but when the final package using the library is installed it would not be set... Does it make sense to add the search path spec to the library package in such a case? <lilyp>sounds evil, but search-paths don't propagate to dependents (which we see as a bug) <nckx>lilyp: Should've popped in here sooner, I'd ended up suspecting union-build in the meantime too. Thanks for pointing out there's a known bug report. Less spooky that way. <vivien>Hello guix, if you enjoy reading python packages, then you will be happy to know that my set of patches (53402) is now working! <nckx>I don't enjoy that one bit but I'm still happy for you. <nckx>lilyp: Why evil exactly? Some libraries do getenv (libva is my personal example of why I'd like search paths propagated). Some people consider that evil in itself. Is that what you mean? <nckx>I vaguely remember the cURL authors being in the ‘libraries shouldn't getenv’ camp but don't remember why. <lilyp>nckx: The use case is exactly the opposite from the behaviour we want (search-paths expanded always) <lilyp>i.e. the library wants to sneakily hide its environment variables, which imo is pointless -- we can use wrappers if we want it to take a particular value <nckx>Aaah. I read singpolyma's ‘it would not be set’ as describing the perceived bug (current behaviour), not part of the use case. <lilyp>"The current behaviour is my use case" aka. "Don't remove the spacebar heating" <nckx>Make it configurable through an env var honoured by glibc. <singpolyma>lilyp, nckx: well, I don't so much want to hide the env vars as make them available during development <singpolyma>If I put the search path spec in the application package it will be there when installed (bad) but not be there at dev time (worse) <nckx>I think Guix's complete lack (and I hope: rejection) of all the ‘development environment’ nonsense some other package managers have is a major feature, so I'm not going to participate much in this discussion 😉 *nckx AFK, enjoy your week-end responsibly. <lilyp>FWIW I do think that search-paths should be a first-class citizen of profiles <lilyp>i.e. specifiable in the manifest itself <singpolyma>I think this isn't a problem in most cases because the program that reads the search path and has the spec is a dependency and not the final application (eg Python or ruby) <singpolyma>I have considered adding a dummy package that is just the search path and putting in the application inputs, this fixes at least the guix shell case <Curiosa>Gooberpatrol_66: I think that cgroups equivalent were added on certain versions of Mach and are called ledgers, but they are not implemented in the Hurd and I don’t think they are as priority as x64 and multiprocessing <panosalevro>hi guix. is it possible to use a different init system to shepherd? i'd like to use openrc for example <lilyp>on Guix System? No. On foreign distros? Go ham. <gnoo>yeah, a (use-modules (guix init runit)) would be great, if it was possible <bricewge>Is it possible to get the default value of record field? <lilyp>construct an empty record and get its value :P <bricewge>That's what I did but if not all the fields of the record has default value you need to specify them <bricewge>And you need the getter to be defined. Which is the case for me ATM <gnoo>how do you enable kvm on guix? <gnoo>i get permission denied errors <gnoo>Could not access KVM kernel module: Permission denied <lilyp>gnoo: being in the kvm group helps :) <podiki[m]>sneek: later tell nckx yes, something odd with union-build. I haven't looked at that part yet, but confirmed propagating the replacement package explicitly does not have the same problem. <dale`>What is the correct way for a user to clean up their current-guix generations? <KarlJoad>Perhaps not a question for here, but does Guile have a built-in or library for flattening a list of alists? <nckx>dale`: guix pull --delete-generations[=period] <sneek>nckx, podiki[m] says: yes, something odd with union-build. I haven't looked at that part yet, but confirmed propagating the replacement package explicitly does not have the same problem. <nckx>KarlJoad: Do you mean (apply append list-of-lists)? <dale`>So I'm supposed to use guix gc --delete-generations=current-guix-* ? <nckx>current-guix-* is not, I believe, a valid time period. Try e.g. ‘1w’ instead. <KarlJoad>nckx: Yep! That's what I wanted. Thanks! <nckx>KarlJoad: 👍 A little functional composition gets rid of the need for many (but not all) ‘built-ins or libraries’ ☺ <dale`>Yes, guix pull is what I was looking for, thanks. <nckx>podiki[m]: I got basically as far, totally duplicating your work, because I didn't think to check the bug tracker. Oh well. lily p set me straight. <podiki[m]>only looking briefly at union-build now, but I guess somewhere in building the hashtable...this feels like something very subtle to track down <podiki[m]>but I don't enough about these internals, especially with grafts <nckx>I'm an absolute expert on how symlinks are made, but that's not what you mean, is it. <gnoo>lilyp: thanks! that worked <rekado>panosalevro: system services assume that shepherd is used. It’s not impossible to drop in a different init, but someone’s gotta do the work. <podiki[m]>because somehow the final version part of the library is wrong in the symlink, but the store directory is correct; I see some code with relative paths and symlinks in union.sm but seems innocuous <rekado>it’s not a very motivating task, because we like the fact that shepherd is written in Guile and is extensible <rekado>so if there are things missing from shepherd (there are a *lot* of things!) it would be good to add them <podiki[m]>nckx: someone who could answer when the replacement happens in the package process and what that means for union-build would be handy. could be a timing of when the replacement happens and when union build figures out filenames for linking? (just guessing) <nckx>If everything were working as expected that shouldn't be an issue, though. Unions made ‘early’ would then get grafted, and grafting includes rewriting symlink targets. IIUC. It matters little, as there's clearly some assumption that doesn't hold anyway 🤷 <katco>hey all, i seem to recall someone having to go through the pain of recursively comparing derivations to find an issue. can anyone point me in the right direction? <lilyp>nckx: Ahh, but how are the symlink targets rewritten? <lilyp>I think Guix only rewrites the hash parts, whereas it would need to actually replace the file with the correct symlink from the package <lilyp>tbch I think "grafting" is actually ill-defined in a lot of cases, I'd rather have Guix spend more time constructing a mirror tree <nckx>Hashtag shruggaroo, I'm not guixing right now. But what you describe seems indeed to be the case. I basically retreaded podiki[m]'s steps earlier (again, sorz). <lilyp>I'm not criticising you if it reads that way. I'm thinking out loud towards an audience. <nckx><I'd rather have> ‘Hmmmmm.’ I get it, but I also think that's a slippery slope that's hard (if possible?) to ever get right, once we start with stuff like ‘Guix should rewrite .so versions, it would be so cool’… I'm really hesitant. <nckx>If that's what you mean that is. <nckx>…but hey, I wasn't going to be guixing 😉 o/ <lilyp>I completely get your point, I just think we could solve some issues like double grafting with that <lilyp>But again, as with many of my proposals, I haven't yet formalized them, let alone implemented, so it's hard to say. <podiki[m]>lilyp: re: rewriting of hash parts, do you have a place to see that? but often we use replacements that have a different version number too (or you thinking of that in the store directory?) <podiki[m]>(but why only for union build is there this problem?) <lilyp>podiki[m]: those are typically hidden, because soversions aren't baked in <lilyp>let's say you libfoo-1.2 → libfoo-1.3. Since libraries link against libfoo.so, rewriting works the way we intend <lilyp>note that only /gnu/store/<hash>-libfoo-<version> is rewritten afaik ***Newfangled is now known as GNUfangled
<lilyp>with union builds, this assumption is copied, because libfoo.so plus symlinks are copied <f1refly>what is the recommended way to set theme settings in guix for window managers? I tried lxappearance, but it doesn't see my installed themes. xfce4-appearance-settings does see the installed themes, but switching there doesn't do anything <podiki[m]>f1refly: I don't remember exactly (had similar issue) maybe make sure you have xdg_data_dirs? <podiki[m]>oh, I have a symlink set up for ~/.themes to the profile where my themes are in my case ~/.config/guix/profiles/desktop/desktop/share/themes/ <podiki[m]>so whatever profile/share/themes since I think lxappearance will look in ~/.themes (there are probably other ways but this is what I did if I remember) <zamfofex>podiki[m]: Thank you! 🎉 Any kind of feedback is appreciated!