<roptat>morrigan__: you should be able to guix pull and build your package now <roptat>I've just pushed a fix to the node build system <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. <nckx>(I mean, it's possible to do that, but I don't know if all dependencies are in Guix.) <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. <morrigan__>Now I just have to... pull the entire dependency tree for these three packages lol <roptat>Weird, it shouldn't lepend on the node build system <roptat>Looks like it's Tobias' fault :p <nckx>We've known each other so briefly. <nckx>So the fix don't fix? Don't worry, I'll fix it! <roptat>The 'disable-CoW phase failed for me <roptat>Don't be sorry, you found a real bug :) <nckx>morrigan__: What does ‘stat -fc%T /tmp’ return? <nckx>I tested this on non-CoW file systems but obviously messed up. <morrigan__>The CoW functionality is provided at the "hardware" level (it's a qcow vhd) <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>morrigan__: Go pull and get your vim. *nckx right about now: uh oh which email <morrigan__>nckx: Thanks! It'll be a minute before this update finishes <nckx>raghavgururajan: I did not realise that wasn't a list mail. <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 😒 <raghavgururajan>nckx I still need some thinkering to make dbus work. Will get back to you. <raghavgururajan>nckx Guix Manual at guix.gnu.org seems to be outdated. For polkit and bluetooth are still shown as non-types. <nckx>raghavgururajan: Possible. My configuration's outdated too. I'll take a look at the manual. <nckx>raghavgururajan: The last line of my .xsession is: exec dbus-launch --exit-with-session ssh-agent i3 <nckx>Maybe you need dbus-launch? <raghavgururajan>nckx Would you be able to pastebin your complete services field please? <guix-vits>raghavgururajan: meantime example -- (services (append (list (elogind-service)) %base-services)) <raghavgururajan>guixvits Thanks. But I already tried (services (append (list (dbus-service) (elogind-service) (service polkit-service-type)) %base-services)). It did not work. <raghavgururajan>When I used thumar+thunar-volman, the volman could not connect to dbus when I plugged-in a USB drive. <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. <nckx>I use vim under protest so I'm not the most motivated person to fix this. <morrigan__>nckx: but fair enough. vim is my editor-of-choice so it's important to me that it works, but I have a working version from a previous update so I'm fine <nckx>morrigan__: If you're desperate you can always ‘until guix whatever vim; do :; done’ until it either succeeds or you give up. <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. <guix-vits>morrigan__: interesting, how Arch-ers do package Vim...? <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. <morrigan__>They make a good reference because someone figured out how to do it. <nckx>So judging by the log it would seem to be a manual process. <nckx>‘!pacman foo’ is a habit of mine. <morrigan__>But since Arch is a binary distribution, there's no guarantee that the pkgbuild won't fail on your hardware <morrigan__>There *is* a test in the pkgbuild for the Arch version of vim <nckx>I've never actually built one. <morrigan__>nckx: My experience was it's usually pretty reliable. I never ran into a situation where something wouldn't build/run <morrigan__>They also don't guarantee that an update won't brick your system <morrigan__>(Although that only happened when I was on Parabola) <guix-vits>morrigan__: Only if one do `pacman -Sy` instead of -Syu :) <morrigan__>Manually rolling back in the middle of a lecture was a fun experience *nckx bristles at the word ‘brick’, having brought *actually bricked systems* back from the dead. Like, I'm sorry your systemd prints a scary red boo-boo but your system is not ‘bricked’. <nckx>Not really ranting at you, just the sky. <morrigan__>The update *broke* my distro in that it wouldn't boot. I don't remember exactly why, this was 4ish years ago <nckx>Well, there was that thing with Samsung(?) laptops, but that wasn't Arch-specific I believe. <nckx>morrigan__: Very broadly, how do you roll back on Arch? Aren't upgrades destructive? <morrigan__>I think it was something to do with a kernel version disagreeing with something else low-level. <morrigan__>nckx: By "roll back" I mean "compile and install the previous version of the conflicting package" <morrigan__>I had to boot from a rescue and poke around to find what was causing the problem <guix-vits>nckx: "Rescue-device", arch-chroot and downgrade; never performed myself. ***guix-vits is now known as morrigan___
***morrigan___ is now known as guix-vits
<nckx>Pretty sure that's illegal. <nckx>guix-vits: 8.2.0314 fails in the same way as …303 by the way. <nckx>guix-vits: I think we got that. <guix-vits>nckx: What about Arch's 8.2.0148 (downgrade)? <nckx>I dunno. The last nckx-approved® version was 8.2.0069. 8.2.0236 presumably built fine for Jakub. I don't really feel like doing vim's bisecting for them tonight. <raghavgururajan>nckx Would you be able to pastebin your complete services field please? <nckx>Things like minutes->seconds obviously won't work as-is but it should be obvious what they do. <nckx>I still think your dbus failure is related to a missing user-session component, not a system service, but I don't know that much about dbus myself. <nckx>p.d.n managed to make my ugly config even uglier \o/ <nckx>Although it also says DBus users should autolaunch one if it doesn't yet exist 🤷 <nckx>I'd believe that if I hadn't added dbus-launch to my start-up files to fix actual bugs. ***Server sets mode: +cnt
<drakonis>not merging core updates for this release and saving it for later for a blog post might be nice and fun <drakonis>exploiting distro news cycles for fun and profit <drakonis>as it turns out, the install script isnt clear that it needs the signed keys to be on root's keychain <drakonis>though that should've been assumed when it asked to run as root <guix-vits>drakonis: the script that installs Guix unto foreign distro? <drakonis>hm, i wonder why the daemon rewrite to guile hasnt come up in this gsoc <drakonis>ehh i'm not sure why that's relevant though <guix-vits>drakonis: Is the daemon written in Guile 3 or 2? <drakonis>the main difference between guile 2 and 3 is that guile 3 has a jit <drakonis>sneek: later tell civodul is there any particular reason the daemon rewrite proposal hasnt returned for gsoc 2020? <drakonis>it hasnt been a gsoc proposal since 2018 <funfuna>What is the general speed when you download binary packages?(ci.guix.gnu.org) <guix-vits>funfuna: Western Syberia, mobile tethering (weak LTE): 300 - 500 Kb/s as the minimum. <guix-vits>funfuna: i'd similar troubles for connections for SIM-2, in my phone model full speed is only for SIM-1. <funfuna>Is it difficult to set up a server to provide Guix now? <nckx>guix-vits: The daemon is written from C++. It's an old (patched) fork of the Nix daemon, rewriting it in Guile would finally make it ours. <nckx>funfuna: It's not plug-&-play but it's not hard. The server still needs to download all the sources though. <nckx>*in C++, of course, good night. <guix-vits>funfuna: good news is, that Guix fetches from the "snapshots". All software versions are frozen until the next `guix pull`. <drakonis>writing it in guile would not only make it ours but make it significantly more hackable <drakonis>and it'd allow replacing those pesky .drv files <drakonis>nckx: perhaps it should be included in this year's gsoc page <efraim>if your compute speed is faster than your download speed you could switch to compiling locally <str1ngs>that would not speed up source downloads though :P <efraim>true, but most package updates are due to dependents being updated, not from actual version updates of that package <efraim>I think I used update ambiguously <efraim>most changes in profile generations is due to a dependant of the installed packages changing, not due to an actual change directly in the installed package <PurpleSym>Is there a package in the tree using multiple source URLs and merging them into one directory before building that I could copy? <guix-vits>PurpleSym: idk. Can you share what are you doing? <PurpleSym>guix-vits: I’m trying to package rstudio, which has releases on github, but the build system tries to download extra files from the internet. <guix-vits>"Use a BIND-VERSION of our choosing instead." ^ <guix-vits>not sure if they got merged in the same dir... <PurpleSym>guix-vits: That looks promising, thanks! I guess I can extract the tarball somehow. <efraim>There's a couple of packages were extra bits are downloaded as inputs and then unpacked into the build directory later <Blackbeard>I'm trying to install guix system on a hard drive that already has parabola <Blackbeard>gnu/system/file-systems.scm:241:6: In procedure file-system-needed-for-boot?: ***apteryx_ is now known as apteryx
<Blackbeard>is there somethin to consider when I already have a grub partition? <guix-vits>And if can, not to something protected by Cloudflare, please :) <raghavgururajan>Blackbeard Also, describe here about your partition scheme (MBR/GPT, no. of partitions with type, etc.) <Blackbeard>ok I have 4 partitions /dev/sda1 is for boot with grub <Blackbeard>sda2 has parabola, sda3 is where I want to put guix, sda4 is empty <Blackbeard>sda1 already has a grub, the one that boots parabola <efraim>does anyone have a snippet to delete everything except for a specific file or two? <efraim>oh good news it's not necessary. The repo was far more cluttered than the release tarball <Blackbeard>of course I can wipe it and change it to EFI, I just need it to recognize parabola, but I don't know if that is possible if I change from BIOS to EFI <raghavgururajan>Blackbeard Okay so, 1) Change sda1 to sda in target field of bootloader. 2) For file systems, use (needed-for-boot? #t). <raghavgururajan>Anyway, this installation will overwrites grub in BIOS-BOOT (sda1), but you will have a menu-entry to boot parabola. :) <Blackbeard>worst case scenario I boot grub-repair usb right? <Blackbeard>raghavgururajan: the (needed-for-boot? #t) is for / ? <guix-vits>efraim: rm -i `find -type f | grep -vE '(NOT_DELETE_ME|AND_ME_TOO)'` ? <efraim>guix-vits: I'm looking for something to stick in a snippet <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>Blackbeard That;s correct. needed for boot is in right place as mentioned in manual. <efraim>I ended up with this: (for-each delete-file-recursively (find-files "." "[^Cargo.toml,^build\\.rs]")) <efraim>doesn't delete the directories, but they're all empty <Blackbeard>gnu/system/file-systems.scm:241:6: In procedure file-system-needed-for-boot?: <Blackbeard>In procedure struct_vtable: Wrong type argument in position 1 (expecting struct): (#<<file-system> device: "none" mount-point: "/de <raghavgururajan>Blackbeard Hmm. I am not sure why you are getting the error "Wrong type argument in position 1 (expecting struct): (#<<file-system> device: "none" mount-point:". <peanutbutterandc>There isn't a lilypond-mode ready to install in guix itself (for emacs that is) is there? <guix-vits>Blackbeard: try to delete needed-for-boot ... <testa1>Would it be possible to offer torrent downloads for GNU Guix? <testa1>What DE does the live installer come with? <testa1>Would KDE Plasma be installable? <testa1>Any plans to equip the live install with a default DE? <Blackbeard>/mnt/etc/config.scm:26:16: error: invalid field specifier <raghavgururajan>testa1 You can choose from GNOME, MATE, Xfce, LXDE and Enlightenment. <Blackbeard>because menu-entry should be inside (menu-entries ) <testa1>how many maintainers are there currently for gnuguix? <guix-vits>testa1: 5 "heads" and unknown quantity of GNU partisanes. <testa1>if I have a package request, would IRC be a good place to discuss whether you would consider including it? <efraim>apparently we have about 60 people with commit access and I think ~200 contributors on an average month <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)))`. <raghavgururajan>Blackbeard And also, `%base-file-systems)))` should have only two brackets at the end. So `%base-file-systems))`. *raghavgururajan ---> Zzz <sneek>Blackbeard, you have 1 message. <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 <rekado_>I’m back to the office since yesterday, so for the next few months I’ll probably be on IRC more often than before. <dftxbs3e>I would like to submit some patches but I am confused by that problem where you can't send patches all at once. What does one need to do exactly? (actual git commands) <efraim>git send-email --to=guix-patches@gnu.org <coverletter> <efraim>git send-email --to=bug-XXXXX@debbugs.gnu.org <all-the-patches> <dftxbs3e>Is it just an argument where I explain what's being done? <efraim>a placeholder/short email that says "I did a thing!" and any explanation you want about the patch series <dftxbs3e>Is there a way to give the coverletter within an editor instead of within the argument like this? <efraim>when you do git format-patches -<number-of-patches> it'll also spit out 0000-coverletter (or so) <dftxbs3e>rekado_, I mean, I don't want to create a before before-hand, that would be tedious. Can git just open an editor if I don't give any coverletter? <efraim><coverletter> and <all-the-patches> are placeholders for 0001-first-patch 0002-second-patch ... <efraim>you can also just send a regular email to guix-patches and then send all the patches to the address you get in reply from debbugs <dftxbs3e>And uhm, send-email is unauthenticated SMTP? <efraim>I've always extracted the patches and then sent them off, I've never actually tried sending emails directly from a git tree <rekado_>dftxbs3e: I use send-email with msmtp <dftxbs3e>I see. Thanks. Any specific layout or configuration needed to send patches manually using say; Thunderbird? <rekado_>dftxbs3e: as long as the patches are generated with git format-patch everything is fine. <rekado_>you can also attach them to your email <dftxbs3e>So I can send a single mail and attach all the patches to it? <rekado_>(that’s a little less convenient for us, but it works) <dftxbs3e>Ah.. I don't want to put any inconvenience on you guys <rekado_>it makes review and in-line comments more difficult, but it doesn’t affect applying them much. <rekado_>thank you for working on porting Guix! <rekado_>I hope the review won’t be too painful for you. Let us know if it becomes too tiring. <rekado_>we don’t want to drag it out for too long, of course. It just sometimes happens. <rekado_>so… thanks in advance for your patience! <janneke>dftxbs3e: a coverletter can be created using the --cover-letter option to git-format-patch <dftxbs3e>rekado_, OK! I'm not going to send the patches for the port just yet. I have some patches to openssl and icu4c that break builds on powerpc64-linux <janneke>it generates a 0000-*patch file that you can use as a template for your first mail -- but you can also just compose the first mail yourself <janneke>i am using git send-email over authenticated smtp (smtpserver, smtpuser, smtpencryption, smtpserverport) <janneke>real soon now, we'll have g_bor[m]'s postfix with a trivial mta setup :D <dftxbs3e>I can't wait to actually run GNU Guix as my system so it's much easier to configure these things <dftxbs3e>Fedora favors a GUI oriented workflow and I'm slowly switching to GNU Emacs with i3 or maybe later exwm <dftxbs3e>I'll be back later! Thanks for the help. <rekado_>I haven’t but I heard that it isn’t very usable, unfortunately. <rekado_>it seems that many more people use StumpWM <funfuna>I tried launching it using gdm and ~/.xsession. <funfuna>but it fail: Could not find any X authentication token for ~a ~a ":1" "chromebook" <guix-vits>"An annotated sample init file is included with the distribution as "wm-init-sample.scm"." <funfuna>I found that guix placed a default configuration file in my home directory. <allana>guix-vits: not good. But it motivated me to put guixSD on actual hardware <guix-vits>funfuna: Maybe add a xcb-proto to user's profile? It's already dependence of guile-wm, but... just to check. <efraim>does supertuxkart have a pvp mode using different computers? ***patrixl` is now known as patrixl
***wxie1 is now known as wxie
<rekado_>glibc 2.29 no longer installs rpc/xdr.h <rekado_>that file is needed by clang-runtime 3.5 <rekado_>in glibc I think it can be enabled by switching on legacy RPC support <rekado_>the file exists in the source tarball; it’s just not installed <rekado_>I’m working around this by building clang 3.5 with glibc 2.28, but the better fix would probably be to enable legacy RPC in glibc 2.29 <efraim>I had trouble in the past linking packages using different versions of glibc *alextee[m] has a bunch of patches ready to send :-) <janneke>rekado_: yeah, i remember "fighting" with that to disable it in the bootstrap <guix-vits>Are Guix patches frequently get accepted upstream? <alextee[m]>some do, some don't in my experience, i think it helps to ping people with commit access otherwise they might get overlooked <janneke>guix-vits: i think it's always best to try, unless maybe it's entirely guix-specific -- but even then <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. <apteryx>weird naming for python2 modules: /gnu/store/wlpf643b4901fqlsj1s38d6iax5sw5rw-python2-python2-keyring-8.7 <efraim>apteryx: on master? I didn't get the duplicate prefix <nckx>apteryx: I also cannot reproduce that (guix build python2-keyring). <roptat>Oh, found it. I'm not too far from NYC actually but my visa status would not allow me to receive that money <joshuaBPMan>heyo roptat! I've made a very hacky way to get guix's vpn to work for me.... <roptat>And even refusing the money would then be unpaid labor, which is also illegal <alextee[m]>roptat: i doubt it classifies as labor if you do it voluntarily, but i dont know the exact laws lol <roptat>Unless I get permission from my university to go give a talk on something unrelated to my current work <joshuaBPMan>I hardcoded my openvpn config file in the service definition. :) <roptat>They told us to be very careful and to at least talk to them first <roptat>joshuaBPMan: I can't find tls-clent in that file. It would be simpler if you could make a patch instead :) <joshuaBPMan>roptat: oh no. What I did is not submitable upstream. <joshuaBPMan>#$pid-file "--config" "/home/joshua/prog/guile/guix-config/vpn/my_expressvpn_switzerland_udp.ovpn" <joshuaBPMan>Right now I'm trying to figure out how to get myopenvpn service type to accept a file argument. <roptat>You could check the type of the configuration <joshuaBPMan>that way I can do this: (myopenvpn-client-service #:file "/path/to/file.opvn") <joshuaBPMan>Is it better to do (myopenvpn-client-service #:file "/path/to/file.opvn") or (myopenvpn-client-service #:config (file "/path/to/file.opvn")) ? <joshuaBPMan>I think the #:file option is probably a little better, but I could be biased. <apteryx>efraim: if you define a package python2-something, and start the recipe with (package-with-python2 ...), it'll trigger the problem. <roptat>joshuaBPMan: can you make an opaque-openvpn-client-configuration type maybe? <apteryx>I don't include it in Guix proper as it's mostly obsolete (hello, python 2). <roptat>I think you will find examples looking for opaque in the existing services <joshuaBPMan>roptat: ok. I'll look for an opaque service example. Let me fire up the old grep. <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? <nckx>It fixed some MIME issues for me in i3. <apteryx>nckx: it could just stop doing anything for 'python2-' prefixed packages, perhaps? <nckx>Not all of them though. I still occasionally spin up a LibreOffice when accidentally opening a patch file. <leoprikler>do you have a mime association set for patch files? <leoprikler>otherwise it'll likely open whatever it believes to be the editor <nckx>No, of course not, I've never touched a mime in my life. I have emacs installed. That should be enough. <leoprikler>In my personal experience mime types in Guix are extemely brittle. <nckx>apteryx: That's one heuristic. I prefer stupid-but-predictable over magic-but-even-more-convoluted-than-it-already-is but don't have a horse in this race. <apteryx>another weird thing I'm now facing, with this "cleaned up" definition of python2-keyring@1.6 https://paste.debian.net/1132139/: 'guix build -L some-channel-dir python2-keyring@1.6' -> 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>efraim: I think my problem stemmed from python2-keyring now inheriting from keyring, and not python-keyring. I'm trying to understand how this works. *apteryx is braindead today, beware <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 ;-) <NieDzejkob>Since I saw patches sometimes not being merged mentioned in the backlog, here's a free tip: link your patch on IRC to make people look at it! <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. <alextee[m]>i test (and use) the packages before i send the patches, but yeah these are a bit niche so it's probably hard for others to test, <alextee[m]>but even if you are not sure if they work properly, a package that doesn't work 100% properly is better than no package IMO, it's easier to fix something than make a new package <alextee[m]>should probably add steps to test it along with each patch <kmicu>nckx: reading in 2020 that chief of a project is Saint is not my thing 😺 Of course if Guix maintainers want to allocate time for that then be my guest. <bavier1>kmicu: I think they don't use that joke on that page, afaics <leoprikler>Don't worry, it's actually the opposite with Guix. A few months ago, there was a shitstorm because we "cancelled Stallman". <kmicu>bavier1: Yes, sorry, it’s ‘The Chief GNUisance’, I’m not good at paying attention to that sillines. <bavier1>but yeah, there's little to no allocation of time in that regard <Blackbeard>I gave up and went to sleep, so I am gonna try again today *bavier1 sinking in administrivia <kmicu>I’m not worry, but personally I will stop pointing folks to GNU Guix. <bavier1>Blackbeard: hope it goes better this time; please seek help here if you can <Blackbeard>yes, I think there might be a bug with (menu-entries) or something in the documentation needs to be updated <Blackbeard>although of course, I might be doing things wrong <kmicu>bavier1: In the past I was happy to do that. <leoprikler>Blackbeard: So you're going for a dual-boot setup? <Blackbeard>I have a sda1 with grub, no EFI, then sda2 with parabola, I want guix on sda3 <kmicu>bavier1: I’m familiar with that. But it’s easier to deblob NixOS than constantly explain Chief. <drakonis>that'd miss the point of guix, honestly. <Blackbeard>the only reason why I keep parabola is because I need my printer to work and it uses some proprietary bits :( <leoprikler>Fair enough. So what does your config.scm look like? <leoprikler>okay, two hints: first (append (list ...) %stuff) = (cons* ... %stuff) <leoprikler>it appears you are doing (append (list ... %base-file-systems)) by mistake <leoprikler>don't forget to audit your menu-entry for parabola as well, specifically "/boot/old/initrd" seems fishy and manpagey <apteryx>does it makes sense to source ~/.bashrc from ~/.xsession? <leoprikler>you should put environment variables into ~/.{bash_,z,...,}profile <leoprikler>if your bashrc has something they lack, that's abug <apteryx>shouldn't the wrap phase of the python build system use '= to protect the wrapper against impurities from the environment? <apteryx>to prevent the wrapper from leaking in impurities from the environment, in a better worded sentence ;-) *sirgazil goes and replaces append by cons* in system config (but thinks cons* should have an alias like add or add*). <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 :-) <leoprikler>DamienCassou: You probably want to provide one of --share or --expose <leoprikler>perhaps I'll try --expose=/etc/passwd next time I check something in a VM <sirgazil>leoprikler: I don't know scala, but cons* is meaningles for people that don't know Scheme, imho. <DamienCassou>that makes sense. I was trying to create an image with qemu-img and mounting in the VM but that doesn't work. Your solution seems easier <leoprikler>the name `cons` is pretty standard in Lisp though, so `cons*` as "cons, but different" makes sense <leoprikler>That said, you need to have a little lisp background to get behind it, I agree. <Blackbeard>leoprikler: you are right, I was using ssh from my laptoy <Blackbeard>seems like I didn't copy the changes from my computer <Blackbeard>yesterday they were right tho, and still failing <DamienCassou>leoprikler: `--share` is part of `guix environment` but I'm using `guix system vm`. How are those two related? <leoprikler>DamienCassou: `guix system vm` documents an option with the same name, it probably works similar to what you know from environments <leoprikler>Blackbeard: That's because not having the right entries is a different kind of error – even if you put in something wrong there, it would be constructed. <leoprikler>Whereas having a list instead of a struct is a type error, which results in an exception. <Blackbeard>leoprikler: so I should change (append (list ) for (cons* ) right? <leoprikler>That is always a good idea in my opinion. But if you don't want to do that, it suffices if you adjust the bracketing in your file-systems section <sirgazil>kmicu: "The Chief GNUisance is responsible in principle for all significant decisions" 👎 <sirgazil>sway users, how do you get system sounds? (pavucontrol says system sounds are audible, but I can't hear them) <drakonis>kmicu: tbf i use guix not for the deblobbed parts but for all the other cool lisp features. <drakonis>its like throwing the baby with the bathwater to not recommend it <kmicu>drakonis: folks have different goals and different use‑cases. (Untyped) lisp part (sometimes called freedom, sometimes called mess) doesn’t bring much value to me personally. <kmicu>Like typed Nix. That doesn’t change the equation for me. <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? <str1ngs>so you want dont' like RMS but you want like want the benefits his vision and philosophy have created. <str1ngs>let me rephrase you don't like RMS but you want to benefit from all his work? kmicu ? <nckx>kmicu: I don't want to tell you what to do. But consider who this affects more: Guix or GNU. <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 <drakonis>because rms was interfering too much and causing gcc to stall out <elais>Does RMS still push code to anything? <drakonis>he exerts his authority in really inconvenient ways <leoprikler>Long story short, some of his attitudes are seen as toxic by a portion of GNU/FSF. This is not to say, that all of his ideas are bad, however, but people like to think in boxes. <alextee[m]>like making technical non-freedom related decisions when he shouldnt? <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 <drakonis>he wrote the original incarnations of emacs and gcc <drakonis>the issue is that he's so disconnected from things that he shouldn't steer any projects anymore <drakonis>he hasnt written a line of code in decades <alextee[m]>of course, he went the political route and made a foundation and spread the free software message. that was best for the movement <drakonis>his advocacy hasnt been exactly in top shape though <elais>Great, but he should butt out of technical decisions <elais>GNU projects are healthy without his input <str1ngs>this sounds like alot of band wagon jumping to me. <str1ngs>and it's pretty pretentious to tell the originally author no you don't get a say in the project you created. <leoprikler>From what I understand, RMS is not a good figurehead in 2020, be it political or technical. <drakonis>there's technical decisions by rms that are guided by his notions of freedom that are very... poor <drakonis>he took issue with allowing gcc's ast being exposed to other applications <drakonis>ie: editors using it for syntax highlighting <leoprikler>which is why we have clang-format, but not gcc-format <drakonis>apparently it would be bad that it could also be used for non free purposes <str1ngs>leoprikler: have you heard of GNU indent? <leoprikler>And I find it somewhat perverse, that clang tools almost have better Emacs integration than proper GNU tools. <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 <drakonis>gcc for the longest didnt have a plugin system because of rms <drakonis>because people could write nonfree software with it <leoprikler>Suppose you have a completely free backend that merely exports it as Lisp or XML <str1ngs>for the longest time gcc has been the only free C compiler worst using <leoprikler>Any nonfree software could read that string and process it in whichever way it needs. <alextee[m]>so in the end, all the things you mentioned are not technical but freedom related <str1ngs>do you think llvm is more free then gcc? you know llvm is primarly backed by apple . ask yourself why? <str1ngs>so they could circumvent GPL that's why <drakonis>llvm was going to be given out free of charge to gcc mind you <bavier1>I can't imagine a decision like that would have actually hinged on a single email to one person <str1ngs>free of charge != freedom . common misconception <drakonis>is it necessary to fight over the way i used the expression <kmicu>Fair, I started it so I politely ask you to return to topics closer to GNU Guix. There’s already enough RMS+GNU-Guix talk out there. <leoprikler>Does someone want to take a look at GNOME Terminal with 39783? <leoprikler>Be warned though, compiling all the stuff needed for the VM takes some time. <OriansJ`>leoprikler: up to 12 hours if you need gnome <sirgazil>Oh, I was going to give it a try, but only have one computer :) <leoprikler>Ahh, so you've already noticed. I should have known.