<nckx>(Nitpick: ‘mkswap’ is similar to ‘mkfs’ also in the fact that it defines the size of the swap area, which can be smaller than the underlying device. ‘swapon’ didn't claim to show the size of the file. But why ‘mkswap’ created such a small header, I don't know.)
<nckx>I wish I could feign more amazement at the apparent fact that the official btrfs tool is worse at doing something than manually truncate+chattr+mkswap was…
<bjc>i'm mostly just mad at sun for concentrating so much quality work behind the cddl
<patched[m]>Could somebody here check if they have the same issue as I? If I do guix shell ant openjdk openjdk:jdk and then run ant, it complains about missing build.xml (expected), but if I add the --pure flag, it instead complains about missing java installation.
<nckx>If you add coreutils, the distracting errors (which should also be fixed but don't seem related) will go away.
<nckx>‘We have tried to execute java but failed.’ is probably a lie, since ‘java’ exists & runs fine…
<cel7t><civodul> "shouldn't we add a couple more?" <- As someone who'd like to participate, I wanna work on (1) adding a NixOS-like command-not-found script
<cel7t>(2) making parameterized packages (Guix equivalent of Gentoo USE flags) a thing
<nckx>ellysone[m]: Not integrated, it's just a package in Guix (I think it's in Haskell, even). We could recommend it… good idea. ‘licensecheck’ is just what I happen to know & use, I don't know if there are other similar tools? (I've tried ‘reuse’ once but it's not suitable for this—it assumes a very rigid SPDX format.)
<mirai>see the test suite for how I query the type with loginctl
<nckx>ellysone[m]: Cool! I'm not going to package that one (Go…) but a face-off would be interesting :)
<winter>jpoiret: if you './bootstrap && ./configure --localstatedir=/var && make && ./pre-inst-env guix system image ...', the resulting image will have broken substitutes, as the base service for ACL insertion hardcodes '/etc/guix' for sysconfdir. though I cannot find how the current Guix gets into the built image 🤔
<winter>build-self is only used in pull, and guix-service-type just uses (gnu packages package-management guix), which has all the proper flags set
<jpoiret>winter: are you talking about specifically the installer image?
<jpoiret>that one uses (current-guix) and not the standard guix package
<jpoiret>tldr: the guix installed in the installer image is built from guix pull, not the guix package
<winter>oh, that would do it, damnit. i was looking for something like that but guess i didn't grep hard enough
<mirai>jpoiret: ideally they would be system tests :)
<jpoiret>right! but even without tests, it's always nice to get the testing setup they have
<winter>but just running ./configure won't get you there
<winter>which is why I'm concerned that the result of the autoconf run from my checkout is somehow getting into the image
<winter>when it should be reconfigured when current-guix is built
<jpoiret>if you check inside the image, you can find the config.scm file that's generated by the build process
<jpoiret>it should be in /run/current-system/profile/share/guile/.../guix/config.scm
<jpoiret>both (current-guix) and the guix package should generate a new config.scm, since the former imports the current guix checkout using git-predicate, which only selects files that belong in the git index, and config.scm is excluded (only config.scm.in is checked out)
<guixfren>can I add my own scheme module paths to %load-path?
<Guest74>I installed Guix System with EXWM and eshell says ssh command not found. Basically every shell says bash: ssh command not found. How can I fix that
<ulfvonbe`>> Out of curiosity, do you have a need for ‘system’? I’m inclined to recommend against its use, in which case this patch is unnecessary.
<ulfvonbe`>I don't, and I tend to agree about not using it, but make-system-constructor and make-system-destructor both use it and are documented in the manual, so we should either make them work properly or remove them.
<gabber>Guest74: you need to install the package `openssh` to each profile where you need to use the `ssh` command
<Kabouik>Forgive the noob question, but if I want to occasionally use a pip package, I would `guix shell python3 && guix shell python-pip && pip install somepackage`, or should I use guix environment? Also, the package needs an internet connection, and I am not sure this is possible with guix containerization, is it?
<lechner>Kabouik / i know nothing about Python, but i would do guix shell python3 python-pip -- pip install ...
<lechner>that's one command instead of three. when guix shell exits, that's it. the profile is gone again
<gabber>i have tried `guix shell [--pure] python python-pip` but i've had some troubles with it (not sure what they were exactly but i remember that i wanted to do some more research with it)
<Kabouik>`guix shell python-pip -- pip install somepackage` seems to be the way, thanks.
<Kabouik>I haven't tried to apply the patch myself to be honest lispmacs[work]. It seems to be a pretty involved patch, and it remaining unfinished does not align well with my noobism with Guix.
<graywolf>Does anyone here use ibus-anthy? Couple of questions: 1. When you open the setting and click on the Japanese - Anthy method, is the "properties" button on the right clickable or not? 2. Does the icon for the input method properly load up?
<Kabouik>Hum, so I installed my pip package earlier in guix shell using `guix shell python-pip -- pip install somepippackage`, then I closed my terminal window and all, and yet the guix shell still exists (I can see that because the package is already installed if I redo the same). I thought guix shells were cleaned upon exiting/closing. Does that need a guix gc after all?
<Kabouik>I thought one of the goals of guix shell was to make one-off environments instead of cluttering the filesystem with things not installed by guix?
<graywolf>For that you might want to try guix shell --container
<Kabouik>Oh, but then I don't quite get the usage of guix shell, I'll need to read the manual again.
<graywolf>(I'm novice here as well so I might be wrong): I think guix shell is for using packages (from guix) without making mess in your profile. But (by default) it does not isolate the filesystem in any way, so if something tries to install into ~/ (which pip probably does), it *can*.
<Kabouik>I totally got it wrong that it was useful to use packages from other package distributions systems, without the --container option (which I hadn't used so far anyway). So `guix shell python-pip -- pip install somepackage` would only be useful to me if (1) I want to install somepackage with pip instead of waiting for its guix port or writing it myself, and (2) if I don't want to keep the pip installer on my system?
<graywolf>virtual environment, basically make the pip install into any directory you pick instead of the default location in ~
<Kabouik>And then it stays there, except if I used python -m venv /tmp/?
<graywolf>nah, the typical usage would be `python -m venv SOMEDIR' then `. SOMEDIR/bin/activate' and then you can just do pip install (and it will be installed into SOMEDIR instead of into ~). Then you can just rm -rf SOMEDIR.
<graywolf>venv is imho pretty useful, I recommend to read up on it
<Kabouik>I was under the impression that using anything else than guix was baaaad. Which I think it is, because it kind of breaks the workflow of a system being all managed by a powerful package manager like guix.
<graywolf>Depends. If you can avoid it, then yes, guix-only will likely be better. But sometimes you have to, since 1. not everything might be packaged (yet) 2. some projects might have strict version requirements that are not in guix (yet)
<graywolf>You can have reasonable middle ground when you use guix to manage non-python dependencies (gcc, various C libraries, ...), and pip install -r to manage the python ones. At least that is how I plan to do it at $dayjob once I get guix up and running on my laptop.
<Kabouik>Yeah, I was already breaking the ideal workflow since quite some time, but was not sure how to do it as properly as possible. I guess using pip is not as bad as I thought then (plus pip does allow easy upgrades and uninstall, so that's not too bad), especially if I use it inside a guix shell --container, or with venv (not sure which option to favour, but guix shell --container will be easier to remember).
<Kabouik>I have come some more serious conflicts when mixing R packages installed from R, guix packages for R, and rekado's guix.install() R command which allows importing those that are not yet available for Guix. Same with emacs packages already available in Guix, and those only in some channel doing the importation of others packages automatically. And I still haven't come up with a sane workflow for both of these situation, I keep postponing.
<mirai>it's horrible to search for any info regarding mcron
<civodul>mirai: i think nckx would know who to contact (might be Bruce Korb?)
<mirai>the question about mcron was whether it keeps state across reboots which you can see the searches returned garbage
<jpoiret>forgetting `-enable-kvm` when using qemu is quite costly 🙃
<mirai>civodul: thanks, I'll ask nckx when he's around
<graywolf>Why is there both en_US.utf8 and en_US.UTF-8 in /run/current-system/locale/2.33? 1. I assumed that UTF-8 would be normalized to utf8 2. It is the *only* locale in there that has both variants.
<mitchell>civodul: Yesterday you shared a link to a talk you gave in 2021 where you show cased a browser based application to view guix systems in. Where can I find that program?
<mirai>if the TODO file in mcron.git is to be trusted, then mcron does not have 'anacron capabilities'
<Kabouik>Interesting, I don't know what would be the pros and cons compared to r-guix-install. This is fairly similar to what I've been using for Emacs plugins though, and I still ended up with conflicts
<Guest74>Upon installing a package like mpv Guix updates its substitutes even from different channels. Can this be improved? Kinda annoying since it takes some time for updating one substitute server that it not even used anyways
<jpoiret>mirai: I'm reviewing your patch, everything looks good, but just FWIW (compose list (const x)) is just (const (list x)) 😄
<jpoiret>civodul: since you're around, wdyt of adding a recommendation for contributors to the system services to 1) add tests if possible 2) at least provide a simple configuration to test the changes with? that would probably avoid some duplicated effort on the reviewers part
<jpoiret>1 might be quite hard depending on the system, but 2 should be a minimum
<lechner>mirai / Hi, would it be possible to make guix-publish-service-type depend on 'mdns, which is in turn provided by avahi-service-type? Maybe then the configuration would at least fail without the latter
<jackhill>mirai_: lechner: what about if I don't want to advertise my guix-publish server via avahi? Will it be conditional? mdns isn't allowed on the network where my publish server runs. I mean, I could just block connections, but running something that nothing will connect to seems suboptimal to me.
<lechner>jackhill / mDNS advertisements are used by many devices like printers (and CUPS) for service discovery. i am not even sure people can turn all of them off, but if they are not allowed there is possibly a way to hardcode it
<lechner>civodul / i think their concern is, however, that they would still like to publish using fixed ips
<mirai>it can do more tricks if you look up the docs
<lechner>i think they want complicated dances without avahi
<jackhill>yesh, I think the way it is now, it configurable in the service, but if I understand what you're trying to do is that currently if one turns it on, they have to separately configure an avahi service, but now the publish service will always pull it in.
<nckx>mirai: …ouch. I think the person to ask about removing outright spam is Ian Kelling. But the list manager needs to change something about their moderation settings, or moderate by hand (like Guix does :-/ ) or it will just keep coming.
<jpoiret>Guest74: you totally can have both on your system, other distributions usually make pipewire-pulse and pulseaudio conflicts
<nckx>pulseaudio-service-type is what sets up the auto-start (it does not ‘start Pulse’ like some people think), so if your system doesn't have it I think you're good. I've not switched to Pipes yet though.
<bjc>fwiw, "extrinsic" is a perfectly cromulent word in my house. but then again, my partner is a university professor =)
<nckx>As usual, I see no evidence of you being mean.
<nckx>bjc: Mine isn't, and the word is (occasionally) used.
<lechner>my point about logic is actually somewhat well-founded (at least in my view). it leads to an over-emphasis of justice, which is the counterpoint of compassion. this can be seen in societies that cut people's hands off for committing a crime. i like compassion, and should have had more zimoun. sorry, zimoun
<juli>on running a system reconfigure, i'm getting the following error: "guix system: error: gnu/services/desktop.scm:1880:9: no value specified for service of type 'geoclue'". does anyone know what's going on here? should i open a bug report about this? i'm running gnome if that's relevant
<mitchell>where specifically do you want to overlay? the command line or the config? On the command line you can pass `--with-source=dwm=/local/repo` or from the config.scm you can use (package/inherit dwm (name "my-dwm") (source (origin ...)))
<nckx>ACTION thinks ‘guix system build’ is underappreciated.
<cel7t>This won't require me to write a dwm.scm, right?
<mitchell>Another option if you don't want to fork the entire project but only introduce a few additional files would be to add a phase after 'unpack where you can copy additional sources (which you sould specify in the native-inputs section)
<mitchell>no you can do it in the config.scm if you want
<mirai>I've just noticed that git send-email doesn't preserve the true commit date
<nckx>helaoban: Sadly, that's one of those perma-suggestions that can't seem to get enough people to agree on how *exactly* it would work and implement it. We all agree on the general shape, but everyone seems to project their own face on it.
<lechner>Hi, is there a place on IRC where i can get some help with a bricked Android device, and find out whether there is a remedy?
<nckx>cel7t: If you accidentally do, that's no big deal. What's really horrid is editing your message. Please don't. The bridge has regressed and now sends the entire message again. And again. And—for each edit.
<PotentialBear-75>Hi, so Im getting started with guix this week on my old macbook. Some ups and downs but so far have the wifi and such working so its technically working. My issue now is that I need to install certain applications not available thru the main channels. In particular Brave (the browser I like), Slack (talk to work team), and Sagemath (work). I was
<mitchell>PotentialBear-75: I am trying to get guix working on my 2015 macbook air but while the wifi driver probes correctly it won't connect to any networks. The macbook bootloader can connect so I know it is not a wifi bug. How did you get the wifi working on yours? Does it use a broadcom chip?
<PotentialBear-75>mitchell Yeah My is 2014 pro with broadcom. I used 5.15 lts kernel of unclean origins
<nckx>mirai: I mis-addressed you above. What I actually meant to ask: what was wrong (if anything) with the date?
<mitchell>PotentialBear-75: To answer your question I would make your own channel and copy the structure of that other place. You can add whatever package definitions you need there and guix pull like normal
<PotentialBear-75>@michaelll I rememebr now. I had to also modprobe blacklist usbmouse for some reason. I forget how I cam upon that solution
<nckx>mirai: Please don't compare your commit to mine, I lie.
<mitchell>Guix packages flatpak so if you can get these things that way then so be it. If you know how to build them from source but they can't be included in guix because of licensing or whatever then you can stuff them in your private channel. The other place defines a binary build system which may be useful to you
<nckx>Well, you're right. Date: in each *.patch is a unique snowflake. Date: on each mail is when git thinks it was sent. Fine, but *why do this only when sending .patches*? If anything, the other way 'round would be more logical, if equally frustrating…
<nckx>[‘when git thinks it was sent’ because I run git under faketime.]
<juli>i intended to setup virt-manager so i could do schoolwork, but it's not working and instead i'm bootstrapping a riscv64 environment... neat
<juli>(i suspect i need to do more configuration of libvirt but i kinda wanna mess around with riscv stuff now so...)
<nckx>mirai: I shot myself in the foot with that. git send-email does also replace the date, my two fakes just happened to match. I'm not going to file bugs against git, but it sure feels like a regression.
<cwebber>sneek: later tell civodul funny thing, I was supposed to ping you to ask whether or not "shepherd / guix daemon on goblins" was of interest (not a promise to commitment that we'll have resources to do it but checking if there's interest before we talk more about allocating time internally)
<nckx>lechner: Yeah. I still don't understand how clients are supposed to parse that if there's Unicode before that point, but it's a bit of a moot/philosophical point: all clients alive today will be using UTF-8 anyway. I suggest you do too.
<lechner>nckx / it's not my choice. the guile implementation of SXML does not (or maybe it's the built-in web client)
<nckx>It is very likely to choke on The Modurn Web.
<nckx>Have you reported this bug/difference of opinion in #guile?
<nckx>I think you'll get the response I hinted at above.
<lechner>actually, email@example.com hasn't responded at all
<nckx>‘Use a modern framework that assumes UTF-8, go away, it's a living standard or whatever, be liberal in what you accept’ meaning accept the status quo.
<dthompson>sneek: later tell civodul re: GSoC mentoring, I could probably co-mentor the guix system web interface as a personal-time thing. if any spritely+guix projects end up happening I could be part of that, too, but I'll leave that stuff to cwebber.
<lechner>mirai / Hi, are you connecting via hand-held antenna. i can send screws, if needed
<nckx>I feel kind of bad that my ‘this practice makes little logical sense if you think about it’ grumbling led you to ask webmasters, the most cranky of humans on this earth, to change their practices. That was not my intention.
<dthompson>because I tried to work with them *as an fsf employee* many years ago and it did not go well!
<lechner>they still write html by hand i think, so changing the tags is easy!
<nckx>You'll not convince them to, because this is a moot point. The whole world has settled on ‘assume text is UTF-8’. Guile is a straggler in that regard but you'll find no mercy out there. Stragglers will be shot.
<nckx>Me explaining why your code broke on their input was not meant to send you on a quest to fight windmills. Had I known, I would have told you not to :
<nckx>lfam: Yes, it's technically staging material, but I'm certainly OK with pushing CVE fixes to master.
<whereiseveryone>basically a way for newbs to guix deploy subcommand a mumble server without having to prepare write scheme code for a mumble service
<mirai>whereiseveryone: how does it get configured?
<lfam>We haven't formalized it yet, nckx, but on the second day of the Guix Days we reached a rough consensus among the people present to abandon the strictly numerical criteria for which branch to push to, in light of improved build farm capacity. Of course it leaves some architectures in the dust, but...
<lfam>It's been a while now, but my opinionated TLDR is that we restrict the core-updates branch to the actual core packages (defined in %core-packages), and then use feature branches to deploy changes with a relatively high compute cost. For example, a "mesa-updates" branch, a "python-update" branch. This is actually something we used to do in the early days of Guix, and then we stopped because of compute limitations that no longer exist
<nckx>That's basically my opinion, so if you represented it at the Guix Days I'm happy :)
<lfam>There was also an abortive discussion of the question "do we need releases?" but, as Andreas said, it was met with a near-total lack of understanding. So, that question is still open IMO
<lechner>nckx / what's the full command for guile, please? is that a static executable?
<nckx>lfam: That sounds like an opinionated interpretation of the room. What's there not to understand?
<lfam>The question was raised and then not really discussed at all, and we quickly changed the subject to branches.
<lechner>also, anyone know of a hypervisor for linux 3.10.108, so i can get a modern kernel going?
<lfam>The big point I made is that, since we have soooo many packages now, there are a large number of non-core packages that cause thousands of rebuilds. But, we shouldn't hold those updates until we also update GCC+glibc+etc
<lfam>Even if it uses more electricity and bandwidth to rebuild lots of packages more often
<lfam>The open question is unpopular platforms such as armhf. They will be even worse off
<vagrantc>i daresay the thing i like about releases, having just run the guix installer a few times ... is basically checkpointing how many commits you need to verify to get a fresh install, and it seems like the substitute availability was very high for a release (i think measures are put in place to avoid GCing packages at time of release?)
<nckx>Building armhf on aarch64 was fundamentally unreliable, right?
<nckx>That's how I remember it going, after too many attempts.
<nckx>vagrantc: I don't get the checkpointing bit.
<vagrantc>nckx: guix 1.4.0 has fewer commits to verify than 1.3.x when you guix pull
<vagrantc>try and fail, or nobody has the resources to try?
<lfam>Let me put it this way. Every piece of successful Guix infrastructure has a tireless person who makes it work. The reason we can build so well for Intel platforms is that somebody convinced their employer to give us >2000 cores in a datacenter
<vagrantc>i can help with the technical issues around how to do it, but definitely a bit sparse for extra time
<vagrantc>the biggest difference is guix is more prone to world-rebuilding or large rebuilding events that for the most part debian doesn't do ... so it needs even more compute (and thus indirectly, human) resources
<graywolf>Is there a command to find a package providing specific executable?
<vagrantc>at any rate, if anyone wants the magic runes to run virtualized 32-bit armhf systems with kvm support on top of a 64-bit aarch64/arm64 system, i can probably dig that up
<vagrantc>if i had more time, i would probably try to keep some core subset of guix working on armhf, but ... i do not.
<nckx>I'd hope that by then widdle armhf boards will seem as energy-irresponsible as big beige towers do today.
<vagrantc>bjc: i also have some apm mustang systems that were historically unobtanium ... that were cast-offs when someone retired a bunch ... i have a few spare boards i would happily be able to donate to guix formally
<bjc>i'm not formally guix, this is just a project that tickles my fancy. i wouldn't necessarily be able to commit to it