IRC channel logs

2025-09-24.log

back to list of logs

<Deltafire>the git bisect algorithm works fine with merge commits
<Deltafire>this maybe the reason they are discouraged in guix: https://lists.gnu.org/archive/html/guix-devel/2022-01/msg00307.html
<Deltafire>(merge conflicts being resolved incorrectly resulting in confusion later on)
<gabber>efraim: i am unable to get radio working on my pinebook pro. my config is inspired by yours. in `nmtui` radio is listed as "Hardware: Missing". it works fine when i boot the stock manjaro image. do i have to manually load some drivers after booting? do you have any idea what i might be missing?
<apteryx>klm`: it's sad, because outside of these nonfree blobs, the free drivers for AMD work great. I'm not wholly sure Intel will provide you with working graphics without blobs, but I'd expect basic 2D to work at least.
<apteryx>I used to run a 8800 GTS with nouveau, which worked without any nonfree firmware, but the driver had some bugs seen for example in Qt (ugly green artifacts in Jami for example).
<apteryx>so if you want functional 3D without any nonfree firmware, vintage hardware can be something to shop for. Using h-node.org can help find cards that will work.
<ieure>Never shoulda got rid of that Voodoo2
<apteryx>eh
<apteryx>I asked Matrox if their stuff still works without any nonfree firmware. Never got a reply.
<apteryx>conclusion: a free hardware shop that makes low performance but correctly working accelerators fully free may have a niche
<ieure>apteryx, Isn't that basically what the Mali GPUs common on ARM machines is?
<apteryx>ieure: not exactly; the drivers were reverse engineering efforts. not as good as a shop collaboratively helping create free firmware/drivers (https://en.wikipedia.org/wiki/Mali_(processor)#The_Lima,_Panfrost_and_Panthor_FOSS_drivers)
<apteryx>if the drivers work well without any firmware, it'd make it a good option though!
<Serentty>I was looking into packaging `uutils` today, but I found it difficult to figure out how to use `cargo-build-system`. I packaged something with CMake earlier and it was definitely easier to figure out. What are some good resources to learn about packaging Cargo projects?
<mange>Have you already read "(guix) Rust Crates" in the manual, and the June blog post about Rust packaging? https://guix.gnu.org/en/blog/2025/a-new-rust-packaging-model/
<mange>I don't actually know anything about building Rust/Cargo stuff, so I can't answer any specific questions, unfortunately.
<mange>Oh, there's also "(guix-cookbook) Packaging Rust Crates" in the cookbook.
<Serentty>I found the blog post kind of confusing and felt like I was missing prior knowledge. But maybe I should cycle between those and see if I can manage to bootstrap my understanding.
<mange>I think the basic thing with cargo is that Guix doesn't build libraries, they're just added as additional source dependencies. So there's a separate "registry" of cargo libraries that aren't real packages, and the rules are slightly different.
<Serentty>Okay, I think that is probably one of the things confusing me. I figured that Guix would either take the approach of packaging only the final compiled Rust binary, with all of its dependencies included, or having a real package for each dependency that the final binary depends on. You are saying it is actually something in between?
<mange>Guix used to do the latter, with libraries as packages and a separate #:cargo-inputs argument, but it was super confusing. Earlier this year things changes to your former approach, but rather than having libraries defined in each package definition there's a central "registry" of crates in gnu/packages/rust-crates.scm so each library is defined once.
<mange>Guix *is* packaging only the final compiled package, but for maintainability reasons the library definitions are done in a central place and referenced by the packages.
<awth13>Serentty: i recommend reading this section of the cookbook (info "(guix-cookbook) Packaging Rust Crates")
<Serentty>So, was the issue with the old approach that the dependencies could not actually be shared between other packages using them, even when compiled with the same version of the Rust compiler, because of different enabled feature flags, or something like that?
<Serentty>awth13: Okay, I will go over that.
<mange>I don't think cargo supports using pre-built dependencies, maybe? I don't know. But I do know the #:cargo-inputs approach didn't play nicely with other things like package rewriting.
<awth13>if I understand correctly, this is simply about the mapping between the design of cargo and its representation in guix
<awth13>in the rust world, nobody really builds or distributes /just/ the libraries and cargo is designed to facilitate compilation of leaf targets by pulling all dependencies and recursively compiling
<Serentty>Yeah, I know that is the normal way since there is not a stable ABI. Although I did wonder if dynamic linking with Rust might be easier to do on Guix because it can be sure that the library and the program were built with the same compiler version, by tracking dependencies meticulously. But just doing it the normal Rust way makes sense.
<awth13>incidentally, the rust way™ is how Eelco Dostra thinks it should be: "Note that no installation occurs; the source code is the installation." on page 8 of https://edolstra.github.io/pubs/iscsd-scm11-final.pdf
<Serentty>On another note, I was trying to package something using CMake, and it tries to pull in `iniparser` with this:
<Serentty>  find_package(iniparser REQUIRED CONFIG COMPONENTS shared)
<Serentty>But CMake can’t find it, even though I put it as an input to the package.
<Serentty>I am kind of stumped because it just asks me to set CMAKE_PREFIX_PATH or iniparser_DIR, but pointing those to the GNU store directory for `iniparser` does not really seem to do anything.
<Serentty>I got way further with this one than with the Rust one.
<Guest44>i set up my project to use guix for my node, python, and system (C stuff, etc) libraries and it works beautifully after forcing myself to learn a thing or two about shells.  never again will i have to go through 4 different steps to set up different package managers when i set up a fresh system.  thank you for making an awesome project
<kestrelwx>Morning.
<apteryx>ACTION takes a dive into the fediverse
<dlmsr>Hi Guix, I cannot unlock the lock screen when using the swaylock package from Guix but when using the swaylock package from Ubuntu it does work? I am obviously using Guix on a foreign distro. I figured it has something to do with PAM configs ... Has anyone experienced a similar problem?
<identity>dlmsr: if you were on guix system i would suggest (once again) to use ‘screen-locker-service’, but i guess not this time. i suspect the issue has the same cause: PAM configs, as you mention
<dlmsr>identity: ok, thanks. any ideas how to fix this? /etc/pam.d/swaylock is very simple, it just contains the line "auth include login"
<identity>we should really mention ‘screen-locker-service’ somewhere in the manual section for ‘home-sway-service’…
<identity>dlmsr: not familiar with PAM, really
<dlmsr>identity: yeah, me neither :D so probably I should do some research in that direction
<kestrelwx>identity: I also think that.
<jlicht>hey guix
<futurile>morning jlicht
<gabber>\o
<ttz>>Hi, I have created a module containing a definition of openssl-3.1.2. Now I would like to have a guix-channels.scm file allowing me to install it in addition to other things from upstream. To my understanding, the guix-channels.scm is of the form (list channel ...) as this is what guix describe -f guix-channels generates. How to declare the local definition in that file?
<ttz>I have tried using (channel (version 0) (directory "/my/path")) but I get the error extraneous field initializers (version directory)
<dlmsr>‘info "(guix)Specifying Additional Channels"’ says you just need to include the fields name and url in the channel record
<dlmsr>However, if you want to authenticate your commits, you also would need to include a channel introduction
<dlmsr>I think you're probably mixing up ~/.config/guix/channels.scm with .guix-channel where you declare your channel...
<csantosb>apteryx: regarding this thing, colognechip.com/downloads/gatemate-timings-latest.tar.gz, would it be enough to include a license file along with it ?
<civodul>another day, another Emacs crash :-/
<sneek>Welcome back civodul, you have 1 message!
<sneek>civodul, ArneBab says: to do some pressure testing of fibers, I created a tool I’ve wanted to write for a long time: distsort sorts files or arbitrary strings by editing distance and uses fibers to parallelize the work: https://hg.sr.ht/~arnebab/distsort/browse/distsort.w?rev=463e9a930cb4#L95 -- this only yields factor 2 speedup, I think due to garbage collector problems, but it’s the simplest use: fan out and recombine in a block.
<kestrelwx>civodul: On EXWM?
<janneke>ACTION hasn't had crashes, but has to reboot emacs quite often as magit grinds to a halt, some memory leakage?
<janneke>has enshittification reached gnu too?
<Rutherther>civodul: have you tried no grafts yet? I am planning on doing that to see it if can be related to grafts. But it is possible my crashes are different kind of crashes than your ones
<ttz>dlmsr: I may be mixing things up, Guix related concepts are still not clear for me. I tried the URL thing but I want to use a local file. So I tried using (url "file://./guix/guix-channel") in guix-channels.scm, where .guix/guix-channel contains (channel (version 0) (directory "/my/path")). This resulted in an error too (no such path or directory)
<ColdSideOfPillow>Isn't file:// only used to refer to absolute paths?
<civodul>kestrelwx: yes, EXWM
<dlmsr>ttz: Is .guix/guix-channel a directory or a file?
<dlmsr>ttz: info "(guix) Creating a Channel" has a detailed guide on how to setup your own channel
<futurile>ColdSideOfPillow: oh hey there, I was just looking at some of your PRs
<ColdSideOfPillow>futurile: hi! I saw them, was surprised to see sudden activity on my oldest (unmerged) PRs :D
<ColdSideOfPillow>I myself had forgotten about their existence haha
<futurile>ColdSideOfPillow: I've been trying to go through from the oldest to newest and find 'non-team' ones that had dropped through
<ColdSideOfPillow>btw is it possible to authorize commits in a channel using SSH?
<neox>ColdSideOfPillow, I think that's currently not possible
<ColdSideOfPillow>neox: aww, bummer. I try to avoid PGP whenever I can for reasons.
<janneke>casually checking a pr on the web https://codeberg.org/guix/guix/pulls/2630, I found that codeberg only sends certain messages as mails?
<janneke>oh wait, found it -- it was lorger ago, nevermind
<csantosb>Threshold for world rebuild is 350 ? I am unable to find this number in the doc.
<identity>csantosb: “Changes which affect more than 300 dependent packages should first be pushed to a topic branch other than ‘master’” (info "(guix) Managing Patches and Branches")
<ColdSideOfPillow>csantosb: Shouldn't it be 300?
<ColdSideOfPillow> https://guix.gnu.org/manual/devel/en/html_node/Managing-Patches-and-Branches.html
<csantosb>300, thank you !
<kestrelwx>That's so annoying, Mesa has been building for 50 minutes and then the 'llvmpipe/lp_test_format' test failed. I think last year when I was building Mesa 24.1.3 locally I had to disable the test too.
<csantosb>sneek: later tell enge, pushing to world-rebuild is still valid ?
<sneek>Okay.
<csantosb>sneek: later tell andreas-e, pushing to world-rebuild is still valid ?
<sneek>Okay.
<trev>it's funny to see all the tags on that PR
<kestrelwx>'lm-sensors' concerns everyone.
<jlicht>would the release-team for the upcoming release still need members?
<gabber>jlicht: i guess more is more (though i am not on the team)
<ttz>dlmsr: yes but the guide only details how to do via a remote Git repository. I would like to use a local channel definition.
<gabber>ttz: i am not sure you can mix and match local definitions and channel descriptions. if you "only" want to make your local modules available you can use the `-L' flag
<yelninei>ttz: There is also GUIX_PACKAGE_PATH. For openssl there was an attempt to update to 3.4/3.5 but it got reverted because it caused problems with python
<ColdSideOfPillow>ttz: If I understood your request correctly, doesn't info '(guix-cookbook)Channels' tell what you're asking?
<ttz>I will try the -L flag, thanks
<ttz>Maybe the manual explains it, but I couldn't understand it...
<ColdSideOfPillow>ttz: The -L flag adds your project to the load path
<ColdSideOfPillow>You'll nees to manually specify it if you have not added your repository as a Guix channel
<ColdSideOfPillow>s/nees/need
<gabber>ttz: i remember having similar issues when first attempting this path. please let us know how we could clarify the manual. maybe there is an easier attempt at what you are doing without channels? what is it exactly, that you are trying to do? if you "just" want to update openssl for your local system then defining and using channels could be overkill and the loadpath (-L) flag is more than enough
<gabber>if you consider packaging the updated version on a private channel (and have a broader use than just trying to build and use the package on you local machine) then channels might be right.
<gabber>if you succeed, we would gladly push your patches though, since updating packages is core business here (:
<csantosb>sneek: later tell apteryx, regarding this thing, colognechip.com/downloads/gatemate-timings-latest.tar.gz, would it be enough to include a license file along with it ?
<sneek>Got it.
<ttz>well to give more context, my objectif is to generate a reproducible environment inside which to build a Rust crate. Since this crate needs nightly for now, the environment should allow installing rustup. One of the dependencies of this crate is OpenSSL, but it requires a FIPS build, which is not packaged by guix. I could write a module in which I define openssl-3.1.2 compiled with the enable-fips flag, and without the perl-removing
<ttz>patch, not to temper with the sources. What I wouldl like now is a way to describe an environment using this module: I already can run `guix shell -f my-openssl.scm -NCF additional-dependency ...` successfully and build my crate in the generated environment. Now I need to pin all versions, so I used `guix describe -f guix-channel > guix-channels.scm` to pin the additional dependency versions. I simply want to add another channel in the
<ttz>same file allowing to use my openssl-3.1.2 definition.
<ttz>s/I could write/I already wrote/
<ieure>ttz, Why does it need FIPS OpenSSL? Do your requirements for this project share that requirement with that crate?
<ieure>ttz, Basically, do you need FIPS OpenSSL because you explicitly need it, or do you need it because some random crate needs it/
<ttz>No I explicitly need it for compliance.
<gabber>ttz: great to see you making progress! what other channel do you need in that channels file (if i may ask)?
<gabber>adding another channel to a channels.scm file should be straigh forward how it is described in our manual
<ttz>so yes, the manual describes how to define another channel with (url ...) but I was trying (for the sake of curiosity rather than need) to define a channel with my openssl module without needing to serve it from a remote.
<gabber>ttz: you can do that, of course
<ttz>The channels file should have some guix channel for the additional dependencies + some channel for the custom built OpenSSL.
<gabber>for that you need to create a IIRC publicly available git repository featuring the modules that contain your openssl package
<Rutherther>ttz: if you want to obtain channel from a local file, just use the file:// scheme for the url
<gabber>a custom channel can depend on other channels, yes. or do you mean contain a manifest with the additional dependencies?
<ttz>that's what is explained in the manual, but what about serving it from the file system?
<ttz>Rutherther: I couldn't get the syntax write, maybe: I got an error (not a file or repository or something like that)
<Rutherther>show what you had then
<ttz>gabber: there you lost me, these concept are not yet clear in my mind
<gabber>ttz: WDYM with "guix channel for the additional dependencies"?
<Rutherther>and yes, the channel needs to be a repository. So if you just had a folder without git repo in it, it won't work. Guix doesn't support that. You would need to git init inside & commit / if you already have this inside of git repo, point to that repo and make .guix-channel accordingly pointing to the folder with the modules
<ttz>mmh that would explain it then, I will try that
<ttz>(since you asked for it, there is what I have for now, but I think your answer satisfies me: https://paste.debian.net/1397959/)
<Rutherther>no, that's a different error. file:// doesn't support relative paths, you need to provide an absolute path
<Rutherther>so it would be something like "(url (string-append "file://" (getcwd) "/.guix/guix-channel"))"
<Rutherther>that would be equivalent to what you wanted to do. But if you instead wanted to make it irrelevant of where you are cd'd, it would be something like "(url (string-append "file://" (dirname (current-filename)) "/.guix/guix-channel"))"
<ttz>Is there a way to force guix to refresh its git cache? I tried pulling from the channel before pushing the branch and now it that it is pushed, guix still cannot find it
<Rutherther>what guix commit are you on? (output of "guix describe")
<ttz>Guix commit d9e2ee3e99475cfa5caa7c9ee7f2f54e3f71215f
<Rutherther>then you're affected by this bug https://lists.gnu.org/archive/html/guix-devel/2025-09/msg00148.html that prevents guix from fetching channels
<gabber>ttz: a quick `guix time-machine --commit=96d87b4747c63bfce81f8b6ac8eba481f31ed44d -- pull` should get you going again
<civodul>Rutherther: oops, that was pretty bad! thanks for fixing it
<civodul>and apologies (i reviewed this)
<ttz>wow thanks for the quick diagnostic
<gabber>civodul: should we have just reverted your commit as soon as we noticed the erronous behaviour?
<Rutherther>civodul: no prob. I am just wondering how long after it happened we will see people confused their guix pull is not pulling, because I wouldn't be surprised if for some time they haven't realized it
<untrusem>is there some other other mirror for mailing list, it just don't load for me time to time
<ieure>untrusem, Nope. And it doesn't load because it's hosted on gnu.org, which is being pummeled by the "AI" harvester bots that are destroying the Internet.
<ieure>web.archive.org maybe? ugh
<untrusem>:<(
<gabber>do i assume correctly that in our build environment /dev/stdout and the like are unavailable?
<ieure>Genuinely not sure. Run `find /' in a build step?
<ieure>This might print everything in /gnu/store.
<Rutherther>I am pretty sure /dev/stdout is available. That's where the prints are going... those you see in the log
<ieure>Rutherther, Does glibc's printf() work by opening /dev/stdout?
<gabber>mailman has a test_opening_character_device that apparently tries to open /dev/stdout (Permission denied)
<Rutherther>ieure: I don't think so, it prints to an already opened device
<Rutherther>isn't stdout opened at start of process?
<trev>can someone review/merge this? https://codeberg.org/guix/guix/pulls/2909 ...CI build has succeeded, just doesn't show up. Want to put up another PR that depends on this one. Thanks
<gabber>trev: sorry, i am super concentrated on fixing mailman right now
<gabber>i can look into it later, but please don't let this hold you back from crafting new PRs (:
<gabber>just open the PR and reference this one
<trev>gabber: ok thanks, will do!
<untrusem>I was affected by this bug, https://lists.gnu.org/archive/html/guix-devel/2025-09/msg00148.html, I ran the fix `guix time-machine --commit=96d87b4747c63bfce81f8b6ac8eba481f31ed44d -- pull` and after that I ran the `guix pull -C <my-channels.scm>` but guix is throwing error
<untrusem>guix pull: error: aborting update of channel 'guix' to commit 5053a59a0b6284ef8269f90457c560ee294ae9ad, which is not a descendant of f3c7c225d4ca39eeeae5f469f9f9d4f7243da4c3
<FuncProgLinux>o/
<untrusem>aint f3c7 is the latest commit, why guix trying to dowgrade?
<Rutherther>untrusem: what do you have in <my-channels.scm>?
<untrusem> https://codeberg.org/untrusem/verito/src/branch/trunk/etc/channels.scm
<FuncProgLinux>Would #2939 be a good place to propose a medium-heavy refresh on MATE due to an upstream known bug?
<FuncProgLinux>I think our friends at MATE are having trouble with their Travis CI service and newer releases are *not* being published to the FTP mirror :/
<Rutherther>untrusem: I have trouble believing that is actually the file. I see no reason guix would be pulling to a 2 week old commit other than that you have (commit specified in the file
<untrusem>ohh you are right
<untrusem>I had some local changes
<FuncProgLinux>(This issue is documented at https://github.com/mate-desktop/mate-panel/issues/1467)
<FuncProgLinux>(Also https://github.com/mate-desktop/mate-panel/issues/1513)
<untrusem>anyone use doas instead of sudo in guix?
<FuncProgLinux>They have that issue for a year now. So I think the releases published on the FTP site are not coming back anytime soon. I still don't know if we follow the "ask first" rule or the "just do it" rule xD
<gabber>untrusem: i am pretty sure, but i don't ;)
<gabber>trev: if your could assign me or ping me on the PR i'll get reminded by codeberg (:
<klm`>apteryx: interesting discussion on non-free blobs. I've been using the integrated GPU on my Intel i5-7400 for years without any hickups, with hardware accelerated 3d (still much, much faster than software rendering), and (presumably) without nonfree firmware blobs. I hope my newly purchased i9-13700K will work just as great.
<trev>gabber: done
<identity>wait, they are making ‘i9’s now? i would expect them to jump up to 11 (next prime after 7), but i guess they just hate even numbers for some reason
<ieure>identity, i9 has been around since the 7th gen Core CPUs, it replaced the "X" series (ex. X9000).
<clarkf>I'm struggling with home's bash service (I think). I don't think I've updated my home configuration scm file, but all of a sudden about a month ago, home stopped updating my $PATH (and $EMACSLOADPATH) :( Did something change?
<ieure>clarkf, Haven't noticed anything like that.
<clarkf>for whatever reason, `~/.guix-home/profile/etc/profile` is now empty
<Rutherther>do you have something in ~/.guix-home/profile/bin?
<Rutherther>also... empty as in completely empty, no comment?
<clarkf>~300 items
<clarkf>profile is empty as in completely empty
<Rutherther>then I would blame file corruption
<clarkf>I've rebuilt 4 times and it's continued to be empty
<Rutherther>try "guix gc --verify=contents" to check you have file corruptions, there will probably be more if that's it
<clarkf>oh, weird, yeah, there's corruption!
<Rutherther>you say you've rebuilt... did you change something in the profile / rebuilt with a newer guix?
<clarkf>i did not modify the config scm between rebuilds, but i `guix pull`ed between rebuilds, yeah
<clarkf>but, specifically, the profile was corrupt, so that's almost certainly the issue
<Rutherther>hm, still depends on what updated, if no packages from your profile updated you would be hitting the same profile, so still the same etc/profile file. You could check if the older generations "guix home list-generations" profile's are the same profile as your current one. If they are, all seems to check out. If they aren't, there is something strange going on if you've hit empty etc/profile for multiple profiles like that
<clarkf>I'm now seeing /multiple/ corrupt profile items in the store. it seems like this HD may be toast
<Rutherther>maybe... you can try running some tests
<clarkf>I just gc-verified, I'm going to rebuild now and see if that sorts things out
<clarkf>er, oh, `verify=contents` doesn't actually remove the corrupt items, i see
<Rutherther>nope, it only verifies the contents. To remove you would have to use "guix gc" (can also add arguments that just control the deletion itself, ie. --free-space or -D). You could use -D to control what paths to remove. But you still need to first remove gc roots pointing to those paths, ie. remove the old generations that point to those profiles
<clarkf>so the play is to roll back to a known-working-ish generation, delete all 'future' generations, and reconfigure (both home and system)?
<theotherone> Hello :) is gtk known to have flaky tests? Does a package with and without testing result in the same item in the store?
<ekaitz>theotherone: it shouldn't because it's a different package. right? I'm just guessing here but the arguments to the build are different.
<Rutherther>yes, the derivation is different, so the output as well. Guix cannot distinguish between changes that can/cannot lead to an actual change of the files in the output
<futurile>ANNOUNCEMENT: if anyone here is interested in donating regularly to Guix to support the projects recurring costs we're now on Open Collective. The money is held by Guix Foundation and it's all used to support the project. If you want to donate you can do so here: https://opencollective.com/guix/contribute/backers-93617 the other option is to join Guix Foundation and donate which is here:
<futurile> https://opencollective.com/guix/contribute/sponsors-93618
<Rutherther>what are practical implications of joining guix foundation?
<futurile> we'll be working on having a fundraising drive over the next few days and weeks so that we can ensure the project's sustainable!
<futurile>Rutherther: practically the Guix Foundation is a non-profit 'Association' (registered in France but open to all). As a member you can take part in the association's assemblies and discussions about it's activities. So it's member-driven.
<Rutherther>thanks
<bdju>Has anyone been working on yt-dlp in the last 24 hours or so? There was a new release and upgrading to it with --with-latest isn't working, but also there's an open issue saying it's going to require deno be installed soon, so the guix recipe will need updating I'm guessing.
<bdju> https://github.com/yt-dlp/yt-dlp/issues/14404
<ieure>bdju, That's unfortunate. I have no idea what the bootstrapping story for Deno is, but I'm gonna guess "not trivial."
<bdju>I didn't even think about that, yikes.
<ieure>bdju, I've picked up several of the yt-dlp updates this year, but they've all been trivial.
<ieure>Looks like it's mostly Rust, so might be a pain, but hopefully a tractable bootstrap.
<bdju>There's also some discussion in that issue about whether quickjs could also work, and looks like that's already packaged.
<simendsjo>futurile: Thanks for the links, I've been waiting for an easy way to contribute directly. I guess you'll post something on Mastodon I can boost later?
<futurile>simendsjo: yes, I'm working on making sure everything is correct. Then tomorrow doing some Stripe work. Then I guess after that I will add to the Guix web site. Then on the weekend? writing blog posts, emailing channels and posting on Mastodon.
<futurile>simendsjo: I wanted to get some contributions through it - so kinda doing things a 'soft launch' to make sure it's all correct
<simendsjo>futurile: Great. I'll wait for your post on Mastodon and boost that rather than post anything myself then. I'm also eagerly waiting for some official swag as I don't know who runs UM4NO (https://um4no.creator-spring.com/)
<futurile>simendsjo: yeah great!
<futurile>simendsjo: that's actually run by Luis Felipe who designed the logo, did all the graphics for Guix.
<futurile>simendsjo: so it's legit - I haven't actually bought anything through it
<futurile>simendsjo: I do want to add some merch for us, I did a bit of research, but that's going to be a future project
<simendsjo>futurile: Good to know, I couldn't find it on the site anywhere. Guess I'll have to get myself at least a mug to do some promotion in meetings.
<futurile>I really like the camo hat, it's cool - and I'm not really a 'camo' kind of person
<simendsjo>A shepherd notebook is also a quite fitting product.