IRC channel logs


back to list of logs

<vagrantc>i always wondered why the locales weren't just one derivation per locale...
<leoprikler>well, that'd escalate quickly
<vagrantc>with arbitrary uncommon locales? or what?
<vagrantc>this implementatin nckx doesn't generate deriviations for each locale?
<vagrantc>nckx mentioned...
<leoprikler>I think it scales in the number of languages per machine.
<leoprikler>imagine building the same package 20 times with slight variations
<nckx>vagrantc: No, one store item with a versioned subdirectory for each locale.
<vagrantc>ah, got it
<lfam>Usually, the answer to "why wasn't it done like this" is just that it was easier and faster to do what was done, and time is the most valuable thing
<nckx>1 drv.
<vagrantc>couldn't you also do multiple outputs ... e.g. glibc-locale:en_US ?
<leoprikler>that list would be hard to maintain
<vagrantc>you couldn't ask glibc?
<nckx>Note that this is not about the ‘locales’ shipped with random packages in /share.
<vagrantc>ah, the outputs need to be known in advance...
*nckx → zzz, o/ all.
<vagrantc>i had always figured guix could be more flexible than say, debian, where it actually generates the locales at package installation/configuration time
<vagrantc>(un)fortunately, my skill with locales isn't very good as ... free software generally caters to my native locale
<lfam>As a US-ian, everything always just works for me
<vagrantc>oh, i was raised speaking C
<vagrantc>i think this is also the moment where i make my hopeless plea for C.UTF-8
<roptat>don't we have a facility (for guix system at least) to generate locales on demand?
<roptat>there's a locale-definitions field
<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?
***ece34 is now known as ece3
<lfam>Howdy dftxbs3e
<lispmacs[work]>do I have to be subscribed to guix-devel to post to it?
<lfam>The first time you send a message, it gets held back for human moderation, but it shouldn't take too long
<iyzsong>is 'license:fsf-free' correct for this modified "ISC Lincense"?
<dftxbs3e>iyzsong, I wouldnt say fsf-free, more like non-copyleft?
<dftxbs3e>lfam, I am good, what about you? :-D
<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.
<awb99>With docker images
<awb99>Any guix System could be operated via a kvm cluster.
<awb99>This works out of the box.
<awb99>Can be done in minutes.
<awb99>Guix pack: this is actually a nice idea. But it means that essentially I am reducing guix to a package manager again.
<awb99>So I could use guix pack as part of creating a docker image
<awb99>And then run docker images say with alpine linux executing a binary made with guix pack.
<dftxbs3e>awb99, you can even "FROM scratch" there
<dftxbs3e>You can use a builder container with a GNU Guix installation then copy/extract into a scratch where there will only be the "guix pack" outputs
<awb99>A scratch?
<awb99>You mean without is?
<dftxbs3e>awb99, "FROM scratch" the empty docker iamge
<dftxbs3e>image *
<awb99>Without os?
<dftxbs3e>awb99, yes, a "guix pack" is self-contained
<awb99>Oh fuck. So the docker guest image would not have any operating system at all?
<awb99>I never even imagined that this could be possible.
<dftxbs3e>awb99, actually it is already possible to create a "guix pack" in docker format directly, with "-f docker"
<awb99>But I guess it must be, because the host has it all.
<dftxbs3e>The host has the Linux kernel, so that's all that's needed
<awb99>This should do wonders to the docker image size
<awb99>And app startup time
<awb99>That Is an amazing approach for web apps
<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.
<Humanoid>s/regular use/regular user/
<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 ;)
<dftxbs3e>Humanoid, - try reading this, there's some information about how "guix pull" works exactly
<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>(and not their own)
<dftxbs3e>Humanoid, maybe there's a contradiction but each user runs their own after they first ran "guix pull" and set: export PATH="$HOME/.config/guix/current/bin:$PATH"
<Humanoid>So I should just delete that symbolic link from section 2.1?
<dftxbs3e>Humanoid, I believe it's purpose is for new users to create their own 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>Ok, thanks!
<Humanoid>Where is the profile list for each user kept? When running "guix package --list-profiles" it knows I created extra profiles, but I don't know where that information is stored.
<dftxbs3e>Humanoid, /var/guix/profiles/ maybe?
<Humanoid>No, because I can create profiles outside that directory, and "--list-profiles" can still find them.
<dftxbs3e>Humanoid, I don't know then, you will want to use strace or look at the code
<dftxbs3e>Humanoid, /var/guix/gcroots/profiles/ - could find this in strace
<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.
<Humanoid>I just can't find this list.
<dftxbs3e>Humanoid, I don't think it stores any list, check if your link fits the criteria in the code that looks it up in gc-roots
<dftxbs3e>Humanoid, gc-roots variable is defined here:
<Humanoid>Yeah, it does look like it's running some kind of algorithm starting from gcroots. Must be some small attribute that I'm missing, which gets changed when using it in a --profile command.
<dftxbs3e>mbakke, hello! I am looking at deriving an hypothetical electron package from ungoogled-chromium, what do you think about it?
<awb999>I am using terminator on my host system. I now installed python3 via guix. And so I have python3 2x on my machine.
<awb999>But now terminator crashes:
<awb999>I guess it is because environment variable PYTHONPATH hset by guix.
<dftxbs3e>awb999, I think you shouldnt try to start terminator from there
<awb999>I start terminator on my host system
<dftxbs3e>awb999, instead of using user profiles, use environments
<dftxbs3e>So you install nothing in your user profile
<dftxbs3e>And do everything in an environment
<dftxbs3e>Then after you started terminator, within it do: guix environment -m manifest.scm
<dftxbs3e>You can export the manifest for your current profile with: guix package --export-manifest
<dftxbs3e>This way it does not pollute your host environment
<dftxbs3e>I don't know exactly why you meet this issue but I propose that workaround
<dftxbs3e>There was an initiative recently to get rid of GNU Guix editing PYTHONPATH
<dftxbs3e>awb999, see:
<dftxbs3e>It will come in the next core-updates merge I believe
<awb999>good idea
<awb999>so to fix my issue, I would just create a new profile and switch to that profile
<dftxbs3e>Once you started terminator, yes
<dftxbs3e>So terminator is not affected by it's childs environment
<awb999>many thanks
<awb99>I cannot find a command to switch active Profile
<dftxbs3e>awb99, I didnt mean to switch to a profile, just activate an environment with a manifest
<dftxbs3e>do: guix package --export-manifest > manifest-123.scm
<dftxbs3e>then, delete everything in your profile (don't use the feature anymore)
<dftxbs3e>then, guix environment -m manifest-123.scm
<awb99>My default profile has all the packages installed
<dftxbs3e>awb99, "guix package --export-manifest" will create a Scheme code file with all the packages in them
<dftxbs3e>in it *
<awb99>I get that
<dftxbs3e>awb99, if you go: guix package -l
<dftxbs3e>you can find your very first generation of the profile (empty)
<dftxbs3e>then do: guix package -S <path>
<awb99>But I could also just create a new profile
<awb99>Which is empty
<awb99>Switch to that
<awb99>And then make the new profile the default profile
<dftxbs3e>I don't know how to do that, never used them, try around
<awb99>Deleting profile will delete the channels also?
<dftxbs3e>awb99, delete how?
<awb99>Delete all files in the this profile
<dftxbs3e>Never delete manually
<dftxbs3e>always use "guix" command
<dftxbs3e>I think if you do, guix package -d (WARNING: don't do it straight up, it will DELETE old generations)
<awb99>Still I have to create a empty profile
<awb99>Because by default the empty profile has to be active
<awb99>Otherwise the python path will get exported
<awb99>And In My current I already deleted a few old generations
<awb99>I will not be able to move to the 1st generation back.
<dftxbs3e>then delete packages manually
<awb99>Good idea
<awb99>That shouldn't work fast
<dftxbs3e>awb99, in the GNU Guix manual it says: All it takes to get rid of the profile is to remove this symlink
<dftxbs3e> and its siblings that point to specific generations:
<dftxbs3e>$ rm ~/code/my-profile ~/code/my-profile-*-link
<dftxbs3e>awb99, look at: - --profile part
<dftxbs3e>Apparently the way to delete profiles is with "rm"
<awb99>Uninstalling python in guix
<awb99>Did not under the python path export
<dftxbs3e>awb99, do you have things in your .bashrc or .bash_profile?
<awb99>But I now manually did 'export Pythonpath='
<dftxbs3e>try restarting your shell to update environment also
<awb99>And this allows me to start terminator in that shell
<awb99>I did
<awb99>Didn't fix the export
<awb99>I agree though that having multiple profiles Is stupid. Better use manifests
<awb99>The only thing where it is big stupid
<awb99>Is speed
<awb99>If si want to do 'guix gc'
<awb99>Then only profiles are protected
<dftxbs3e>awb99, but you can always re-create your environment
<awb99>But some of my packages are compiled from source as there are no substitutes
<awb99>So I want to keep them cached
<dftxbs3e>awb99, I think you can combine both, you can do: guix package -i hello -p test-profile
<dftxbs3e>awb99, then do, guix environment -p ./test-profile
<awb99>That would work
<awb99>Head Exploding now.
<awb99>Ha ha ha
<awb99>Good night
<dftxbs3e>Good night!
<awb99>Many thanks
<mothacehe>hey guix!
<dftxbs3e>mothacehe, hello! :-D
<dftxbs3e>mothacehe, by any chance, do you have the power to review a Commit Access application? (mine) :-D
<mothacehe>hey dftxbs3e, I think your application is currently being handled :)
<dftxbs3e>mothacehe, okay! Thanks!
<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.
<dftxbs3e>efraim, do you use emulation there?
<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.
<raghavgururajan>I just received a *CRITICAL BUG* alert from GnuPG, which seem to be related to
<dftxbs3e>raghavgururajan, what version do you have? It seems it says only 1.9.0 is affected since it was introduced there
<raghavgururajan>Oh guix is still at 1.8.5. Never mind!
<dftxbs3e>It seems the recent change for FTP causes some trouble: write(23, "EPSV\r\n", 6) then read indefinitely (when connecting to an IPv4 FTP)
<dftxbs3e>reproduction scenario: strace guix refresh libgcrypt
<dftxbs3e>iyzsong, ^
***iyzsong- is now known as iyzsong
<efraim>dftxbs3e: building natively
<nckx>Good morning, Guix.
<dftxbs3e>Good morning nckx!
<nckx>dftxbs3e: The only people who can are the maintainers (, I'm sorry it's taking a while.
<nckx>Hi :)
<dftxbs3e>nckx, Mathieu Othacehe is one that's why I asked them heh
<nckx>Right, I meant in concert. Everyone must approve, although it's a formality.
<dftxbs3e>nckx, oh okay
<dftxbs3e>Got it
<nckx>Ludo's still finishing up your criminal background check and Ricardo still needs to review the CIA report.
<nckx>(It's... long.)
<dftxbs3e>I see ...
<dftxbs3e>It's been only a few days, not long yet
<nckx>Up to our usual standards.
<nckx>I think you can apply the same ones too and send a reminder in a few days.
<dftxbs3e>nckx, what do you think about nss's .so being in /lib/nss/ ?
<dftxbs3e>should it be there?
<wingo>nckx: isn't there a pastry evaluation component too? like you have to send your creation to each of the maintainers, sort of thing
<dftxbs3e>I don't do GNU Guile programs in any meaningful way FYI
<nckx>That was scrapped after the great salmonella incident of 2019.
<nckx>dftxbs3e: I get your point, it's unexpected and does not seem to be common, but why do you ask? Trouble?
<dftxbs3e>nckx, yes trouble doing something not free
<dftxbs3e>how does GNU Guix packages use it in that subdirectory?
<nckx>I mean, /lib/<foo>/*.so isn't ‘wrong’ in itself.
<nckx>There are some manual hacks in Guix to point some packages to /lib/nss (but then there are manual hacks to point to regular /lib too).
<dftxbs3e>nckx, do you have an example of such hack? how to alter RPATH here?
<nckx>The most common fix is passing -Wl,-rpath=... to the linker (LDFLAGS).
<nckx>Often (dunno why) packages have trouble finding themselves, e.g., darktable.
<nckx>Setting LIBRARY_PATH is another. A bit dirtier but easier.
<nckx>LIBRARY_PATH=$(guix build nss)/lib/nss ./my-executable
<nckx>to test.
<dftxbs3e>nckx, I see, well I'll use wrap-program then
<nckx>I missed that this was about non-free software.
<leoprikler>patchelf is your friend
<nckx>Your buggy tedious friend.
<dftxbs3e>patchelf manually called I guess
<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?
<Schroedinger50PC>sorry it should have said "./configure" of course
<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>I think (a) is fine and simpler.
<dftxbs3e>Schroedinger50PC, I suggest you do something like: (arguments `(#:phases (modify-phases %standard-phases (add-after 'unpack 'rename-configure-script (lambda _ (rename-file "boardname" "configure") #t))))
<nckx>Schroedinger50PC: Why is that not practical?
<nckx>Oh, is this because the file isn't writable?
<g_bor[m]>You could also replace configure I guess...
<g_bor[m]>I mean the phase
<g_bor[m]>And simply call boardname from there.
<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
<PotentialUser-92>Cheers, I'll use that next time!
<nckx>PotentialUser-92: I admit to avoiding [updating] Rust packages for that reason. It's just not... fun.
<nckx>PotentialUser-92: aside: DISPLAY= alacritty works too without affecting the entire desktop.
<nckx>I'd like to disable Xwayland but need some time to find alternatives to feh &c.
<nckx>PotentialUser-92: I wonder where that could be written, where people would actually read it.
<PotentialUser-92>nckx: imv may replace some of your uses of feh, and is wayland native
<nckx>Noted, thanks!
<PotentialUser-92>Guix doesn't have a wiki does it? Maybe in the manual under "Packaging Guidelines - Wayland Applications"?
<PotentialUser-92>But it's still no guarantee that people read it.
<nckx>No, it doesn't.
<dftxbs3e>I would really welcome some packaging guidance on package families and common issues
<nckx>I think they'd be welcome in <>.
<nckx>Which is closer to a wiki than the manual.
<PotentialUser-92>I must admit I'd never heard about the cookbook
<nckx>I added a comment <> but that will only help people specifically updating alacritty.
<nckx>Not good! It's on with a spiffy logo; where else can we promote it PotentialUser-92?
<nckx>(I must admit I've never read it...)
<PotentialUser-92>Hmm I think whenever I've been on "Help" I saw the "Guix Manual" link and thought that's the one! and missed the other links :P
<nckx>I'd move videos down/right one or two notches but maybe I'm just old 😛
<nckx>Putting the goal-oriented cookbook next to the concept-oriented manual seems more logical to me.
<dftxbs3e>Added to
<dftxbs3e>I would need help adding more resources about learning Scheme
<dftxbs3e>Scheme on GNU Guile specifically
<dftxbs3e>I didnt read much myself because it has been too boring
<dftxbs3e>I feel like I learn more practicing and reading GNU Guix code as I go
<nckx>Sure, same.
<PotentialUser-92>I find I'm missing an easy lookup for syntax: e.g. <record> or =>. I end up opening the Guile manual all on one page and searching
<dftxbs3e>I would be much better if I had better IDE support for GNU Guile, like a true LSP that supports Scheme syntax-rules too
<dftxbs3e>geiser cannot go past syntax-rules
<PotentialUser-92>nckx: I agree with the videos, maybe it makes sense to add links to manual and cookbook on the homepage
<dftxbs3e>No syntax-rules support means no code assistance within GNU Guix packages, correct?
<nckx>What do you mean by ‘no syntax-rules’ support?
<PotentialUser-92>I find the distinction between the cookbook and manual a bit confusing, i.e. the cookbook is for tutorials but the manual includes the installation tutorial.
<nckx>Guix uses syntax-rules, even within packages.
<nckx>PotentialUser-92: Excellent point.
<dftxbs3e>nckx, I mean geiser
<nckx>Ah OK.
<dftxbs3e>autocomplete within GNU Guix packages
<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.
*nckx stops looking at the Web site.
<dftxbs3e>I crave for that little dropdown menu at cursor with all available names (and accurate context-aware ones)
<nckx>dftxbs3e: You could submit a video script if you're interested.
<nckx>dftxbs3e: Yeah, that's what I think of when I think IDE.
<dftxbs3e>I've got some of it with Emacs, geiser and company
<dftxbs3e>But far from complete
<dftxbs3e>nckx, script?
<nckx>dftxbs3e: The videos are generated from git sources (apart from the voice-over, which is done by a human -- Paul, IIRC) <> but I just meant script as in ‘film script’.
<nckx>What it should mention, how it should introduce topics, etc.
<dftxbs3e>nckx, ah that's cool!
<dftxbs3e>I would really love a thing that can highlight different escape levels in code, like by changing code background color
<nckx>That's such a basic Lisp thing it has to exist -- but no idea what it's called.
*nckx → away from the kay.
*raghavgururajan nckx back
<raghavgururajan>Oops! the TAB happened.
<raghavgururajan>OMG! Telegram debugging is giving me existential dread.
<raghavgururajan>sneek, later tell pineapples: I think I am onto something regarding telegram. webrtc::DspAudioFormat and Endian.
<sneek>Will do.
<dftxbs3e>raghavgururajan, :-S
<raghavgururajan>I am flabbergasted on how a "Tech Giant", Google, couldn't find a way to allow directly browsing files on their git platform.
*raghavgururajan hasn't slept ... goes to bed
<dftxbs3e>nckx, a bit like this: - but not really since that does scopes and not Scheme quoting/escaping levels.
<cage_>hi! when modifing standard phases i would like to include a phase from asdf-build system while using '(build-system gnu-build-system)' in package definition form
<sneek>Welcome back cage_, you have 1 message!
<sneek>cage_, raghavgururajan says: : Sorry I had to be away. Were you able to figure things out? If not, let me know, I'll try my best to help.
<cage_>sneek, hi! thank you for your message
<cage_>i am still struggling with packeging i think the problem is that i am trying to use both GNU autotools and asdf for building the common lisp executable
<cage_>raghavgururajan, thank you!
<cage_>ia me using '(build-system gnu-build-system)' and i would like to add the 'configure from asdf building system after the gnu 'configure
<dftxbs3e>nckx, ha!
<cage_>i tried with '(assoc-ref asdf-build:%standard-phases 'configure) but no luck :(
<dftxbs3e>cage_, look at adding asdf things with #:modules
<dftxbs3e>in arguments
<dftxbs3e>I'll go to sleep as well, bye
<cage_>dftxbs3e, thank you, sleep fast! :)
<cage_> #:modules ((guix build asdf-build-system)) ;=> no code for module (guix build asdf-build-system)
<narispo>sneek later tell marusich growing list of all failed powerpc64le-linux builds with failed logs etc.
<sneek>Got it.
<apteryx>hmm, on a Debian based machine, how to get the Guix specified environment variables put in a user's .bashrc file (at the top of it) to be honored when executing commands via ssh?
<apteryx>It used to be, IIRC, that putting the exports declaration on top (before the check for interactive shell in the .bashrc skeleton) would be enough
<jlicht>hello guix!
<leoprikler>just a heads up, I think the crates importer messes up indentation
<apteryx>it's not the only one
<apteryx>there's a general issue about that
<apteryx>basically we'd need to have our scheme writer parse the emacs file defining the format and honor it
<apteryx>it's not trivial
<apteryx>that emacs file is .dir-locals.el
<PotentialUser-92>do QT applications in Guix support Wayland? or better how does the QT plugin idea work with Guix?
<leoprikler>if you add qtwayland/kwayland to the packages' inputs, it should work
<PotentialUser-92>what is the policy with adding qtwayland to inputs? would adding qtwayland to Qt packages on master be accepted or is it intended that I recompile them myself
<leoprikler>same as all other changes, if it causes to many rebuilds to staging/c-u it goes
<leoprikler>s/to many/too many/
<PotentialUser-92>Thanks. I suppose that its another thing to add to the cookbook for wayland programs (as well as the DISPLAY= testing from earlier today).
<nckx>raghavgururajan: Bit late, but: they do let you browse, if you click on (e.g.) ‘master’ you get <> which has a directory listing below the fold.
<nckx>It's a terrible UI but that's normal for goog.
<kondor>Can an input to a package be a derivation?
<roptat>kondor, probably, but not sure
<kondor>... yes, it can
<kondor>according to the docs
<civodul>iyzsong: thanks for the FTP client fix!
<civodul>FTP remains kinda obscure to me
<GNUtoo>Hi, is there a chapter on how 'root' work in Guix (not GuixSD)? If I do guix package -i sudo, can I use it to become root? What about things like gnome-disk-utility?
<rekado>GNUtoo: outside of “Guix System” sudo will not work as expected.
<rekado>that’s because it needs to be setuid, and none of the files in the store are setuid root
<GNUtoo>so I need to setuid files as root and that's it I guess
<rekado>on Guix System we have a separate directory for setuid binaries
<GNUtoo>I saw "10.9 Setuid Programs", can I do that in the case of Guix (not Guix SD) ?
<GNUtoo>or do I need to manually do the setuid outside of Guix?
<GNUtoo>For instance for guix pack, what would be the best way to do it?
<GNUtoo>oh the tarball has root/root
<GNUtoo>so maybe it'll just work
<GNUtoo>I'll try
<civodul>GNUtoo: files in the store must not be modified, so you can't make them setuid in there
<GNUtoo>ok, so I guess it only works when guix isn't installed
<civodul>the only option (that's roughly what Guix System does) is to copy the "sudo" binary elsewhere and to make that copy setuid-root
<GNUtoo>like a guix pack being deployed
<civodul>if it's a "throwaway store" as in 'guix pack', you can fiddle with it i guess
<GNUtoo>Thanks a lot
<GNUtoo>I'll try gnome-disks (since it's root/root, the system sudo should at least have the right users)
*GNUtoo should probably try to formulate questions better next time
<jgart[m]>Hi guix! I just wanted to let everyone know that I'm hosting a guix packaging meetup next week over mumble/tmate:
<jgart[m]>I'll announce it also in guix-devel
<civodul>jgart[m]: nice!
<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
<bavier[m]>jgart: cool, nice idea!
<leoprikler>didi: GUIX_PROFILE is a metavariable and only bound for the expansion of "source $GUIX_PROFILE/etc/profile"
<leoprikler>it can be whatever you want it to be
<didi>leoprikler: I'm trying to follow the manual and deciding what should I put inside `~/.profile'.
<leoprikler>and particularly during login both of the above should be sourced (this happens automatically in Guix System, but not on foreign systems)
<didi>leoprikler: oic. So I should but both.
<jgart[m]>bavier: Thanks! It's a nice group effort. donotshake is kindly donating the mumble server at that is running on a guix system vps. I'll publish the config for that mumble instance soon in a git repository.
<didi>leoprikler: Thank you.
<jgart[m]>gettogether is a feature-competitive alternative to
<bavier[m]>jgart: I like Mobilizon too:
<jgart[m]>bavier: Ohh cool! I didn't know of that one.. :)
<jgart[m]>Ohh nice, it's an elixir app
<sneek>Welcome back pineapples, you have 1 message!
<sneek>pineapples, raghavgururajan says: I think I am onto something regarding telegram. webrtc::DspAudioFormat and Endian.
<pineapples>This is the news I have been hoping hearing today
<pineapples>raghavgururajan: Have you read my and mjw's yesterday conversation about the plausible cause of the crash?
<pineapples>You may find relevant information in it
<milkey>hello everyone, relative guix (and irc) noob here. I saw the conversation about alacritty in the log and thought you might want to know about a PR I made to smithay-client-toolkit recently:
<milkey>it solves the native-wayland alacritty thing in a less hacky way than the current package
<milkey>once this PR is merged every depedency of alacritty that depends on libxkbcommon will have an optional feature to link directly to it instead of trying to dlopen it at runtime
<milkey>then the only special patch to do to alacritty when building is disabling the "dlopen
<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
<leoprikler>yes, but only in a container
<milkey>a lot of packages have a patch-shebang phase specifically to fix that, could you just do that for your scripts
<leoprikler>environments otherwise share the filesystem
<awb999>bug report: inside gux environment --container tmux brings this error: tmux: need UTF-8 locale (LC_CTYPE) but have ANSI_X3.4-1968
<vagrantc>hrm. apparently i replied to an old long-closed bug. heh.
<awb99>Thanks @milkey
<awb99>A guide environment --container .. hpw is network shared with the host? How can I access a Webserver running in the container?
<milkey>you probably need to add --network to guix container
<milkey>at the very least
<awb99>I have --network
<awb99>But seems not to work
<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/ 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
<didi>There is no `--login' in my bash it seems.
<didi>There is, but it errors somehow.
<FennecCode>Hey, so I was wondering if there are any database frontends available in the default repos? Is there one people tend to like? 🙂
<FennecCode>Specifically I'm hoping for some kind of nice graphical frontend for MariaDB 🙂
<jgart[m]>FennecCode: are there any that you have looked at already that are not in guix upstream? If so, please share it here.
<FennecCode>I haven't found repos that have any for Guix, but I've found several that look nice that are Free software that are available on Flathub and Snap
<jgart[m]>Cool! What are the names of those?
<FennecCode>Sequeler, DBeaver, and Beekeeper Studio are all ones that seem really nice in their own ways
<FennecCode>There's also HeidiSQL, which I've looked into less, but also seems nice 🙂
<jgart[m]>FennecCode: sequeler is available from nix which we have a nix-service-type for
<FennecCode>So wait, I'm able to arbitrarily install Nix packages like I might install FlatPaks if I set up a nix service as part of my system services?
<jgart[m]>Maybe someone will write a guix package for sequeler in the near future
<jgart[m]>dbeaver is also available from nix
<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 an example of how to setup the nix-service-type in the manual:
<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)
<jgart[m]>FennecCode: here's one adding the relevant line:
<nikita`>s/going to/have told
<nikita`>unrelated issue, I'm going to leave gnunet, so the implication of "needs new maintainer" is that I don't plan to stick around much longer for it.
<nckx>Evening, Guix.
<nckx>nikita`: Oh. May you find happiness elsewhere.
<jgart[m]>Hi nikita` could we schedule a chat about it? I'm free after the 24th. I'd like to learn more about the project and your proposal.
<nckx>jgart[m]: Do you use Nix-on Guix?
<jgart[m]>I'm currently using Guix on Nix
<jgart[m]> * I'm currently using Guix on NixOS
<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
<nckx>jgart[m]: Great to hear.
<jgart[m]>I tried it once some months ago and I remember it having issues but I've heard it's been fixed since then
<nikita`>idk if I can schedule anything, async email works best with my work schedules and everything else going on in life for me right now
<jgart[m]>nikita`: ok, that's 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`>no, i was too broke back then to travel
<jgart[m]>I attended it, but I was living there at the time because my partner was attending University of Cambridge at the time.
<jgart[m]>Great group of people! I had such a blast
<nikita`>ah, cool
<nikita`>yeah i got to hang out with some of us at fosdem last year
<nckx>I hope it works out well for you, nikita`.
<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?
<awb99>I am 100% sure
<awb99>The binary is the sole purpose of the package
<nckx>There are library files as well.
<lfam>We'll be needing to remove openssl-1.0 soon
<lfam>A huge number of packages depend on it still
<jgart[m]>nikita: one of the many paradoxes of crapitalism
<lfam>`guix refresh -l -e '(@@ (gnu packages tls) openssl-1.0)'`
<nckx>awb99: I don't quite follow. Guix builds everything from source, using ‘instructions’ (package definitions) written in Scheme. In this case:
<nckx>No explicit build steps here, it just uses the defaults.
<nckx>What exactly do you want to do/happen?
<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/, 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 ☺
<awb99>Sorry. I am just a R user.
<awb99>What happens under the hood is that R uses gcc to build binaries
<awb99>The Debian and dnf and arch packages all have Rserv binary
<nckx>awb99: I hope not :-/ Everyone would lose if someone were maintaining their own r-rserve without contributing back.
<nckx>s/r-rserve/& package/
<nckx>awb99: I noticed.
<nckx>(Didn't check Arch, only Debian.)
<awb99>Possibly I can use R script to compile it from R
<awb99>I have to ask a friend for this if this si any help
<nckx>src/install.libs.R: ‘all files are optional in case the package is built without the server’ -- ah, maybe that's why it reports success.
<jgart[m]><Guest96 "hello, is it possible to define "> There's currently no way to setup a service-type in a guix environment. Someone correct me if I am wrong.
<lfam>We'll remove Qt 4 and OpenSSL 1.0 at the same time, I think
<lfam>I thought I had started a discussion about removing OpenSSL 1.0 but now I can't fin dit
<lfam>find it
<awb99># download source code# available versions: /tmp/rservcd /tmp/rservwget -xf Rserve_1.8-6.tar.gzcd Rservels # execute R To install it:export R_HOME=/usr/lib64/RR CMD INSTALL Rserve_1.8-6.tar.gz# test running it./usr/lib64/R/bin/Rserve # make symlinksudo ln -s /usr/lib64/R/bin/Rserve /bin/Rserv
<awb99>This is how I installed it in Fedora
<nckx>That's all gibberish to me but it looks like what I'm trying now:
<nckx>That didn't work, because ./configure doesn't honour R_HOME (I think...).
<nckx>Anyway, this is what the fix looks like, awb99:
<awb999>this is what would work if there are write permissions to /gnu/store
<nckx>awb999: With the updated package, running just ‘Rserve’ prints: Fatal error: R home directory is not defined
<nckx>Is that normal?
<nckx>Otherwise, more fixes/suggestions welcome ☺
*nckx → AFK.
<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
<milkey>it's a nice side benefit
<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?
<awb99>Export R_HOME= path
<awb99>I guess it has to be the path of r mínimal package
<nckx>awb99: I did that, but is it expected?
<nckx>(Gave me another error, by the way, but I closed the term. I'm out of my depth debugging R, sorry.)
<nckx>It was ‘cannot find system Renviron’.
<nckx>awb99: After pulling and trying to get the new Rserve to work, please file a bug report to bug-guix at with what still needs to be done. Thanks!
***atw` is now known as atw
***ChanServ sets mode: +b *!*
***jehelset was kicked by ChanServ (User is banned from this channel)
***ChanServ sets mode: -b *!*
***ChanServ sets mode: +b *!*
***jehelset was kicked by ChanServ (Banned: Please fix your client or bouncer and let us know.)