<nckx>kmicu: No, we can't even get the current owner to correct the damn name (r/GUIX). <kmicu>Isn’t there a takeover procedure like on Freenode? <nckx>I don't know. I've never had to take over a Freenode channel. *kmicu checks what’s the fuss about Hyperbola, Libreware, Saslibre CIA… <oriansj>I vote ignore the reddit community, like we ignore all of the other guix communities on social media that we don't actively engage in <nckx>kmicu: You will find one fact-free hyperbole news post and be thoroughly disappointed. <nckx>oriansj: I disagree. The damage is done no matter how good we feel about ignoring them. <kmicu>Of course it matters for newcomers. <oriansj>newcomers to the guix website will see no links to reddit but instead mail archives and instructions to use IRC <nckx>Nobody cares about our obscure e-mail list or IRC (what even is that?) channel. r/Guix is on Reddit, a real site, so it's official. <kirisime>moewe: You can add configure and make flags with (arguments ...) or edit the build phases. <oriansj>nckx: for idiots perhaps but not for technical people who are curious <nckx>As I said, I completely disagree, if that makes me an idiot so be it. <oriansj>Remember guix is gentoo for grownups. not the distro for uncle bob and grandma <nckx>I don't see that on the Web site either. Which is good, since it's not true at all. <oriansj>nckx: perhaps you and I just have a minor disagreement on what sort of community should be the primary goal of guix <kirisime>What's the origin for "gentoo for grownups"? <nckx>oriansj: I don't actually think we do. I think protecting our name is orthogonal to that. <oriansj>kirisime: the fact that guix is one of the few distros where users can be reasonably expected to build it all from source <oriansj>nckx: there are 1M+ social media sites and guix groups on various *chans. Our name can't be protected by anything but our long term actions <oriansj>hence, why trying to take control from others doesn't help our reputation as much as inviting those others to encourage values and behaviors that makes the world a better and richer place for us all <leoprikler>I take not protecting Guix name over actively using Twitter 8 days per week. <oriansj>speak softly and kindly, encourage people to embrace freedom and the empowerment of all. <oriansj>let others use that freedom to help themselves and their communities in ways we don't yet know about or understand <oriansj>If someone chooses unfreedom on a Service as a Software Substitue platform, to encourage others to embrace freedom for us; let them sacrifice for us. <oriansj>Let them learn how to speak to those we have not yet met; to help guide them to embrace this culture we carefully curate. <pkill9>kirisime: i think it's because it's source-based but also more practical, and isn't immediately tweakable and kind of requires more polished tweaks <pkill9>by immediatly tweakable i mean, for example editing a file immediately changes the system <pkill9>i havent used gentoo so take my opini[00:30:45] <leoprikler> The great thing about Gentoo is, that you're going to waste time building everything from source anyway, so you don't care if you want to customize your package by adding a patch to /etc/portage/patches. <nckx>kirisime: It's a pretty old meme, I've heard it said about Arch Linux and Exherbo before Guix took off. ‘My distro is better than yours’ + ‘you're a child’ in one handy meme, I guess. <leoprikler>That, USE flags and an over-abundance of "overlays" (i.e. channels) <oriansj>essentially we can leverage gentoo users experiences to avoid some mistakes in guix and hopefully take one step closer to a better community. <malaclyps>is a MPL 2.0 licensed project acceptable for the main Guix package repo? *kirisime wants a big computer for doing computer things <kirisime>Since there's a way to pin your channel versions to specific commits, is there a way to pin channels to 'latest stable' or 'latest core-updates'? <nckx>kirisime: (branch "core-updates"). There is no ‘stable’ branch. <moewe>All that it needs to do is copy the result of "make all" to $GUIX_PROFILE/local/share/games/fortunes <kirisime>nckx: I ask because I've had core-updates being merged the day I'd done a guix pull break other channels so I'd like to be able to step from one just-works commit to the next one. Not to mention that I'd like to keep multiple machines and profiles in sync. <nckx>moewe: (install-file "anarchism" (string-append (assoc-ref outputs "out") "/whateverthehelldistro.shspitsout"))) <nckx>Where outputs is a #:key so you'll use lambda* for the phase (plenty of examples in gnu/packages phases). <moewe>so (assoc-ref outputs "out") is the output dir of make all? <nckx>moewe: It's /gnu/store/<hash>-blag-fortune-<version>/. The ‘output’ dir of make all is probably your current working directory. <leoprikler>It's sadly a common thing to see staging/core-update merges break something, especially if that thing happens to be a channel. <nckx>kirisime: If by 'latest core-updates' you don't mean ‘what the core-updates branch points to’ I don't understand. Yes, this will sometimes break and it will rebui[01:01:40] <kirisime> nckx: I just worded it poorly. These branches are merged into the master regularly, but other channels don't take their changes into account until they're merged which means that between the merge and the additional channel maintainers adjusting it there's a window of time when a guix pull might fail. <nckx>A real stable branch (‘just 1.0.1 + security fixes please’) is even more work. Which people don't seem to get. Not you; people. <nckx>kirisime: I think I understand. Don't think there's a magical hack here, sorry. You'll be doing the jobs of a system integrator + tester one way or another. <kirisime>Right. Should I then just ask sneek when's core-update merging time and do my pulls say, a day after that's done? <nckx>leoprikler: Good point. It's 1 a.m. here, kids, go to bed. <nckx>kirisime: That depends entirely on the punctuality of the authors of the channels you use. If they're off to the Bahama's for a month, tough luck. <leoprikler>I remember a certain channel that we do not speak of breaking for more than a day when Qt was updated. <nckx>A day is a tight deadline by anyone's standard. <leoprikler>Besides, core-updates/staging merges can break even things on master that "used to work". <nckx>kirisime: I do something vaguely similar for fun(!): my Linux kernel combines several disparate branches (and is based on a patch set to begin with). There are weeks after a kernel release where they just completely conflict, and there's little I can do but wait until everyone adapts their code. I could do it myself, but that would no longer be fun(!). <leoprikler>Hell, even normal commits on master can break stuff. <kirisime>I guess the core of the issue is unsolvable then. I mean, debian tries... <leoprikler>Well, you could make your debian branch by simply checking which commit is at least 6 months old. <leoprikler>But by that time channels will think your guix is outdated as hell. <leoprikler>(Understandable, as you will have missed at least one, if not two iterations of c-u) <nckx>Channel authors could maintain a parallel ‘core-updates’ branch of the channel which works with the latest unmerged c-u. You'll always be at their mercy (but hey, you already are) and it's more work for them. <nckx>Such conventions might help. I don't think this is a technical problem. <moewe>i need to use "strfile" in my build definition, but I don't know from which module it comes from - guix edit strfile or guix package --search yield no results <kirisime>Does install-file need the directories be present before being called? <nckx>That's the point of install-file: it's mkdir + copy-file in one handy package. <moewe>oh, sorry then, misunderstood the question <nckx>moewe: You're missing a ) at the end of your (let … line. <nckx>So "/local/share/games/fortunes"))))))))) probably has one too many but I didn't check. <nckx>moewe: You can drop local/ from the path, that's a /usr/local remnant. <nckx>I don't know where our fortune(-mod) package looks for fortunes but if it's in local/… that's wrong. <nckx>(Does our fortune(-mod) support additional data files like this yet?) <nckx>moewe: This is a matter of style for later, but we prefer #:tests? #f to (delete 'check). <nckx>The rest looks good on the surface, assuming notabug archives are immutable! <moewe>the default fortunes are in $GUIX_PROFILE/local/share/games/fortunes, so I think I can't drop local? <moewe>I can't test my package because when I try to install it, a different package from the main repo fails to build - can I somehow tell guix to only install one package? <nckx>moewe: I still think local/'s a bug, but it's not your bug so we'll ignore it for now. <nckx>moewe: Are you using ‘guix build’? If so, then no, the package is somehow a dependency. <moewe>but when I do guix package --install fortune-anarchism, it tries to download texlive <nckx>So ‘guix install’ doesn't? For now you should be able to test your package with ‘guix environment --ad-hoc fortune-anarchism <other packages>’. It will enter an environment with the package ‘installed’ which you can ‘exit’ when finished. <drakonis>also my laptop can run guix out of the box, no changes needed. ***jonsger1 is now known as jonsger
<marusich>drakonis, very nice! What laptop, if I may ask? <marusich>Is it just a laptop you happened to have on hand, or did you select it for use with Guix? <marusich>Gotcha. I'm eyeing the Purism laptops and maybe even a Pinebook as my next laptop, but I suspect the Pinebook is probably not much faster than [02:30:08] *** Joins: drakonis_ (~drakonis@unaffiliated/drakonis) <nckx><nckx> drakonis: During the USB install phase? <nckx><nckx> drakonis: If so, which exact command did you need to enter to unblock it? <nckx><nckx> I have a stale patch for this somewhere but nobody was ever able to reproduce that behaviour. <nckx>OK, that's the same bug I had (on an Aspire V5 as it happens, but I'm sure that's just coincidence). <nckx>If you look at the connman code it should take care of that but it seems to forget sometimes. <nckx>My solution was to just call ‘rfkill unblock’ manually. I'll see if I still have that patch somewhere. <drakonis>marusich: the pinebook seems like a reasonable option for a low power consumption computer though <drakonis>its probably much harder to find laptops like mine today <drakonis>not exactly a darling of the free software folks <drakonis>the librem is still better than my laptop <mwette>nckx: enabling substitutes worked <nckx>mwette: It's a mere work-around but glad it worked. <apteryx>I think we'd be able to solve a couple problem if our search-path specifications allowed running random programs (thunks), but this seems complicated to implement (as search-path specifications are serialized to manifests). Thoughts? <str1ngs>drakonis: I recently ordered a pinebook pro <marusich>str1ngs, how does it compare to a "normal" laptop? Does it work with Guix? <str1ngs>marusich: I'm not sure yet, they are shipping in batches <str1ngs>marusich: the specs are pretty nice for the price though <str1ngs>not that I know of, you need to pay to get that certification <apteryx>is there a valid use for adding glibc to the inputs of a package when gcc keeps an internal reference to it? *apteryx is looking at php <raghav-gururajan>sneek later ask nckx: Can manual or cookbook contain links/references to outside source? For example, if a topic is better explained in a outside source, is it okay to put, "For more details, refer to URL".?? <kmicu>oriansj: calling others idiots for not using IRC/ML is not kind. Saying that guix is only for experts is elitism and is also not true in practice. Making an assumption that the goal is to policy +1m social sites instead of only the biggest hubs of community is a basic logical fallacy. <mbakke>rhou: there are a few workarounds in Guix, try "git grep include_next" <mbakke>unfortunately they are fairly package-specific <mbakke>the gist of it is that GCC gets confused when glibc is given as a "system header", i.e. with -isystem <rhou[m]>is there something which can be done upstream? <mbakke>rhou: it might take a while, but i'm optimistic :-) <mbakke>rhou: do you have a build log available? most likely you'll find something like 'gcc ... -isystem /gnu/store/...glibc-2.29/include' shortly before the failure <mbakke>the workaround consists of turning that into 'gcc ... -I /gnu/store/...glibc-2.29/include' <mbakke>which depends on the build system <bricewge>We have the password-store package but no extensions like pass-otp. How one would go to package such extension? <str1ngs>bricewge does pass-otp use messaging? <bricewge>On Nix I was doing (pass.withExtensions (ext: with ext; [ pass-otp ])) to install pass together with pass-otp. <bricewge>str1ngs: No the extension have to go in $PASSWORD_STORE_ENABLE_EXTENSIONS <bricewge>oops s/$PASSWORD_STORE_ENABLE_EXTENSIONS//usr/lib/password-store/extensions <str1ngs>PASSWORD_STORE_ENABLE_EXTENSIONS is a variable where it finds the extensions? <bricewge>str1ngs: It looks for /usr/lib/password-store/extensions/COMMAND.bash <bricewge>Maybe, I don't know the uses of libexec. <str1ngs>I think normally with guix you would use a native search path. but in this case if password-store use looking for a FHS prefix . it might not be easy to do. maybe it could be patched to used a PASSWORD_STORE_ENABLE_EXTENSIONS environment varible in which case you can then use native-search-paths <str1ngs>bricewge: try and see if password-store has an evironment varible that effects the extension path. <str1ngs>it might not since a hardcoded path is probably more secure for this. <bricewge>By native path you mean something like /run/current-system/profile/lib/password-store/extensions? <bricewge>Are you aware of some Guix packages that support extensions in a similar way as pass? For inspiration. <str1ngs>bricewge: but guile uses GUILE_LOAD_PATH which is what native-search handles <str1ngs>bricewge: basically if guile is installed in a profile that file is added to etc/profile . and the varible exported. and packages that are installed to that prefixed will then be exposed. <str1ngs>bricewge: maybe PASSWORD_STORE_EXTENSIONS_DIR will work? <jackchla>I want to use PXE and Guixsd to make diskless clusters. Is there any information on this? <bricewge>str1ngs: Hum. So the system extension path (SYSTEM_EXTENSION_DIR) is set during build time. <bricewge>So maybe SYSTEM_EXTENSION_DIR should point to /run/current-system/profile/lib/password-store/extensions for system wide extensions. <str1ngs>bricewge: I don't know how applicable system wide extensions are. <bricewge>While PASSWORD_STORE_EXTENSIONS_DIR should be set to the user profile for user installed extensions. <str1ngs>that seems awe-fully lot like how other package manager work. <str1ngs>I think of you update password-store to expose a native search path for PASSWORD_STORE_EXTENSIONS_DIR with a suffix of "lib/password-store/extensions" and then any package that install to that suffix will be exposed. <str1ngs>bricewge: I'm trying to think of a use case were you want to have password-store for a while system. this seems like something that you would install to a user profile. <bricewge>True, it's definitely more a user oriented package. <str1ngs>installing packages to the system is a paradigm used by less modern package managers :P <str1ngs>it has valid use cases though. but not a much as you would think. <str1ngs>but with PASSWORD_STORE_EXTENSIONS_DIR I think password-store can handle extensions in a way you would like. <bricewge>Understood. It could be useful for an organization enforcing the use of such a package but not for a lone laptop user. <str1ngs>though PASSWORD_STORE_EXTENSIONS_DIR will probably work for system packages as well <str1ngs>bricewge see echo echo $GUILE_LOAD_PATH <str1ngs>notice it includes the system level path <str1ngs>though PASSWORD_STORE_EXTENSIONS_DIR might not handle : <str1ngs>I would try though . update password-store to use a native search path for PASSWORD_STORE_EXTENSIONS_DIR <bricewge>But pass use a single directory for it's extension, it use it like this "user_extension="$EXTENSIONS/$1.bash"" <str1ngs>okay but if you add only as a user. then there should be only one extension path <str1ngs>and that would be ~/.guix-profile/lib/password-store/extentions <str1ngs>when creating your extension package have it install to (string-append out "/lib/password-store/extentsion") <str1ngs>don't make spelling errors like me though :P <bricewge>Thanks a lot str1ngs I'll go head and implement that to add pass-otp to Guix. <bricewge>str1ngs: What a moron I am!!! It's already packaged, and works! Sorry for making you wast your time. <bricewge>I don't know why I thought it wasn't packaged... <str1ngs>bricewge: yes seems password-store already has a native search path :) <NieDzejkob>nckx: You mentioned bcachefs a few times over here, do you happen to have bcachefs-tools packaged for Guix? <bricewge>str1ngs: Yes it does exactly what you suggested with no system wide extensions. <nckx>NieDzejkob: Yes. I'll send it to g-p@ when I get home. <sneek>Welcome back nckx, you have 1 message. <sneek>nckx, raghav-gururajan says: Can manual or cookbook contain links/references to outside source? For example, if a topic is better explained in a outside source, is it okay to put, "For more details, refer to URL".?? <nckx>raghav-gururajan: I'm not involved in the cookbook. The manual certainly can, grep doc/guix.texi for @uref{. I'd avoid the ‘For more details, see…’ wording unless the link can't be integrated naturally into the text. <nckx>NieDzejkob: You have/know how to build the kernel? <nckx>raghav-gururajan: We do tend to stick to authoritative sources & not link to things like Arch wiki how-tos. Whether your link is considered acceptable will depend on the exact, well, link in question. <str1ngs>sneek later tell peanutbutterandc can you confirm this gives you a midi output port? for export a LD_LIBRARY_PATH like so. export LD_LIBRARY_PATH="$(./pre-inst-env guix build alsa-plugins | tail -1)/lib/alsa-lib" that start tuxguitar like so. ./pre-inst-env guix environment --ad-hoc tuxguitar -- tuxguitar <str1ngs>sneek: later tell peanutbutterandc this is a dirty hack. I'll figure out a better approach. that should give you a midi port that you can use with timidity meantime. <str1ngs>sneek: later tell peanutbutterandc . also use your systems timidity since it requires the same hack. <NieDzejkob>nckx: I don't, but the experiments I want to run only require the tools for now. I'd gladly take a recipe for the kernel too, though. <NieDzejkob>(does Guix have kernel module packages, or is everything a separate kernel package?) <NieDzejkob>BTW, if I'm changing the code of a build system, is that core-updates? <nckx>NieDzejkob: A brute-force ‘grep go-build-system gnu/packages/*scm | wc -l’ already gives 618 results, so yes. <nckx>If it were some more obscure build system it might have limboed under 300 packages. <nckx>NieDzejkob: Experiments… with bcachefs migrate, perhaps? 😛 <NieDzejkob>nckx: it's more of a "where is the superblock, really" right now <NieDzejkob>If I read the source right, it's at +4K, but that's a big `if' <nckx>NieDzejkob: That's only ‘leaf’ packages, though. But who knows. Not me, and I'm not going to find out. <nckx>raghav-gururajan: I'm not involved in the cookbook, at all. <nckx>NieDzejkob: Er, well let me just check my read-bcachefs-superblock procedure 🙂 <raghav-gururajan>nckx I understand. I was wondering if there is any general policy for things like that. Cool! <nckx>raghav-gururajan: I'd personally prefer a copy in the cookbook to relying on outside hosting/sources/licences. <str1ngs>NieDzejkob: you can setup user shepherd services. in ~/.config/shepherd/init.scm here is an example init.scm http://paste.debian.net/1126628. please take it with a grain of salt. to start just call shepherd. the use herd to manage <nckx>Even though it's your article. <NieDzejkob>that's great. I'll still need to get the filesystem actually running later on, though <str1ngs>NieDzejkob: my deconstructs are 100% accurate for those service. I mainly use it to just start services on login <nckx>NieDzejkob: OK… just thought it'd be helpful. Bcachefs can't be used as a module at this time, it depends on unmerged kernel changes. As for that you're better off looking for generic ‘customise kernel’ tutorials with the bcachefs git repository than trying to decypher my mine. <nckx>NieDzejkob: In general: some kernel module packages exist but I think support for simply ‘modprobe foo’ (not ‘modprobe /run/blah/foo’) is still in the patch queue. <NieDzejkob>well, I'm already using a git repo with some pending patches applied as my guix channel <nckx>I just insmod /run/booted-system/profile/lib/modules/`uname -r`/extra/acpi_call.ko for now. <nckx>NieDzejkob: I am torn between suggesting a hexedit:man or :doc output for size reasons, and the fact that nobody will expect that… <NieDzejkob>nckx: the manpage is already being installed, there isn't really a way of making the man-db dependency a separate output <NieDzejkob>(guix size returns 75.9 MiB before, 100.9 MiB after, but the user is likely to have man-db installed already) <nckx>The man page would be part of :man, not :out, which is unexpected, which is my point. <nckx>Or wait, nah, never mind, that's too baroque to patch. <nckx>Yeah. I had some weird wrapper in mind to avoid patching the hexedit binary itself. Probably not worth it. <nckx>Size-obsessed folks will customise packages anyway. <nckx>Ignore me, I'm drunk. (I'm not.) As for your Shepherd service question: don't bother installing anything until there's a semblance of a standard of what these per-package user snippets would look like. <kirisime>There's the patch-dot-desktop-files build phase. I have a feeling that if it's extended to patch .thumbnailer files as well, it would greatly simplify the changes required to gnome-desktop and nautilus in order to make thumbailers work. <kirisime>Namely, the two packages wrap their calls to thumbnailer programs with bubblewrap, which requires certain directories to be bound inside the bwrap container. By default /usr and ld.so.cache are bound, neither of which exist in GUIX, causing the bubblewrap setup to fail. <kirisime>I've written and tested a patch that simply replaces the bwrap bindings with /gnu and /run, which makes thumbnailers installed in the system profile work, but causes the ones in user's own profiles to fail still. <kirisime>The system-wide thumbnailers work in this setup because the given program in the .thumbnailer program is relative and therefore looked up in $PATH. If the thumbnailer program is found in /run/current-system/profile/bin/ before /home/user/.guix-profile/bin/ and /run is bound in bwrap, the container is able to find and resolve the symlink to the actual executable properly. <kirisime>To get per-user thumbnailers working in the same way you'd need to bind the user's guix profiles, or everything in their path. This would require you to make a significant patch to the source code of the packages. <kirisime>On the other hand, just turning the Exec and TryExec fields in the .thumbnailer files to absolute paths might just avoid the need for that and for passing /run to bwrap. <kirisime>I love replacing clear and understandable (when ...)s with hacky and unmainainable (and ... ... ...)s <leoprikler>tbh and makes more sense in guix anyway, since the result of a phase should always be #t <leoprikler>unless you have to introduce a (begin ...) clause for it to work, that's a no-no <kirisime>Do you mean to say that (and ...)s are fine or that they're not? <civodul>kirisime: in general, i'd recommend when/unless instead of a one-arm 'if' <sneek>Welcome back civodul, you have 1 message. <sneek>civodul, apteryx says: thanks for the pointers w.r.t. CPATH and Inkscape compilation warnings. <civodul>likewise, i'd avoid 'and' when it's for side effects <kirisime>So I should replace this thing with a pair of whens. <kirisime>Actually what the heck was I thinking, there can be a package that ships no .desktop files but does ship .thumbnailer files. <bluekeys>Hi guix. What can I do instead of an npm install -g using guix os? <bluekeys>Hi leoprikler. npm is node's package manager. Npm install -g globally installs an npm application. Not sure of the details. <leoprikler>first try to port your npm application to node-build-system <leoprikler>then use it in the packages field of your OS perhaps? <bluekeys>I'm trying to move all my workflow to guix and am finding the world is full of evil sharp pointy things I didn't even know I was using <leoprikler>I'm really not sure whether you'd want that, but if you have some use case for it (e.g. some daemon written in node), then go for it. <leoprikler>if not, you'll feel a lot safer adding it just to your user packages like any other package <bluekeys>OK. That might take some time. Thank-you. I'll take a look at other packages using the node-build-system and report back if I make some progress. <leoprikler>There are currently none upstream, but you can have a look at <mwette>nckx: also, I have to start the daemon manually right now. If I find something useful, I will post to bugs-guix. Thanks for all the help. <erikg>is there any way to have guix install cargo into my .guix-profile? "rust" is a package that includes it, but it's not installed by default <nckx>erikg: guix install rust:cargo. <nckx>mwette: And thank you for the bug report(s)! Wish I could do more than look at 'em & say ‘yup, that's SELinux all right’. ***ng0_ is now known as ng0
<moewe>is arc-theme broken for anyone else? <moewe>it complains about not having permissions and I wonder if I messed them up <leoprikler>building it right now, it seems you'd want to (setenv "HOME" (getcwd)) <nckx>moewe: The permissions errors aren't actually errors at all, just Inkscape noise. How much RAM do you have? <leoprikler>first, there's permissions, next there's the RAM eating of Inkscape <leoprikler>if you didn't kill your build yet, have fun going OOM <nckx>moewe: If you have 8 GiB you should be able to ‘guix build -M1 -c1 arc <nckx>Now it no longer builds with 8 GiB here :-| <moewe>oh damn 8GB for just a theme <nckx>Does sassc have a known memory leak? <nckx>moewe: Nah, this is new, I built it fine last year. <moewe>I think I'll wait for the substitute xD <nckx>moewe: Not if it leaks 192 GiB of RAM and OOMs a build node, which is probably why there isn't a substitute now. <kirisime>Wait, do I need to enable substitutes for pre-inst-env separately? Or am I building literally everything because I've modified the gnu build system? <nckx>Reverting 65e2fe (alone) makes the happiness flow. <nckx>kirisime: No and probably. <kirisime>So I'm bootstrapping an entire new guix system to test a minor change in a build system. <kirisime>And I thought, it can't take that long to build a copy of evince... <nckx>kirisime: There is no such thing as a minor change in a build system… A rebuild's a rebuild, no matter how small. <kirisime>I could write a bash script to do the same thing and map it over the store and be done in less than an hour if I could just mutate the store. <nckx>You've just described nightmare grafts. <nckx>Have you considered: regular grafts? <kirisime>Maybe I'll consider the copy-paste abstraction. <jonsger>why does (inherit) never behave like I expected.. <kirisime>Because while looking at how the thumbnailers look like I found that the generic image thumbnailer has an absolute path in front of it anyways and the package definition doesn't hint at how it gets there. <sneek>roptat, raghav-gururajan says: I just saw your email with regards to closing the bug related to video rendering icecat. But it's still doesn't work. :/ <roptat>raghav-gururajan: I haven't tested, you're talking about Mark's patch, right? <mwette>I have installed the binary under root. Now I want to use guix under my user account. I'm getting errors. I think I need to initialize somehow. For example, I don't have a ~mwette/.guix-profile directory. Is there something like 'guix init' ? <sneek>Welcome back peanutbutterandc, you have 3 messages. <sneek>peanutbutterandc, str1ngs says: can you confirm this gives you a midi output port? for export a LD_LIBRARY_PATH like so. export LD_LIBRARY_PATH="$(./pre-inst-env guix build alsa-plugins | tail -1)/lib/alsa-lib" that start tuxguitar like so. ./pre-inst-env guix environment --ad-hoc tuxguitar -- tuxguitar <sneek>peanutbutterandc, str1ngs says: this is a dirty hack. I'll figure out a better approach. that should give you a midi port that you can use with timidity meantime. <sneek>peanutbutterandc, str1ngs says: . also use your systems timidity since it requires the same hack. <leoprikler>mwette, `guix pull` and then `guix package -i` should work on their own <nckx>mwette: If that doesn't work (your first ‘guix pull’ is basically ‘guix init’), please paste the exact errors you get somewhere. Saves a round trip. <peanutbutterandc>str1ngs, Indeed it is, Mr. str1ngs, a very dirty hack. A rather ugly hack, if I may be so bold, sir. Perhaps it needs a good correction. (Please catch that reference!) <str1ngs>peanutbutterandc: I am working on a fix that uses ~/.asoundrc instead <periappi>Hello everyone! I've been using Gentoo then Archlinux on my everday laptop for some time and am very interested in moving to an os based on declarative configurations. After some researche, I found Guix and obviously Nix. Right now I'm having a really bad time trying to make a choice and hoped you guys would help me. The two main things that are making that choice difficult are: I love Scheme and <str1ngs>peanutbutterandc: did the hack work? <periappi>thinking of using it to configure the OS is much more appealing for me than Nix's language ; then there is the non-free "issue": I feel like just having firefox installed isn't straight-forward. Help... ? ;) Cheers! <peanutbutterandc>str1ngs, I just tried with guix-installed timidity and indeed, it didn't work. I do not have timidity in my system yet. I use guix as my primary package manager these days. I will try installing timidity now <str1ngs>peanutbutterandc: I'm more concerned with the settings window working at this point. <peanutbutterandc>str1ngs, settings window didn't show a MIDI port option (with guix-installed timidity); apt is installing timidity right now. I guess you didn't catch my The Shining reference then. :D <link2xt>is it on purpose that builder can't access the network? is it to make builds reproducible? <str1ngs>peanutbutterandc: okay that's good thank you for checking. sorry it's been a while since I read the shining :( <str1ngs>peanutbutterandc: possible we can use ~/.asoundrc point to the plugin lib directory. that will be less hackish. but it would have to added manually . <erikg>link2xt: yes, that's the idea. it ensures the inputs are defined (although perhaps the system time or other things can modify the build result) <peanutbutterandc>str1ngs, I meant the stanley kubrick movie. It's all right. My reference was a littly corny anyways. :D [I don't know much about .asoundrc but I will try to look it up <link2xt>erikg: I am trying to build a Rust package which has github dependencies. I guess I have to package all the dependencies first <pkill9>kirisime: why not just copy paste the gnu build system to a new build system, then inherit the package and make it use the new build system? <erikg>link2xt: I have had a similar problem with c++ dependencies that are defined using ExternalProject in cmake <erikg>I moved to a submodule scheme to check them out, but for rust you might have to package everything <erikg>there's a cargo to guix package builder though, it might make it easy <link2xt>erikg: thanks, I think I will focus on supporting stable Rust and removing github dependencies then <str1ngs>peanutbutterandc: I need to look at guix system's /etc/asound.conf assuming alsa-service-type is part of %desktop-services. but I'm ruin guix on foreign to test this. <periappi>peanutbutterandc:Thank you ;) Another quick question: should I be expecting some strugle with hardware, DRM installation (eg. Netflix). Plus: will the system be "as stable" as my archlinux? (I have the same installation since several years) <str1ngs>peanutbutterandc: that may give a hit to what needs to be added to ~/.asoundrc <nckx>moewe: Sorry, later than expected, but a ‘guix pull’ will fix your Arc theme. <peanutbutterandc>periappi, Oh... wow... Netflix and all... I am sorry, sir. I myself don't really use guixSD as my operating system. I only use guix package manager on top of debian. And it's still so much fun. But I think yes: there will probably be hardware issues (wifi). For netflix, I am not sure. Perhaps you could declare your own netflix package in your own separate channel? <jonsger>periappi: I don't think Guix is as stable as Arch <periappi>peanutbutterandc:I guess so. I'm actually playing with guix on top of pacman, it's quite fun too. That's why I wanted to go deeper by moving to guixSD <moewe>nckx, thanks, I didn't even expect a fix (this early) :D <moewe>what was the fix? rolling back? <periappi>jonsger:When I mean "stable", I think of something quite steady - but not too much (I like it when there are some *minor* bugs here and there). <peanutbutterandc>periappi, I see. Perhaps you could first create a personal channel with package definitions for firefox and netflix and then go deeper? You could perhaps also use virtual machines to practice defining system, etc.? I wish you all the very bet in your journey. :) <jonsger>peanutbutterandc: somewhere on github is a guix channel with firefox and thunderbird. Guix brings Icecat a "fork" of firefox <periappi>peanutbutterandc:I will! I started qemu a few hours ago ;-)! Cheers! <kirisime>pkill9: I just thought I could test it directly in the guix source tree, since I can't I'll find another way to test this idea. The thing is that gnu-build-system patches .desktop files, but not the .thumbnailer variation. The change should probably be to the actual build system, but it's impractical to test like that for me. <nckx>moewe: A localised roll-back if you will. Building only arc-theme with current sassc@3.6 built with the older libsass@3.5. <nckx>I'm now rebuilding all dependents of libsass to make sure this leak doesn't happen elsewhere. <peanutbutterandc>periappi, That reminds me, I have to poke around with qemu and guix system someday. But for now, atleast, you have beaten me to it, sir. All the best! <peanutbutterandc>jonsger, but I'd like that channel URL, too, please, if you happen to stumble into it again <nckx>peanutbutterandc: Friendly request to not paste or recommend non-free stuff in any Guix channel. <nckx>jonsger's pointer-without-pointing was already on the edge 🙂 <jonsger>nckx: nah, I wouldn't call firefox or thunderbird non-free :P <Unix1337>Downloading Guix SD to try it the second time. I was playing with it a pair months ago, but then I leaved to test some bsd. I had a good time with Guix <nckx>jonsger: I completely agree. But the context (Netflix → Firefox) matters too. <jonsger>nckx: I'm not sure if this firefox in this channel includes DRM, I hope not... *nckx is a total freetard and clueless about that, was just following the conversation here. <peanutbutterandc>nckx, If someone asks about using a certain non-free service from guix, what would be the appropriate response? For instance, skype or netflix? <peanutbutterandc>Also, I wasn't trying to taint Mr. Wingo by pointing out his channel. I only had not realized that it was Mr. Wingo that first time. Just a clarification. Mr. Wingo is very cool, BTW. :) <nckx>peanutbutterandc: Just ‘sorry we can't support non-free software here’ (and don't include a big ‘…but see you <in channel X>!’ or otherwise try to cheat 😛). <nckx>If you know more about Skype or Nyetflix than I do, you could recommend alteratives, but I know they don't always exist. <nckx>peanutbutterandc: I'm certain that nobody thought you were. <peanutbutterandc>nckx, I see. Sorry, sir. It completely slipped my mind. I was just so glad to share about all the possibilites that guix has. I will try not to forget that. <lucky_guy>I am trying to install Guix on a single board Bananapi-M1 from an installed debian. <lucky_guy>/etc/config.scm:28:1: error: u-boot-allwinner-booloader: unbound variable <nckx>Unix1337: Happy to hear that! Happy hacking 🙂 <nckx>lucky_guy: ‘Booloader’ 👻 <kmicu>Hi periappi: I used both system for long time and my advice is that syntax is not important so don’t focus on that. Switching between Nix and Guix is not difficult because they work on the same principles so don’t worry about investing too much time time in one of them. If libre issues are not your focus then feel free to go with Nix and then join us later. <kmicu>(We can also use Nix on Guix System and Guix on NixOS system if we want to make transition even less problematic.) <kirisime>I've defined myself a function that I want to use as a builder phase. How do I actually pass it to the builder? <moewe>nckx arc-theme installed, thx <kirisime>(add-after 'phase 'other-phase ,function) doesn't seem to work. <nckx>moewe: /query <nick> <Optional first line <nckx>kirisime: How does your code differ from %openmpi-setup in (gnu packages mpi)? Make it not differ; profit. *nckx guesses: the quoting of the lambda. <kirisime>nckx: It differs by not being a lambda... <nckx>kirisime: That was… not what I was expecting. Your procedure was not a lambda? Intriguing. <mwette> kirisime: if function is from (define (function ...) ..) then try w/o the comma <kirisime>nckx: It's a named function in the same file as the package definition, I'd assumed that's the reason (arguments...) is backquoted so that you can unquote function names in phases and stuff. <nckx>mwette: That won't work. You can't pass native ‘host-side’ code to the ‘build-side’. You can pass quoted code and unquote it because MLP Scheme is magic. <nckx>kirisime: Yes, but the entire procedure needs to be quoted for that to work. <kirisime>nckx: Without the comma variable resolution fails. <nckx>kirisime: The comma (unquote) is correct. You NEED the quote. <nckx>'(lambda …) → <sweet sexp goodness>, not (lambda …) → <procedure> <kirisime>nckx: I know, it's code that's passed to the build daemon. <kirisime>It just doesn't seem to be able to pass a procedure in the place of a quoted lambda. <nckx>I'm sorry. I shouldn't have assumed that was ‘obvious’. <civodul>rekado: thanks for the updates to the build farm config! <kirisime>If you have a minute, take a look at patch-dot-desktop-files in guix build gnu-build-system. What I want to do is that same thing, except the files needing patching are in ./thumbnailers/ instead of ./applications/ and end in .thumbnailer instead of .desktop. <moewe>Is someone using GNOME with GDM here? If yes, did you update without problems? <kirisime>Given that the code is right there it seemed almost trivial to do myself... <leoprikler>can't say for sure, I'm sitting on two patchsets, one of which will not make it into current staging <moewe>I am unsure, "gnu/services.scm:826:27: In procedure struct_vtable: Wrong type argument in position 1" <moewe>Still trying to find out if my config is faulty <moewe>its like an entire wall of text <nckx>Ignore the comment. It works with keyboard-layout too. <moewe>so if I see correctly, you changed list to cons*? <nckx>moewe: (append (list a b c) %) to (cons* a b c %). How are those not equivalent [anymore]? <moewe>but it worked in the past :( <nckx>Ooh. moewe: Try adding a ) to (keyboard-layout keyboard-layout))) in services, and removing one after %desktop-services. <moewe>yeah, that was it! thanks leopriker and nckx I am still learning <nckx>If you're sure you didn't change anything, I can only say that your configuration was never correct. <nckx>And Guix just got less stupid since the last time you reconfigured. <moewe>maybe I am not that sure ^^^" <leoprikler>well, the small change was from (cons* to (append (list without proper closing 😉️ <leoprikler>tbh, I cringe whenever I see (append (list ...) other-list) <nckx>Welp, it wouldn't be a Sunday if I didn't have a headache from counting brackets. <leoprikler>but I cringe even more when I see scm_append(scm_list(item), list); <nckx>You take that filth elsewhere right now! <nckx>leoprikler: That is… real? <leoprikler>The codebase used to have this nugget sprinkled all over it. <moewe>leoprikler, what is so bad about that? new to scheme, python before so excuse my sloweness :P <leoprikler>It's mostly been replaced by scm_make_list, or scm_cons and scm_reverse now. <leoprikler>moewe: You're constructing a list in O(n^2) instead of O(n). <leoprikler>It was scm_append(list, scm_list(item)); of course. <leoprikler>The one I wrote just creates needless amounts of lists, but has no noticable performance impact beyond that. <leoprikler>(I can't even write inefficient code when I try to? What have I become?) <leoprikler>Okay, I checked the codebase again, and it's actually scm_append(scm_list_2(list, scm_list_1(item))); because that's how you actually get append to work in such manner. <leoprikler>There are still two instances of this anti-pattern and one genuine use of append due to unfortunate circumstances. <moewe>stupid question but.. can the other two instances not "simply" adopt the new/faster way of doing it? <leoprikler>there are 4 uses of scm_make_list and 3 of scm_reverse_x, so overall that's a win for alternative patterns (now) <leoprikler>oh, sure, but this kind of code tends to live on if no one's working on it <nckx>moewe: BTW, the next time you redact a configuration just whack your <Insert> key and replace each undesireable character with an ‘a’. Keep the dashes in UUIDs. This way they remain valid, as do things like Unix user names, and one can pass the redacted file straight to ‘guix system build’. <nckx>██▄ ██████████ ▄▄▄▄▄▄▄█ ▄▄▄ █▄ █▄██ is also not a valid UUID. <leoprikler>but it's funnier to look at and you can infer some bits about the actual UUID <moewe>generation generation worked :) thanks guys <NieDzejkob>nckx: "We didn't receive a proper request from your browser. Please contact us if the problem persists. " <NieDzejkob>nckx: I think your grep for go-build-system got quite a large amount of false positives because of cargo-build-system, grepping with -w returns 172 results, a number very similar to the 176 reported by `guix refresh --list-dependent go' <nckx>NieDzejkob: Thanks. Same here… And ha, stupid of me. <nckx>Still, you'll want to actually Scheme that s. <nckx>NieDzejkob: Nothing. I did try some stuff at the REPL because I have guix refresh trust issues but got the same results. Looks good for master. <periappi>kmicu: Hi, thank you for your advice ;) Maybe I'll give it a try finally! (sorry for the late reply) <leoprikler>bandali: I was thinking of gjs as the continuation of the mistake that is JS when I made that statement. <leoprikler>I don't care too strongly about people in corporate web development environments making their lives a living hell by inventing framework after framework in hope to make their lives more bearable while inevitably causing the opposite of that to happen. <bandali>leoprikler, haha totally fair then :p <leoprikler>I do care about people in the free software community making similar design decisions for no apparent reason. <leoprikler>There is for instance no reason to have Polari written in GJS. It doesn't even have extensions, the one thing one would use JS for (not that Scheme wouldn't be a better language for that goal, but I'm getting ahead of myself). Most of it could be written just as easily and bug-compatibly in C or Vala. <leoprikler>And yet I use it. For one, because it looks like, but more importantly, because I hate myself. <lfam>Building the new QEMU fails right at the end while building the docs :( <lfam>"qemu-doc.texi:41: @menu reference to nonexistent node `QEMU Guest Agent'" <nckx>leoprikler: Thanks for letting us fill in the blank ourselves. I didn't know Polari was JS. <leoprikler>That said, I do have to applaud the Polari team for pushing their app from barely usable (3.20) to fairly usable with only some very annyoing bug (3.32). <lfam>Are there any IRC clients without a few major annoyances? 😬 <leoprikler>I think the best you can do when looking for an IRC client is trying to find one, that pleases you aesthetically. <lfam>I will probably never switch until IRC is done <lfam>I couldn't even handle the fonts being hinted differently when switching from Debian's package to the one from Guix <lfam>Yeah, and why do it if you don't have to?