***Rooks is now known as Carmen
<excalamus>where is my guix profile located? I'm using the guix system. I don't see a .guix-profile directory, nor is there something like $GUIX_PROFILE declared <excalamus>the docs say $HOME/.guix-profile, but that doesn't seem to exist for me <excalamus>got it, was't thinking and was doin `cd ./guix-profile` <nckx>And here I was typing my 3rd sentence about how system and user profiles work on a fresh system… ☺ <nckx>Don't be? 'T was funny, nothing more. <nckx>GUIX_PROFILE isn't a global variable to rely on, just to be clear. <nckx>It's not really a thing. <excalamus>okay, good to know. I'm not seeing it anyway in `export` ***Carmen is now known as CarmenRooks
<excalamus>the problem I'm trying to solve is that when I do `package -u`, it errors with conflicting entries for harfbuzz. I asked previously and lilyp said that's because of propagated inputs; that different versions of harfbuzz <nckx>Two things propagate harfbuzz and must be updated together. <nckx>It can quickly become insane ☹ <nckx>Guix should tell you which packages to upgrade if you can follow? <excalamus>how do I do that? When I try to upgrade the packages listed, it just takes me in a circle <excalamus>Try upgrading both `xfce4-panel' and `harfbuzz', or remove one of them from <nckx>And guix package -u xfce4-panel harfbuzz doesn't work? <nckx>Pasting the full output (if any) would be of interest if so. <excalamus>it then says "hint: Try upgrading both `xfce4-panel' and `libnotify', or remove one of them <excalamus> `guix package -u xfce4-panel harfbuzz libnotify` <excalamus>I keep doing that until I have `guix package -u xfce4-panel harfbuzz libnotify dbus-glib dconf qtbase tigervnc-server <nckx>Repeating that process should eventually result in a successful upgrade, even if (1) it might boil down to upgrading your entire profile after all because modern software is a disgusting interdependent ball of snot (2) it would be nice if Guix provided a ‘--just-do-the-needful’ switch, but it doesn't (yet). <nckx>Try upgrading both `xfce4-panel' and `harfbuzz', or remove one of them from? <nckx>Right, that was my omission. <nckx>Running ‘guix package -u xfce4-panel harfbuzz libnotify dbus-glib dconf qtbase tigervnc-server’ tells you to upgrade both xfce4-panel and harfbuzz, specifically? <nckx>So… it's possible for two packages to propagate incompatible ‘builds’ (=different store file names) of the same dependency. <nckx>I'm not sure how you'd get into that situation from a previously working profile though. <excalamus>I was doing work making a package, as seen in the first set of errors <nckx>OK, so that's what's happening: something in your profile demands harfbuzz 2, and something else demands harfbuzz 3, and Guix can't reconcile that. <excalamus>I thought guix handled stuff like this through the `guix package -i thing@1234.5` <nckx>xfce4-panel needs harfbuzz@2 through pango through gtk+. <nckx>excalamus: Yes, but propagation breaks this, hence why it's bad. <nckx>Why do you have harfbuzz@3 installed into your profile? <nckx>Can't you just remove it? <vivien>Maybe it would break some language-specific package manager <nckx>Well, the situation as it is is already broken. <vivien>Are there situations where propagated inputs are inevitable? <excalamus>I haven't killed it yet. Going to hang tight for a sec <excalamus>shouldn't the harfbuzzes be sym links to the store in .guix-profile/bin? <vivien>You’ll find some things under /lib <nckx>harfbuzz doesn't provide any binaries in the default output. <nckx>So unless you installed harfbuzz:bin you won't see any. <nckx>vivien: That's a tough question. They are over-used for sure, but that's because a lot of software assumes the kind of environment that they provide, and there's probably plenty of software that's very hard to make work without them. But if you mean ‘inevitable’ as in ‘Guix must support this, or is broken by design’, I'm not convinced. <nckx>Bit too busy to think more deeply/formally about it though, sorry. <excalamus>okay, all those are version 2.6.4 and that's why guix is unhappy <nckx>Yeah, because it's explicitly installed into your profile Guix will try to pull it up to 3.0.0, but xfce4-panel is holding it back, and the current Guix implementation of this is extremely conservative and won't allow both. <nckx>I've been reading & you can use --do-not-upgrade=harfbuzz, I think, if you're OK with keeping the old harfbuzz. <excalamus>naive question, but why is the propagated input not installed as though I had typed `guix install harfbuzz@3.0.0` <vivien>nckx, I don’t have clear ideas either. I replaced them with *PATH extensions in my guile program, but I’m afraid it just hides the problem. <excalamus>it seems like it's xfce4-panel (by way of pango) which needs (or needed, since it's trying to update to version 3). I don't see a reason to keep the old version <nckx>Because the package propagating it (gtk+) is propagating a package variable, which is the exact harfbuzz that it was built against. It's not propagating the string "harfbuzz" that Guix could later fill in with any old harfbuzz, which is more like how traditional package managers work. <nckx>excalamus: xfce4-panel ‘needs’ (is written to use) version 2, not 3. Guix is only trying to pull harfbuzz to v3 because it's *also* (I think?) explicitly installed with ‘guix install harfbuzz’ for unclear reasons (that's unusual for a library, and could have been an accident?). <nckx>So possible solutions to that are removing the ‘explicit’ harfbuzz from the profile so Guix no longer thinks you, a human, care about it and just follows xfce4-panel's preference, or using --do-not-upgrade=harfbuzz so it doesn't try to give you the shiniest new harfbuzz. <nckx>I'm sorry if that's not clear. <nckx>And it's not a simple problem to solve for the general case, if that's even possible. <nckx>However, Guix's current implementation probably disallows certain combinations that would technically work fine, at the risk of complicated profiles that are harder to reason about… it's not clear how to improve it for everyone. <singpolyma>When I first started my guix journey I thought propagation was kind of the point. But I have learned better and am now working on tooling to make removing all the propagated inputs from the ruby ecosystem possible <vivien>I’m surprised that propagated inputs is a thing for XFCE to harfbuzz. Isn’t the XFCE rpath tuned to get the correct harbuzz? <nckx>Thanks singpolyma. It's a very natural thing coming from other package managers, in fact seems like the most familiar and safe option, which is part of the danger. <vivien>I don’t know much about XFCE and harfbuzz, or even rpath for that matter ^^ <nckx>I was also a bit surprised that something as low-level as gtk+ → harfbuzz needs propagation, but I didn't look it up and am not a ghead. <nckx>Sorry, pango → harfbuzz, I misremembered. <nckx>Ugh, it's because of pkg-config. Of course. <char>Hello, I am wondering if anyone can help me. When I (successfuly) log into Xorg I get "oh no! something has gone wrong. a problem has occoured and the system cannot recover." taking up the whole screen. I have tried: relogging, upgrading packages, deleting /var/lib/gdm/*, using slim instead of gdm, using exwm instead of gnome. removing my .config, .cache, and .local. I reboot after each thing I try. I can log into Xorg as root just <char>fine. I hope it is okay to ask this again. <nckx>Equating Requires{.private,} to propagation, as we've always done, feels like an unsustainable liability. <nckx>Hi char! It's fine to ask things a few times a day. However, if nobody here knows the answer I recommend sending your question to help-guix at gnu.org as well, to reach a wider audience across time zones. <nckx>I know there have been problems with GDM caching too much in the past, and breaking because of it. I don't know where it does so but if something like /var/cache/gdm (etc.) exists, try deleting it. <nckx>So not ~/.cache but something global. <nckx>Since DMs generally run as root, as you haven't logged in yet. <excalamus>yeah, just did a `guix remove harfbuzz` followed by `guix package -u` and all went well. <char>nckx: there is no /var/cache/gdm <excalamus>if I had installed it manually, should it appear in --list-generations? It doesn't (and I've never cleared my generation history) <nckx>I don't use GDM so maybe it's /var/lib or so (which you already deleted, so no further bright ideas from me). <nckx>excalamus: That is my understanding, although I use only manifests myself. <char>nckx: I don't understand how it is a gdm issue if it also happens on slim. <nckx>‘Oh no’ sounds like GDM though. It's consistent with the tone used in other GDM bugs I've heard of. But maybe that's just GNOME in general? Is that what you use? <nckx>I mean useless errors in general, not that one specifically. <char>the dialog definitly looks very gtk-gnome. I usually do use gdm and gnome, but the error persists on slim and exwm. <nckx>I fully admit to being confused about that part, but it's not my stack, I can't really say or guess much. <nckx>Are you sure that it's actually EXWM starting when you select EXWM? Bugs like company. <char>no way to tell since the error takes up the whole screen. Maybe this is a sign that I should stop using gdm and gnome, what do you use nckx? <nckx>char: sddm + Sway, so not really a drop-in replacement. That said, it does, at least, work, which is rather important to me. I'd throw my laptop out of the window or worse if it greeted me like that on a workday. <nckx>I've never actually seen what SDDM looks like because it auto-logs me in. Entering my LUKS passphrase twice is enough sekuritees for me ☺ <singpolyma>If I want to in a build phase find all the source files with a certain shebang line, is there a good helper for that? <dlyons>I'm debugging a shepherd issue where reboot hangs; instead most everything is terminated, including syslogd (according to the logs). Last message on screen is from X Windows terminating. I have to hard reboot the machine. Any thoughts on how to go about debugging this? <the_tubular>Sorry for the wall of text; here's the output of guix pull : <the_tubular>-builder for `/gnu/store/jz40wxxvvczb4apab9nmzqjrf1zh7ch0-guix-package-cache.drv' failed to produce output path `/gnu/store/1lxlmr5ld57zxz1lqvharzflnfk2wndy-guix-package-cache' <the_tubular>build of /gnu/store/jz40wxxvvczb4apab9nmzqjrf1zh7ch0-guix-package-cache.drv failed <the_tubular>View build log at '/var/log/guix/drvs/jz/40wxxvvczb4apab9nmzqjrf1zh7ch0-guix-package-cache.drv.bz2'. <the_tubular>cannot build derivation `/gnu/store/sy9zdly6kzrx2ki9rq0vgcw7ckpz8vhr-profile.drv': 1 dependencies couldn't be built <the_tubular>guix pull: error: build of `/gnu/store/sy9zdly6kzrx2ki9rq0vgcw7ckpz8vhr-profile.drv' failed <nckx>the_tubular: Probably my fault, a missing module import somewhere. *the_tubular slaps nckx around a bit with a large trout <nckx>Which client is that? I've seen it too often to believe it's coincidence. <nckx>slaps … around a bit with a large trout <nckx>Do y'all really type that out? <nckx>I assumed it was a feature of some client. *nckx tried it just in case but hasn't been missing out on a hidden HexChat feature all these years. <nckx>By the way, whenever you're about to type the words ‘sorry for the wall of text’, you should probably use the pastbin in the topic (or another freedom/Tor/human-friendly one). <nckx>6 lines isn't a crime but anything over 3 is generally pastebin material. <nckx>the_tubular: Frankly so was I. <nckx>Trivial to add, of course. <the_tubular>Yeah, I wasn't sure if 6 lines was too much, Above 10 I definitely use a pastebin <nckx>It's a bit much, but I don't really care about 6 if the channel's this idle. <nckx>Oh, you can pull, by the way. It'll even work. How 'bout that. *nckx slaps nckx around with a functional package manager <the_tubular>nckx you seem to be pretty fluent shecme wise, i'd be curious seeing your git repo one day <char>I got removed gnome from my system configuration. Now with both slim and sddm, I log in and the screen flashes and goes back to login screen. With slim, I get a garbled message; something like: "cannot execute startup command". <bdju>if anyone's bored, I would love for yt-dlp to be packaged. it's a youtube-dl fork, so maybe you can reuse most of youtube-dl's recipe. videos lately are throttled to 50-70KiB/s for me with mpv+youtube-dl, but yt-dlp has a workaround for this issue. <bdju>my current solution is a mix of not watching youtube anymore and leaving a video open for 30-60 minutes to fully cache and watch later. it is pretty sad <bdju>audio is still broken in qutebrowser so in addition to not liking watching videos in a browser, I also don't have much of a choice unless I want to launch an entirely different browser than what I actually use <namtsui>oh wow I noticed the throttling, too, elsewhere ***duds-_ is now known as duds-
***betelgeuse7 is now known as betelgeuse
***theruran_ is now known as theruran
***sneek_ is now known as sneek
<vivien>That’s right, I’m blackmailing you into testing my patch. <robin>bdju, looks like the package would be virtually identical to youtube-dl, though you'd probably have to (effectively) copy-paste the ytdl package rather than inheriting due to the renaming <robin>and the shell completions stuff has changed a bit compared to ytdl <bdju>namtsui: yeah it's youtube detecting youtube-dl and messing up the speeds. yt-dlp gets around it by pretending to be the android client from what I heard. used to be if you switched video formats once or twice you'd get better speeds, but that doesn't work for me anymore <bdju>robin: interesting to know, thanks for looking into it <robin>i might try packaging it later when it's break-time (i stopped using youtube-dl because of the throttling...) <bdju>oh, that would be awesome if you did. <jlicht>sneek: later tell jonsger: llhttp, and then node, and then c-ares, and then seemingly the universe :) <robin>bdju, do you want to be credited in the commit, and if so, with what name/mail addr? (Suggested-by: name+email in the git "trailers" is traditional, name can be whatever you like of course) <bdju>robin: sure, I guess. just "bdju" for name if that's fine, and bdju@tilde.team for email <robin>now i'll wait and see if posting to -patches through gmane works... ***yang_ is now known as yang
<robin>posting patches through gmane does in fact work \o/ (though i ought to automate "merging" git format-patch output into gnus...or just start using git send-email and its own smtp support, i suppose) <lilyp>nckx: Did anyone try whether just symlinking the pkg-config files in the consumer works? This ought to be particularly harmless with the GNOME ecosystem, as it uses versioned pkg-config files <lilyp>efraim you might want to send that to 51179 compare it against the submitted one <lilyp>(or improve first, then send) <robin>efraim, what are the propagated packages for? (are they maybe ones vanilla youtube-dl should also be propagating?) <lilyp>I don't see vanilla youtube-dl complaining about them missing <lilyp>and if any, we ought to patch PYTHONPATH in the executable instead imo <robin>hm, it seemed almost pointless to inherit from youtube-dl (given s/youtube-dl/yt-dlp/ in many strings), but yt-dlp could at least reuse the fix-the-data-directories phase <lilyp>I think at least the synopsis and the license can be saved, more if the inputs are the same <robin>imho youtube-dl should just have pandoc in native-inputs and use the git repo as origin, then there's no need to worry about pregenerated files (afaict) <lilyp>Well, we could do the pandoc for youtube-dl thing, but that'd be a two-patch review then ***duds-_ is now known as duds-
<robin>(i actually have no idea what the sys.prefix/"pass the prefix directly" comment is referring to, maybe the fix-the-data-directories phase?) <lilyp>'/gnu/store/76sq54dz5yb4qajzg8p02s2kzzwgq8cn-python-3.8.2' <bdju>will mpv pick up yt-dlp being there and use it or does the binary name need to be changed or symlinked to youtube-dl? <robin>i doubt it looks for yt-dlp, but there's a ytdl_path option (--script-opts=ytdl_hook-ytdl_path=..., if i'm reading the manpage correctly?) <robin>might be worth putting a "youtube-dl" shell script that just execs yt-dlp early in your $PATH if you want everything to use yt-dlp by default <robin>i was able to reuse zero of youtube-dl's extra phases :p but inheriting did save a few LOC, and if youtube-dl is changed to include pandoc in native-inputs they could share a bit more <sailorCat2>Hi, is there a list of good unofficial channels for guix? <robin>and indeed, yt-dlp did need python-mutagen, python-pycryptodomex (replacing pycryptodome i guess), and python-websockets, though it seems to work with those as regular inputs <lilyp>sailorCat2: Guix Past and Guix HPC if you're into that :P <vivien>Is there any chance to get fibers merged into guile at some point? ***daviwil_ is now known as daviwil
<robin>vivien, did you mean to post in #guile? <vivien>Last time I tried my message did not show up <robin>vivien, weird. well, i cross-posted your question so you may want to check the #guile logs later <lilyp>vivien: You need to be registered to post in #guile <lilyp>tfw you're bootstrapping Guix on a new system from an old 1.0.1 CD and certificates fail <lilyp>what? non-volatile memory is expensive <efraim>oooh I finally got offloading setup to my pine64, G4 and unmatched boards/machines <katco>is there a cookbook somewhere for getting guix back into a known state from some kind of messed up store? i.e. the store has not been manually tampered with, but somehow, my profile(s?) cannot seem to get back into a known state. it's like there's something at the root of my graph that got a bad graft or something. <katco>`sudo guix gc --verify=repair,contents` found nothing <katco>maybe `guix deploy` from a machine with a sound store? <robin>that's all i had to suggest :/ i've had (manually-repairable) sqlite problems with the store before, but they were very obviously sqlite-related <jlicht>katco; at that point, I'd rather check my file system <katco>robin: thank you, that's a good idea. i had started to suspect something lower-level when i couldn't reproduce a derivation. <katco>does anyone know where fsk results are logged when run at boot? <lilyp>hmm, some sources claim /run/initramfs <katco>no luck using `$ sudo grep -irl ext4 /var/log` <katco>also no luck looking in `/run/booted-system/initrd`. <katco>it would seem they are lost to time. that seems like something guix should store and move over to the root filesystem once mounted. <nckx>katco: They aren't stored at all. <katco>on a guix system, does the root user keep old derivations hanging around the store from profile 0? what's the right way to manage that user? does it need to also periodically log in and `guix pull` even if there's nothing in its profile? <katco>because i couldn't catch whether there were issues with my filesystem or not <katco>nckx: oh, sorry, are you answering my question about root's derivations? <katco>nckx: yesterday's problems portended serious issues. i still haven't figured out the root cause. <nckx><Did anyone try whether just symlinking the pkg-config files in the consumer works> No idea, lilyp. Not me. <katco>to give you some idea, just now, trying to do `guix pull --no-grafts` in an empty profile gives "error: failed to compile 'gnu/services/base.scm':" <nckx>katco: No, I'd just seen your message about fsck logs. (Good morning Guix!) <katco>i am very confused over here. i can't seem to create a working mental model to latch onto to start getting this resolved. <mbakke>katco: do you have more log context? what is your 'guix describe'? <katco>`guix pull --no-grafts`, after no changes just succeeded ***sneek_ is now known as sneek
<mbakke>oh, so the problem fixed itself? :/ <katco>all the nondeterminism guix is supposed to prevent seems to be popping up <katco>mbakke: i am not hopeful of that. i expect further issues, seemingly at random *nckx wonders how many people have packaged yt-dlp for Guix. Tenth one gets a prize. <katco>so far i've tried to pull `guix system` and all profiles back to minimum package sets with `--no-grafts`, and reboots, to try and get guix back into a known state so it can progress through a known state machine. <nckx>I don't remember that ever existing. <mbakke>iskarian: it seems commit 9fc8ae4171e5da4939a64fc6d684c8b9d85bbe84 forgot to add the relevant files (ref above) <hackeryarn>Do we have recommended setting somewhere? I would be happy to submit a patch with the updated file. I'm just not sure what we want those settings to be. <char>Hello, I am wondering if anyone can help me. When I (successfuly) log into Xorg I get "oh no! something has gone wrong. a problem has occoured and the system cannot recover." taking up the whole screen. I have tried: relogging, upgrading packages, deleting /var/lib/gdm/*, using slim instead of gdm, using exwm instead of gnome, totally removing gnome and gdm from system configuration (This one doesn't display the same error, but still <char>doesn't start the window manager.), removing my .config, .cache, and .local. I reboot after each thing I try. I can log into Xorg as root just fine. <roptat>have you tried moving your whole home away? <char>My bashrc is very minimal, and I did try removing the environment variables from it, I also tried removing .xsession and I don't have an .xinit <charles>roptat: move my whole home directory worked!, now to track down the culprit. ***charles is now known as char
<jlicht>charles: way back in the day, it was `$HOME/.cache' that had something funky in there <char>jlicht: I did try deleting that previously. <sneek>Soheil[m], you have 1 message! <sneek>Soheil[m], efraim says: I'm in and out all day, I'm on my phone now. You'll get better support from the main Guix channel for making sure you have all the substitute servers enabled <Soheil[m]>Although I use Ultra mode for compression, the compressed file is no different in size from the original file! (Tar / 7Z / ...) 🤔 Why does this happen in GuixSystem? <katco>well, my approach of peeling back all profiles to minimum package sets with `--no-grafts`, and then reinstalling packages seems like it might have worked out. that was a really weird state i got my store into. <nckx>Whose ‘Ultra mode’ and what are you compressing? <Soheil[m]>nckx, Example: 7z a -t7z Archive.7z -m0=lzma2 -mx=9 -aoa <nckx>Soheil[m]: What does this have to do with Guix System? Works fine here. <nckx>p7zip doesn't try to look for LZMA. <nckx>Perhaps you're compressing uncompressible data. Are you comparing this against another distro's 7z binary that produces different results? If so, please share more deets. <excalamus>I'm doing a `sudo guix system reconfigure my_config.scm` and it fails. Checking the log, guix-build-gnome-bluetooth-3.34.5 fails to find dbus in what looks like a Python import. <excalamus>I've tried adding (gnu packages glib) to my config, as that appears to be the module that has dbus in it. That doesn't resolve the issue. I'm confused what's going on overall. It's like the guix-build-gnome-bluetooth-3.34.5 is ill-defined <lilyp>the build is not affected by whatever module you import locally ***daviwil_ is now known as daviwil
<excalamus>part of me wonders if importing something like the python build system would resolve it. But doing this in my config feels like the wrong spot. Since it's a package that appears to be failing, I would think that the fix would be in the package definition. <char>roptat, nckx, drakonis: I have narrowed down the problem to the ~/.guix-profile. <char>nckx: when the folder is present in my home directory: no graphical login. when I move it, I can log in. Is that a folder that should exist? <podiki[m]>(e.g. where there is bin, etc, include, .... from the packages installed) <char>podiki[m]: it is to /var/guix/profiles/per-user/charles/guix-profile <lilyp>you're probably hosing XDG_DATA_DIRS <char>lilyp: I do add to XDG_DATA_DIRS in my .bashrc, but that is not causing any trouble. <podiki[m]>yeah, that sounds like it could be it, check ~/.guix-profile/etc/profile to see what it does <lilyp>the fact that you do is a trouble in itself <char>lilyp: Why is it bad to add to it? <lilyp>code to modify environment variables should run in .*profile, not .*rc <char>podiki[m]: export XDG_DATA_DIRS="${GUIX_PROFILE:-/gnu/store/xgm9yg71h4096s5ij3qwdlxxim1s46a5-profile}/share${XDG_DATA_DIRS:+:}$XDG_DATA_DIRS" I have never edited this file manually <podiki[m]>yeah you shouldn't edit it that, it is generated automatically <lilyp>the former is run on login, the latter whenever you spawn a shell thus messing with all sorts of environment setups (in the particular setup of guix, pure environments) <char>podiki[m]: just stuff for flatpak <char>thanks lilyp I'll move it out of .bashrc <podiki[m]>the directory it warns about with share/applications/ .desktop files I guess? that should be fine (but in .profile as lilyp says) <podiki[m]>and of course making sure it is adding to that variable, not overriding <char>is there a way to generate .guix-profile? <lilyp>yeah, it's a command called `guix package' <podiki[m]>not something you touch manually, generated when you install, remove packages, that sort of thing <char>so I can just delete it, then install a package, and it will should fix? <lilyp>no, your config outside of guix is borked, you need to fix that instead <char>it has to be some configuration inside ~/.guix-profile though <lilyp>foreign distros hate it when their precious variables get set by Guix <char>lilyp: I'm not sure how that is possible because when I remove .guix-profile, I can graphically log in. I'm not on foreign distro <lilyp>okay, let's see your config.scm first then ***stikonas_ is now known as stikonas
<char>lilyp: paste.debian.net/1215298 <lilyp>so at the moment it doesn't appear you're using any desktop manager <lilyp>oh wait, you're implicitly using GDM despite deleting it <char>yes, that is meant to be commented out. <ngz>lilyp: about bug#51188: I would, for clarity, put each S-exp within the `format' on its own line, but that's probably a matter of taste. Otherwise, LGTM. <lilyp>should i match the indentation then? <ngz>I would indent at the same level as the #f, which stays on the same line as `format' <ngz>Does that make sense? <lilyp>Ahh, I think I misunderstood <lilyp>I was thinking about the generated code, but you meant the generating code <ngz>Yup. At the very least, you may put "all" and "(string-append ...)" on different lines. <ngz>But again, this is just some nitpicking. <lilyp>i.e. (format #f "..." [newline and indent] all [newline and indent] (string-append ...)) <lilyp>hmm, tbh you do have a point, but I think same line is still readable and reflects the generated code better <lilyp>but I'll await ML feedback anyway, there's no hurry <ngz>Ah. OK. I thought that would be faster here. <lilyp>nah, I have more realistic expectations w.r.t. the bikeshedding potential here :) <char>lilyp: any other ideas about my config? <podiki[m]>maybe try the opposite, of renaming everything in home related bash, env, etc. <podiki[m]>or rolling back your (user) profile, or removing all packages from there (you can switch-generations right back instantly) <podiki[m]>since it seems to be something with your user profile/something in home maybe? <the_tubular>Dumb question, how do you guys keep your config.scm? <civodul>the_tubular: one per machine or, if they're part of the same "group", you might use "guix deploy" and factorize that <civodul>roptat: hey! did you have a chance to look at the web site build failure? <the_tubular>Yes, that's what my plan was but I'm not sure on how to do that <roptat>civodul, there's a build failure? I haven't seen that, but I'm busy today, I don't think I'll have a chance to look at it today <the_tubular>I would like to merge some "group" like have a sub-group that could only install and setup packages that would be relevant to a desktop environement let's say <podiki[m]>can also use something like org-mode to generate the system config from common and custom pieces for each machine <roptat>civodul, is there a bug report? build logs? <the_tubular>But i'm still very new to emacs and very new to guix <podiki[m]>you'll want to look up literate dot files, org-mode, tangle <podiki[m]>I haven't done this for guix system configs, but do it for my other dotfiles <podiki[m]>you can find some guix examples online I thin <podiki[m]>that's the idea then. so you can have different blocks to customize for different machines, and have it combine to output the full config instead of copy/pasting common parts <the_tubular>I'll read more about tangle, I'm not sure on how to take only parts of a config file <podiki[m]>welcome! and like I said, I have seen somewhere people doing this for guix configs, just don't have a link handy. <mbakke>many wayland packages needs updating to work on c-u-f, but their latest versions also wants a newer wayland-protocols which has 3,5k dependents ... are such rebuilds still OK, if they fix more packages than they break? <jackhill>mbakke: I'm in no way an authority, but that line of reasoning is compelling to me (also a user of sway). The tricky thing I guess is knowing ahead of time the fixing/breaking ratio <sneek>Welcome back jackhill, you have 1 message! <jackhill>podiki[m]: aweomse, I've added it to my list of things to test/comment on. <podiki[m]>jackhill: great, thanks! I've been running that (flatpak, xdg-desktop-portal-gtk) and it has been working well for me without needing workarounds like before