<roptat>also, how about this for glibc-locales: we have a variable with the set of supported locales, use it to populate the outputs field of glibc-locales, generate every locale (a make target?), and pass the list to the builder so it can check we haven't forgotten any; fail if the list is incomplete or contains locales that were not generated
<roptat>that way, we make sure we won't forget any?
<iyzsong>dftxbs3e: I don't know, is 'ISC' fsf-free? it's GPL compibitable..
<dftxbs3e>iyzsong, I tend to think fsf-free means FSF has explicitly reviewed a license in full and approves it, non-copyleft is more at the discretion of the person who sets it
<iyzsong>dftxbs3e: okay, so even 'ISC' is fsf-free, this modified version is not. I'd use use 'non-copyleft' for it, thanks!
<awb99>I love guix concept. And I am starting to use it as foreign distro on my desktopp/laptops. And on my servers I figure out the way to go is via docker. I now have built 100 times a customer docker image with guix .. and it is really slow. Also the images are huge. So I think what would be needed are root docker Images that have guix that then can be modified via normal Dockerfiles. Or one could modify a dockerfile by
<awb99>executing some guix commands into the docker image. Would this be a good idea?
<dftxbs3e>awb99, I think in general GNU Guix would welcome some space-optimization of packages, this would reduce the size of the docker image. Also, keep in mind GNU Guix docker images contain a full system inside them, not just a single application like others. Bundles for single applications can be created using "guix pack". Probably docker image generation could be made working with "guix pack" as well.
<dftxbs3e>I don't think the GNU Guix community in general is that much interested in optimizing GNU Guix with Docker combination, but more so encourage people to use GNU Guix and get rid of Docker.
<dftxbs3e>awb99, it would be helpful to profile what is slow exactly
<dftxbs3e>When you use Docker layers the problem is that you lose provenance information that GNU Guix is providing
<awb99>My point is this: guix is amazing. Years ahead of anything else. But how can I make use of it? Laptops/desktops: difficult because of hardwar driver issues. Window managers are not as beauti customized as on other distros.
<awb99>This leave me with using it as a package manager on a desktop.
<awb99>Server usecase: Here we have bootstrapping issues.
<dftxbs3e>awb99, I think you can try, also to run services with that, maybe you can also achieve it not sure, shepherd just takes configuration so.. usually in the docker eco-system people make a shell script with environment variables, you could also do that. So the application's package definition contains a script that can be used as entrypoint for the docker image and that script reads environment variables for configuration.
<Humanoid>I'm very confused as to which "guix" I should run. In the manual it says to create a symbolic link /usr/local/bin/guix that points to /var/guix/profiles/per-user/root/current-guix/bin/guix. But then in another section of the manual, it says the regular use should run "guix pull" himself... but this won't update the guix from that link.
<dftxbs3e>Humanoid, hello! what are you trying to do? just install GNU Guix on your system or..?
<Humanoid>I already installed it. I just want to know which "guix" I should be running, because the manual is telling me 2 contradictory things.
<Humanoid>I installed it on top of another distribution by the way.
<jgart[m]><lfam "jgart: Absolutely! I agree with "> lfam: I misunderstood. Yes, I agree with you on that. And, hopefully locale warnings would be a thing of the past by the time the MVP would get launched ;)
<Humanoid>I already read that. That's where the other half of the contradiction comes from. They say the regular user needs to run "guix pull".
<dftxbs3e>Humanoid, If we look there, if PATH contains "~/.config/guix/current/bin" then it runs guix from there
<Humanoid>The first half of the contradiction is in section "2.1 Binary Installation", step 6, where it says to link /usr/local/bin/guix to /var/guix/profiles/per-user/root/current-guix/bin/guix, so this means the user should be running the guix from the root's profile.
<Humanoid>So another question I have is, whether or not this makes sense that a user is invoking his own version of guix, which communicates with a different version of guix-daemon. Since guix-daemon is always run by root. Should guix and guix-daemon, which communicate with each other come from the same version?
<dftxbs3e>Humanoid, guix-daemon is broadly compatible in general, so in practice it's not needed, only in some rare situations.
<Humanoid>I tried linking to the directory from gcroots, but it still doesn't find it. It only finds the profile after I used it in a --profile= argument for something. So it must be storing a list somewhere.
<efraim>16 hours to build guile-3.0.2 from checkout on powerpc32, with skipping the tests :/
***jetomit_ is now known as jetomit
<mbakke>dftxbs3e: I don't know anything about Electron, but happy to help :)
<dftxbs3e>mbakke, it basically pins certain versions of Chromium, v8 and node with a patchset on top (but it could also use ungoogled-chromium in theory, unfortunately Electron doesnt use Chromium stable release versions AFAICT). And then Electron is an npm package. I figure one has to do with the npm situation first.
<g_bor[m]>ouch. I was also looking at electron, but the npm stuff is a tough one.
<g_bor[m]>The problem is that you have so many deps that it is very hard to keep track of it the manual way, and the versioning in most packages does not give you too much leeway when designing automation.
<Schroedinger50PC>I am trying to build a package for the bootloader of my arm board. The source code can be built with gnu make, but ".config" is named as "boardname". Copying the repo and renaming the file makes it possible to build the bootloader but is not really practical. Is it possible to tell the gnu-build-system to use "boardname" instead?
<dftxbs3e>Schroedinger50PC, you mean the configure script is named "boardname"? Like you'd do "./boardname"?
<nckx>Schroedinger50PC: There's no direct #:configure-name flag, but you could (a) rename it in a (add-before 'configure ...) phase or (b) replace 'configure with your own phase that just does (lambda* (#:key (configure-flags '()) #:allow-other-keys) (apply invoke "./fooboard" configure-flags)).
<nckx>Hum... are my messages not coming through? I suggested both.
<nckx>Schroedinger50PC: I'm going to answer here if that's all right, doesn't seem worth a private chat. You wouldn't use a separate repository. Both changes affect only the Guix package definition.
<nckx>Guix throws away the build directory with your renamed script after installing the result.
<dftxbs3e>nckx, they are coming through, I was in the process of writing mine so I sent it anyway and for g_bor[m] I don't know maybe Matrix delays
<nckx>Okie, thanks! I'm having connexion issue's & it seemed fishy.
<nckx>Modern wi-fi networks are no match for the cutting-edge ‘rsync’ DDoS tool.
<PotentialUser-92>nckx: I can confirm that alacritty after your commit works without XWayland, it didn't before
<nckx>It's mbakke's work, I just updated it, but thank you very much for reporting that!
<nckx>It convinced me to give alacritty another try and it's currently my default terminal.
<nckx>The multi-gig memory leak seems to be fixed.
<PotentialUser-92>Well thank you and mbakke for the work! I tested it using sway and "xwayland disable" in the config, maybe it should be written down somewhere that when packaging Wayland applications they should be tested w/o XWayland to be sure they work.
<PotentialUser-92>I had looked into updating it before but it seemed to be an awful amount of work to update the crate dependencies.
<dftxbs3e>PotentialUser-92, "guix import crate -r alacritty" helps with that I believe
<nckx>PotentialUser-92: Also about the home page. I prefer a shorter home page that does one job (looking at ours, it seems to be: ‘why Guix?’, not how) but then there are the how-to videos slapped in the middle of that...
<nckx>The videos are cool, and we should be proud of them, but they feel out of place and invite ‘well, why not link to the manual/cookbook/... on the front page too’?
<dftxbs3e>The videos are really good, they should expand to how to actually contribute and send something with git-send-email maybe
<nckx>I don't use Geiser or any other IDE. Maybe that's Geiser's fault; dunno.
<dftxbs3e>It has C-c C-m C-x apparently to expand macros, seems to work pretty well
<nckx>The ‘All packages’ button is randomly placed.
<didi>Should GUIX_PROFILE be "$HOME/.guix-profile" or "$HOME/.config/guix/current/etc/profile"?
<jgart[m]>civodul: thank you! We'll be live streaming the tmate session for those that would prefer to just watch and/or chat in the mumble. For the first meetup we'll continue the efforts of working on bitmask-vpn client that I started working on with raghavgururajan. We'll be committing our work as a group. The final package will end up in either a guix channel and/or for upstream review.
<jgart[m]>ryanprior: made the nice questionnaire and kindly hosted it
<jgart[m]>bavier: Thanks! It's a nice group effort. donotshake is kindly donating the mumble server at mumble.libremiami.org that is running on a guix system vps. I'll publish the config for that mumble instance soon in a git repository.
<milkey>...disabling the "dlopen" feature across all dependencies, and enabling the "use_system_lib" feature
<awb99>Is it possible to create for a guix environment automatically a symlink /bin/bash that will link to bash? I have lots of scripts that use bash and not sh. In normal Linux distros normally there is /bin/dh and /bin/bash
<didi>If XDG_DATA_DIRS and XDG_CONFIG_DIRS are not set, guix will set it to only its paths. By doing this, GDM will not initiate a desktop session in Debian Stable because it can't find the necessary files.
<didi>Guix should check if XDG_*_DIRS are set, if they are not, it should set it to the default locations before adding its own values.
<didi>XDG_DATA_DIRS=/usr/local/share:/usr/share and XDG_CONFIG_DIRS=/etc/xdg
<didi>I see /etc/profile.d/guix.sh is doing it, but something is not right because I need to add it myself inside my ~/.profile.
<leoprikler>are you sure your chain of source call is set up correctly? try something along the lines of `bash -v --login` for debugging
<jgart[m]><FennecCode "So wait, I'm able to arbitrarily"> yup!
<FennecCode>Holy moly no way. I'd like to write an actual Guix packages for these in the future, but this will save me an incredible amount of time in terms of stopgap measures in the future. Thank you so much 🙂
<jgart[m]>There's also some misc configs in the wild that you can consult for examples of how to set it up
<nikita`>so since gnunet and gnurl are in guix, i know i wrote in my stepping down as maintainer for gnurl email that I'm searching someone to co-maintain it, but the actual case I'm planning towards to is passing on maintainership as I just dropped maintaining it fully. if anyone's interested, given the crowd around the time i was more active was leaning partially towards finding gnunet okayish, shoot me an email
<nikita`>as pkgsrc dev I'm going to tell our vulnerabilities DB maintainer to just watch it same as curl now with a couple of exceptions, as I'm removed from the process (it's our own curated CVEs + more)
<nikita`>idk, I mean it's no longer paid work, was only briefly, so I can only point out the very minimalistic steps to maintain the fork. I automated almost all the boring parts away + needs some manual checking
<jgart[m]>but I think Raghav tested nix on Guix System recently and said it worked
<nikita`>almost 5-6 years maintenance of it made me reach the point where the biggest annoyance to fix is an CI file. pretty cool
<jgart[m]>I'll send you an email once I look it over more closely
<nikita`>nckx: yeah I mostly work on pkgsrc and netbsd now for a long time already, but i'm also motivated to give changing professions a try as I'm still interested in CS but my first choice was history+gender studies which I never got into at uni for work reasons back then
<jgart[m]>nikita: unrelated, but were you at pkgsrcCon 2019 in Cambridge?
<nikita`>nice people, and the broader *bsd community in general.. received job offer pitches, 2 replacement laptops, just the kind of closeness with people you work with and rarely see but chat regularly,.. wow
<nikita`>current job is shit but it's a job. anything else and I would've been on the streets 3 times this year already by my counting
<jgart[m]>I've been meaning to catch up with Benny and Thomas Klausner. Alistair is quite the character. I really enjoyed his talks. He gave a few.
<awb99>The package r-rserve is broken. It should install Rserv binary. But it only installs docs. How to fix this?
<jgart[m]><nikita` "current job is shit but it's a j"> sorry to hear that! I hope you find the job/gig you're looking for
<nikita`>i call job search in this economic schroedinger's jobsearch. i had many almost successful interviews and some even twice because the company couldn't hire. it remains weird. I'm rather disillusioned about the search
<nckx>awb99: It also installs R libraries. Maybe that was all the last packager/updater cared about or tested. Or the package has indeed bitrotted. In either case, briefly: you can check out Guix from git if you haven't done so yet (there's a ‘Building from git’ section in the manual), edit gnu/packages/cran.scm, and submit a patch.
<nckx>And of course you can ask more specific questions here if you run into problems.
<nckx>You're sure there should be a stand-alone binary?
<awb99>Can I do a build from source just for this package?
<civodul>lfam: howdy! a large part comes from the Rust bootstrap though
<lfam>Yeah. We can keep it hidden for that purpose civodul
<civodul>but i see a few matches in web.scm, which are probably more worrisome
<lfam>Either that or find some free source for the 1.0.2 updates. Maybe RHEL has it
<nckx>awb99: The problem here is that the rserve build scripts want to install Rserve into R's /bin directory, not rserv's. The second problem is they ignore the error so Guix considers the build a success.
<nckx>Looking at src/Makevars.in, we should be able to set $(R_HOME) to the build output directory. Let's see...
<awb99>R-rserve is a very popular binary that serves as a socket connection to R
<Guest96>hello, is it possible to define a package that depends on some service? is there a way to setup a service in a environment or profile or manifest? probably I'm confused
<awb99>I am surprised that nobody is using it with guix.
<lfam>More housekeeping... we should start removing FTP sources in guix/download.scm
<awb99>The hpc people must be using it in some way.
<awb99>I will look perhaps someone has implemened this in a non official Channel
<nckx>awb99: Do you know actual R packaging? I'm currently just looking at random files guessing what they do ☺
<ss2>guix is so cool! It takes minutes to modify the declaration, then it works, and that will never change as well! This reassuring feeling to know that every reboot will present me with the same machine.
<milkey>saves space in backups too. I no longer worry about backing up /usr/bin or /bin since I know they can be regenerated
<ss2>I've spent years with other systems pushing the uptime until it would eventually crash anyway and I'd always reboot to a different state.
<ss2>I know. The countless hours spent to try to keep a system at a state, which is now reduced to several kilobytes in just one file.
<Guest96>jgart[m] ok, maybe I got it: guix manifests allow you to define packages and it works everywhere guix works as a package manager, if you start defining also services, them will be avalable only to systems with shepherd. am I right? what's the best workaround?