<noobly>will a firefox binary run on guix w/o issue?
<morrigan__>nckx: I was thinking from earlier.. wouldn't it be possible to force a check of any source signatures (if present) in order for them to be committed to the Guix tree? Then there wouldn't be much need for install-time checking.
<nckx>morrigan__: So we currently ‘expect’ contributors to check any signatures as part of their due diligence. However, I don't know how to ‘force’ that currently.
<nckx>noobly: On Guix System? It won't even start. Foreign binaries need to be patched using the ‘patchelf’ tool or you need to extend your system configuration to include all dependencies in the expected (FHS) places, and I don't know if that's possible.
<morrigan__>nckx: I would imagine it being hooked into the git merge; the "enforcement" here would be informal rather than part of Guix itself. If a package has a (source (signature ... )) field, it will be tested before the merge is accepted.
<morrigan__>Maybe "source" isn't necessarily the best way to handle it
<morrigan__>And Guix could have something like `guix challenge` for source sigs?
<morrigan__>Again though it doesn't make it a lot of sense to expend energy on it right now since source signing is so rare
<morrigan__>roptat: Odd.. vim failed to build in this update. I will look into that a little more.
<nckx>Is there a better way to ignore exceptions than (false-if-exception blah) #t?
*raghavgururajan managed to make desktop-like system without %desktop-services \o/
<nckx>I chose to revert it because I just got the same test failure on tmpfs. With disable-CoW, --rounds=50 on btrfs passes, but it's obviously not the right fix. Seems like ‘fast file systems’ in general might be the problem.
<nckx>I see that includes all services you asked about (accountsservice-service, polkit-service-type, elogind-service and dbus-service) but I can't say why they're there. I wrote this years ago (and obviously haven't cleaned up since…) But it's easy to test and roll back.
<nckx>Sorry about that. It's not like there's a BIG ‘LIST’ COLUMN in my mail client that was clearly empty 😒
<guix-vits>raghavgururajan: i was thought you need an syntax example; i'm sorry, me hadn't tested this with the many GUI tools yet.
<nckx>morrigan__: Yeah, it… does that :-/ I should point out that I've never managed to build vim 8.2.0303 at all (I tried a few times to update it & fix the tests). The patch-CoW hack let me build it on btrfs, but there's obviously more going on.
<morrigan__>The main reason I use vim is because it's fast, it has all the features I need in a text editor, and it'll run on a potato
<nckx>I used vim for years until I saw the light 🙂 I'd just rather not deal with its finicky test suite every half year. But alas, I have reasons to have to.
<nckx>I can't say I enjoy using it now but it's a fine editor.
<morrigan__>What I mean is, it doesn't bother me terribly if I'm using a deprecated version
<morrigan__>I use it cause it works. If it still works, that's all I need.
<nckx>That's the great thing about Guix: as long as you need it, your ‘old’ (certainly not deprecated) vim won't be broken by the next libfoo update.
<nckx>Re: potatoes: SSH'ing into some random routers and being able to fire up ‘vi’ is a super power, and why everyone should at least try learning it.
<morrigan__>nckx: Yeah I'm nooooooot good with vi. The basics have it close enough to vim that I can kinda hobble my way around it but not to any great effect, most of the time.
<morrigan__>My original use-case for learning vim was I was working with some very resource-limited SBCs over SSH. I had root and networking, needed a less frustrating editor than nano. Vim did the trick and I've used it ever since.
<morrigan__>And a graphical text editor seems without benefit
<morrigan__>I could just as easily have sprung for EMACS except it was a little heavier than I trusted for the little computer
<morrigan__>nckx: If I go on the Github, it says that some of the tests are failing for the current release, which... now that I look at their Github I am utterly baffled by their versioning process. There's. One branch.
<morrigan__>Sorry did I say week? I meant several times a day
<guix-vits>morrigan__: They have an AppImage, in another hand...
<nckx>…which is compiled from the exact same code with the broken tests. I'd strongly advise creating a custom (inherit vim) (arguments `(#:tests? #f)) package and using that, over downloading random binaries from the net.
<morrigan__>I'm just a little astounded at this process. In some ways they're ticking all the right boxes; they have tests for every release, the repo is tidy, etc.
<nckx>morrigan__: For tiny environments I have control over I prefer mg or zile (I forget which one is smaller) to keep my muscles happy. But ‘vi’ is standard is found in the strangest places.
<guix-vits>nckx, morrigan__ : version 8.2.0303 in vim.scm; latest release is 8.2.0314; worth a try?
<morrigan__>But they have one branch. Just one. To which they commit every day, often more than once. That is maddening.
<morrigan__>guix-vits: it's packaged by Levente Polyak. I dunno what their process is.
<nckx>guix-vits: The latest ‘releases’ (they ‘release’ each commit, taking ‘patch release’ seriously) do specifically address test failures, so I'll give it a go.
<morrigan__>guix-vits: I used to use Arch so I'm familiar with their packaging system, but I was never a maintainer. I just know they package practically everything (and more in the AUR), and their PKGBUILDs are pretty concise.
<raghavgururajan>Blackbeard In worse case scenario where menu-entry to boot parabola does not appear, press 'c' to enter grub command line. Do `ls` to get disks. Find the one that has parabola. Usually (abc0,msdos2). Then do 1) `set root=(abc0, msdos2)` 2) `configfile '/boot/grub/grub.cfg' `. This will invoke grub,cfg of parabola. :-)
<raghavgururajan>Blacbeard Btw, I found out what was causing error (Wrong type argument in position 1) in your original config. The `(needed-for-boot? #t))` should have 3 brackets at the end. So ` (needed-for-boot? #t)))`.
<Blackbeard>sneek: later tell raghavgururajan thanks :). I did all the changes but it is still not working :( I am sure now that it is related to menu-entries because if I comment that the file works and starts installing
<guix-vits>I hope the math books are more "computized" these days at school: I was barely able to read the "Newton's method (square roots)" at Wikipedia, but easily spended not less than hour with the example written in Scheme. There is a chances that i'll even going to understand it.
<nckx>apteryx: I think you're applying package-with-python2 twice. It's recursive over inputs, so you should be able to drop it from your (mis-name-d) python2-keyring.
<nckx>Ah no it's not mis-name-d, but it's a bit of a strange idiom.
<apteryx>nckx: Yeah I'm abusing a bit it seems, but it could be made more robust ;-)
<apteryx>I was lazy and not wanting to specify explicitly every python2 things, including the #:python key for the build system.
<sirgazil>Anyone using Nautilus in sway? When I double click on a file, I get a dialog saying there is no application installed to handle that type of file, but there are applications for that and they are already marked as default in Nautilus...
<nckx>I dunno. It could stop at already-python2'd nodes, but what's the authoritative way to test for that? #:python?
<nckx>sirgazil: (Guess) do you have the xdg-open command from xdg-utils available?
<apteryx>another weird thing I'm now facing, with this "cleaned up" definition of email@example.com https://paste.debian.net/1132139/: 'guix build -L some-channel-dir firstname.lastname@example.org' -> guix build: error: python2-keyring: package not found for version 1.6.
<apteryx>Is it not possible to define a package by inheriting from another, and simply change its version/hash, and have it discoverable?
*apteryx digs... seems the way inherit works is not as I'd expect it to. I have two python2-keyring packages at the same 8.7 version.
<leoprikler>You'll probably have to inherit from the python3 version
<apteryx>leoprikler: is there an issue inheriting from a inherited package (chain of inheritance)?
<apteryx>also, I don't understand what the python2-variant property is about, if anyone knows.
<apteryx>(define on the current, python-keyring package)
<sirgazil>No luck with xdg-utils. With or without it, mp3s are launched normaly, but images, PDFs, and other files are not :(
<bavier1>apteryx: the python3-to-python2 mapping is not always straightforward, so the property is referenced in package-with-python2 to find the appropriate package
*sirgazil will have to configure the configuration of the configuration system.
<apteryx>nckx: the source of my prior confusion stemmed from the newly introduced python2-variant property on the python-keyring package. This caused by package-with-python2 definition to use that instead of the one I was defining ;-)
<alextee[m]>^ would be great if someone could look at/merge these
<NieDzejkob>alextee[m]: Hmm, so the thing is that, for example, I usually try using the program as a smoketest. I don't know whether others do so too, but I imagine it might be a problem for niche packages
<NieDzejkob>On the other hand, it's kinda irrational, since the person who submitted it probably tested it.
<DamienCassou>I'm using `guix system vm ./file.scm` to create and start a virtual machine
<DamienCassou>I would like to add a drive to this VM so I can later have `/home` saved in this drive instead of the qcow2 image in `/gnu/store`. This way, I can experiment with the definition of the VM (the `file.scm`) and still keep my `/home` partition. Does it make sense?
<leoprikler>apteryx: depends on the context. In most places you want to use prefix or suffix to provide stuff that's needed to work, whereas the environment provides stuff that you actually want things to be used with
<DamienCassou>I'm learning both Guix and Qemu at the same time so please be patient :-)
<drakonis>its only available through hnix right now, the standard implementation doesnt support it
<kmicu>Yes, both projects lack proper types that’s why that’s not important for me. Guix provided additional values like focus on libre and enforced kind community, but I cannot direct my friends to it if Guix is GNU, Chief rules GNU and constantly makes an easily avoidable mess. There is no such mess in Nix land. I hoped GNU can improve but is looks like Chief is a BDFL.
<nckx>kmicu: So you steer people away from one of the projects (if not *the* project) most vocal about changing the exact issues you find problematic about GNU. Despite our commitment to freedom, which are not imposed by GNU in any way. Despite the harmful implications of Nix's ‘pragmatism’. That makes no sense to me. I'm sad to read it.
<kmicu>I don’t steer people away from GNU Guix but don’t steer them towards it anymore. I can fix technical libre issues in NixOS and deblob it. I cannot remove Chief or fork GNU for Guix. What do you expect from me? To tolerate RMS the chief of GNU for the next decade?
<kmicu>Should I pretend that Guix is GNU but not really GNU—exists in some strange twilight zone?
<alextee[m]>im curious, i see a lot of people blaming RMS but i don't see a reason. what exactly did he do that makes people say he is not fit to be the leader of GNU? it sounds very ungrateful. it reminds me of people that basically make a living off enforcing his work (sf conservancy) and then they threw oil into the fire when that eipstein mess happened
<alextee[m]>this is basically his project and his vision and we are all benefitting from it, it sounds right that he should be the leader, unless he changed ship or something, which is very doubtful because he is always true to free software
<alextee[m]>drakonis: what led people to sign that thing mentioned above that he shouldn't be the leader?
<drakonis>he has, in the past, repeatedly enforced his authority on projects
<leoprikler>Which is especially harmful if you go down chains of "equivalences" like Guix = GNU = RMS.
<alextee[m]>i think he should still be the leader for freedom-related things but i guess authority to steer the technical direction of projects should be left to the maintainers
<elais>I tend to not see GNU as a very hiearchical organization but rather as something closer to an art collective. There are many independent projects going on at GNU with some overlap and mindshare but it's not like there's much direction on the part of GNU outside of RMS and individual projects' stated goals.
<elais>That being said, I'm not a fan of RMS as a person, but I understand how important he is to creation and advocacy of the free software movement
<elais>but I haven't spoken here in months, hi guys I'm Elais and I love guix
<alextee[m]>i'm confident in him being the leader for technical decisions too though, look at how good and well behaving GNU programs are. and also, if i am not mistaken he created gcc and emacs and some of the other important tools so i am sure he has the most insight into what should be the best direction
<bavier1>but gcc has technical means of ensuring freedom during interoperation; e.g. gcc plugins must declare a variable to prove the plugin is free software. the same could be done for ast-interfacing