<fiesh>jonsger: hmm adding "librem_ec_acpi" to initrd-modules doesn't work since it can't find the module <fiesh>so I suppose this is the similar problem, it's not part of linux-libre <nckx>It's not part of Linux either, is it? <fiesh>no, it's in librem-ec-acpi-linux-module <nckx>Have you read about ‘kernel-loadable-modules’? <nckx>(guix)operating-system Reference <fiesh>no, trying to find it, thanks <nckx>mala: People who do this do it manually, simply by running ‘guix system init’. I don't know if a wrapper script exists or would be needed. <fiesh>nckx: I'd guess (kernel-loadable-modules (list librem-ec-acpi-linux-module)) should be fine, but I still get the same issue... <nckx>mala: Mm, this is more complex. <nckx>I've heard this described before but remembered only ‘lustrate’, not ‘infect’. <nckx>fiesh: Can you currently boot? <fiesh>nckx: yes, the module isn't necessary for it, it's just for being able to set battery levels and so on <nckx>OK, that's good. After booting after reconfiguring with (kernel-loadable-modules (list librem-ec-acpi-linux-module)), can you ‘modprobe librem_ec_acpi’? <fiesh>oh it actually loads by itself <fiesh>I can just not include it in the initrd image, which I don't need anyhow <fiesh>I just left it in sine I thought it would tell me if the issue was fixed <nckx>If you can boot without it that seems best. <fiesh>so all is good, thank you :) <fiesh>is there any standardized mechanism to alter /sys? akin to using sysctl from a service <vagrantc>fiesh: sometimes the - and the _ in the module file and the way the module thinks of itself are changed in weird ways and guix's initrd generation code is not clever about it <vagrantc>fiesh: e.g. module-x-y-z vs. module_x-y_z vs. module-x_y_z vs. module_x_y_z <fiesh>ah, something to keep in mind, thanks <mala>nckx, apparently there are a stack of these (nixos-infect, nixos-assimilate), etc <nckx>Yeah, I can't honestly say which I remember because I'm positive that I can't keep them straight ☺ <nckx>vagrantc: Why did you have to bring that up 😛 That is one of the worst. <vagrantc>nckx: i don't know if pain is a distributed load or a replicative load <nckx>Linux shot itself in the foot one day and now the official API is you *must* provide a foothole-sized pin in your module loader. <nckx>Much wow but above all else very Linux. <nckx>fiesh: Sorry, missed you. I don't think there is! <fiesh>nckx: no worries, thank you though... so is there any usual hackery to execute a script upon start-up or such? <vagrantc>i sometimes wish the guix initrd generation just had an "all the modules" or a way to specify "all modules below a certain subtree" <vagrantc>that's kind of sort of how Debian's initramfs-tools handles it ... <vagrantc>the default lists it comes up with work in a lot of cases, but ... not all that great for arm and whatnot <vagrantc>oh yeah, this is also because it iterates through the list at runtime, rather than using a tool to load this *vagrantc has surely commented on a bug report about this before <dissent>hello again guix, what could be the cause for inode consumption? i'm rapidly approaching 100% again. <cehteh>small filesystem? create it with a lot inode, and maybe guix gc will help <nckx>A store with many hard links (deduplication enabled) will use far fewer inodes than one without any. <cehteh>anyway store filling up will need inodes for unused stuff, gc should free a lot <cehteh>and maybe create the filesystem esp when it is small with an option to provide more hardlinks <dissent>guix gc didn't even free 1% of inodes. <dissent>oh yeah... deleting generations... that cleared up a lot. <apteryx>rekado_: re numpy CPU features, same for openblas it seems <jackhill>nckx, fiesh: oh, I want /sys setting service too. Something for the wishlist I suppose. <jackhill>Annoyingly, I should be able to do what I want with via the kernel command line args, but only some of them work. I think it's because the module I want to configure (zswap) isn't loaded early enough/built in. Some of it's paramaters work on the command line, but not all. Adding it as initramfs module doesn't work. <lfam>In kernel 5.15 there is a new multiplce-choice option "Initialize kernel stack variables at function entry" <jackhill>rekado_, apteryx: is more testing of CPU feature detection needed? I have a Core 2 Duo from 2008 with Guix to test. Even worse than non-reproducability, The code from the build farm may not even run on my cpu <lfam>I wonder which one to pick <podiki[m]>might be seeing a regression with redshift and python paths? <podiki[m]>I'm a few commits on c-u-f behind, but can someone try guix shell redshift:gtk -- redshift-gtk and see if that runs? <podiki[m]>I get "ModuleNotFoundError: No module named 'redshift_gtk'" same if in another profile, but runs if installed in the default user profile <apteryx>jackhill: I have a Core 2 Duo fro this era as well (Q6700) <apteryx>the numpy test suite used to crash with openblas built on berlin <apteryx>this was fixed with 9e497f44ba8104b6b4743e72cb041c8e15586a83 <apteryx>but the build still is not reproducible between different CPU of the same architectures <apteryx>raghavgururajan: it was done as part of the core-updates-frozen-batched-changes -> core-updates-frozen merge, although perhaps that's not clear from the history as the staging commits got rewritten there <apteryx>so yeah, staging is in core-updates-frozen <apteryx>sneek: later tell civodul re gnome 40 vs 41; the later is supposed to be some kind of improvement/refinement of 40, so I'd expect that the components from either mostly work together (and they seem to for the most part from what I can see). <jackhill>apteryx: hmm, I thought we had a blog post about cpu-specific optimizations, but I can't find it now. Sometimes I wish everyone would just use libvolk and be done with it, but I understand the world isn't so simple <podiki[m]>err....redshift's lib/python site-packages has gone missing? <podiki[m]>should guix_python_path include the package's own store path? <podiki[m]>redshift-gtk doesn't include its own and so doesn't find its own module (this is new breakage) <podiki[m]>doesn't -D just get the deps for the package, not the package itself? <jgart>ignore last paste. I'm trying to reproduce my issue. I'll paste again <jgart>podiki[m], yup, that's my understanding <jgart>Do I need a -D after every dep that I want to include in the guix shell? <podiki[m]>maybe, I forget if it consumes just one argument (was discussed here the other day) <jgart>or is every package/lib after -D included as deps <jgart>yup that is the detail I'm unclear on <podiki[m]>but -D libtermkey then means you don't have libtermkey available, just what it depends on, right? <podiki[m]>might check IRC logs from last few days and/or double check if manual was updated post that discussion. can't remember exactly, sorry <jgart>yup libtermkey does not show up in the shell <jgart>even though it is an arg to -D flag <podiki[m]>(so then you could build libtermkey in that shell) <jgart>by inputs, you mean propagated inputs and native inputs would not be included? <podiki[m]>my understanding was that it would set up the environment to have the dependenices you need to work on that package <jgart>I'm basically trying to build vis <jgart>but, when I do that libtermkey is not found <jgart>I'm trying to build a version of vis that is patched to include support for language server protocols <podiki[m]>my only thought is then I would try guix shell libtermkey -D vis <jgart>I tried building a "vanilla" vis also but it fails with segmentation fault when I try with guix <jgart>I tested building without guix (using deps installed by xbps on void linux) and it works fine <jgart>> my only thought is then I would try guix shell libtermkey -D vis <jgart>I'd like for `guix shell -D vis` to work but it doesn't unfortunately. <jgart>Should I file that as a bug in guix? <podiki[m]>i'm stuck. maybe try something else that depends on libtermkey to see if it is vis specific? <jgart>looks like neovim depends on libtermkey <jgart>Would be cool to start packaging lua based neovim plugins with guix <podiki[m]>meanwhile I'm off to update my profiles again (hello icecat build) to make sure the redshift python path problem I'm seeing is real *jgart guix shell -D neovim <jackhill>I think there might be some mailing list posts from around the same time. IIRC: nvim looks in a different location than vim for plugins, so even the vimscript packages we have don't currently work without creating neovim-specific versions. <jgart>Oh that's interesting. Thanks for sharing <jackhill>Right now the vim ones use copy-build-system. Rather than creating neovim ones by hand, I was thinking of doing something like package-with-python2 or the common-lisp procedures to create neovim packages from the vim ones. Of course that makes some assumptions about the how copy-build-system is being used for vim packages, so I'm tempted to create a vim-build-system to enforce the invarients/add more <jackhill>semantic meaning to the package definitions <jackhill>you're welcome. Of course I became distracted before finishing that investigation :/ <jgart>jackhill, that would be great to have a proper vim-build-system like nix has <jgart>I think we might want a lua-build-system at some point <ulfvonbelow>build systems seems slightly less than sane, requires you to provide a github token just to build... <jgart>ulfvonbelow, seems to have a lot fo js: jquery, underscore, etc... <jgart>those would prove difficult to build with guix completely from source <jgart>unless they are allowed to be vendored in <apteryx>openblas does run-time optimization (e.g., it bundles all possible ones (larger binary) and select the best one at run time) <apteryx>(still doesn't built reproducibly for some reason on different CPU of the same arch) <apteryx>others want to be compiled with -mtune=native; in this case we opt to not distribute substitutes (users have to build them themselves) <jgart>Would it be possible to have rust 1.56.1 on master branch? *jgart would like to package rust 1.56.1 <apteryx>why not; you should add it on the core-updates-frozen branch though to not cause more work <apteryx>(the rust toolchain is heavily modified there) <jgart>I need that rust compiler for a few packages I'd like to have in guix <jgart>where can I read about core-updates-frozen? <jgart>Is it documented in the manual like core-update and staging? <apteryx>no, it's just a branch that's going to be merged in master soon <apteryx>before december or early december I hope; seems we're getting there <jgart>apteryx, is it easy to use packages from a branch other than master? <jgart>what has been your experience installing packages that are not in master <KE0VVT>I was confused by master → main. <jgart>I mean as an end user using `guix time-machine` subcommand <apteryx>jgart: guix time-machine --branch=core-updates-frozen rust@1.54 <jgart>KE0VVT, It let's you install/build packages from any branch, commit, etc... <apteryx>(the above is already possible -- 1.54 exists there and is used to build the rust world) <jgart>I tried guix time-machine once but ran into issues with it <apteryx>more like "guix time-machine --branch=core-updates-frozen -- install rust@1.54" <jgart>that's why I was asking if you've encountered any bugs <jgart>that's helpful and appreciated <jgart>apteryx, Do you forsee adding rust 1.56.1 to core-updates-frozen to be a lot of work? <jgart>Or would it be a simple addition? <apteryx>should be simple, but please follow the packaging advice near the bottom of the module (move testing logic to that 1.56.1 package) <apteryx>yeah; rust don't support older releases anyway, so the world should be built against 1.56.1 <jgart>is rust 1.56.1 the 2021 edition? <jgart>I was having trouble confirming that <apteryx>was does 'the 2021 edition' mean? AFAIK rust stable is on a 6 months schedule <jgart>void-packages is also not at 1.56.1 yet <jgart>Would you like to see the build fail log? ***TheOwlLady is now known as myrcy
<nanoir47>I'm installing gnu guix on xps 9310 but when I started to partition the whole disk, the only disk available is my boot USB. Also the network is not detected, while it can surely be accessible via Windows. Anybody could help? <jgart>nanoir47, do you have a ethernet cable you can connect the laptop too? <apteryx>if you have wired ethernet available, try it; wifi drivers are one of the problematic areas for free software so often do not work unless carefully researched <jgart>xps 9310 will probably not have a wifi card that works out of the box with guix <jgart>you'll need a wifi dongle or ethernet cable <apteryx>jgart: weird, I think there was another person reporting that package-cache problem when attemping to guix pull --core-updates-frozen <apteryx>jgart: yeah the build log failure may be helpful in understanding what's wrong <jgart>how is it that I read bz2 again? <nanoir47>apteryx Thanks. What about the hard drive on xps 9310? It cannot be detected when I started the partition. <jgart>apteryx, what's you're workflow for reading bz2 from /gnu/store? <jgart>is there a convenient way to read it? <apteryx>I don't use compression on my build logs; else I use bzless, zless, etc. <apteryx>(I don't use compression because my file system is Btrfs with zstd compression; which is probably about as good but faster) <apteryx>nanoir47: perhaps you're hitting an known issue in 1.3.0 with some special newer drives (nvme?) <nanoir>apteryx yeah, I suppose mine is nvme. Is there a solution or workaround to that? <apteryx>(try a newer image; I think some fixes went for that in post 1.3.0 commits) <nanoir>apteryx Thanks! I'll give it a try on that iso <apteryx>it's also probably just a bug in guile-parted IIRC; so you may be able to workaround it by doing a manual installation rather than using the "graphical" one <apteryx>but try a newer iso first, as that'd be easier <nanoir>Thanks! May I ask where you found that link to newer iso on the first place? I never thought about anything except the official one <jackhill>core-updates-frozen could probably use some attention from someone more experienced with rust. Right not rust-bitflags@1.2.1 doesn't build for me. Newer versions seem to, but alacritty depends on that version for some reason *jackhill watches a libreoffice build start again <apteryx>nanoir: I'm not sure it's documented <apteryx>but if you visit ci.guix.gnu.org you can see the 'images' job and navigate to it (somewhat ackwardly) <podiki[m]>hrm, one needs python in a profile in order to get a guix_pythonpath? <jackhill>podiki[m]: yes, I think so. At least that would be consistent with how our other search paths work <podiki[m]>I don't know why this didn't bite me before then (redshift in a different profile than python...) <podiki[m]>maybe I had it installed in my main profile too at some point or something <apteryx>rekado_: is 45656 handled by your recent texlive importer work? if so, could you please close it? thanks! <jgart>apteryx, that's the build log failure for rust@1.54 from core-updates-frozen <brendyyn>if a have a font package source where the source is changed inplace all the time, where is the best place to host a copy of it? seems inelegent to use github. <jpoiret>hmmmm, was the hicolor-icon-theme always empty? <jpoiret>on master and on c-u-f, the store location has folders but no icons <jpoiret>alright, it's supposed to be that way, my bad <fiesh>jackhill: have you found a suitable workaround? I guess in addition to a /sys-setter service, a general shell executor service might come in handy every now in then for hacky solutions to things that only require hacky solutions <thorwil>hi! i didn’t use blender in a while, to now find out it will exit right away with: X Error of failed request: BadAlloc (insufficient resources for operation). Major opcode of failed request: 149 () <jpoiret>so, are we upgrading gnome to 41 on c-u-f <thorwil>this is on a foreign distribution. glxgears and glxinfo work fine, no matter if ubuntu or guix version is used. <thorwil>meanwhile, the tarball release fresh from blender.org works <Franciman>does the linux-libre kernel have the ability to load firmware? <thorwil>all i can find online points to issues with specific mesa versions (which should be fixed now) and drivers. a driver issue should affect the tarball blender, too, so i think that can’t be it. <jpoiret>thorwil: me as well, that's weird. In both cases, are you compiling using Guix's tools? <jpoiret>you could try with guix shell --pure blender -- blender <jpoiret>maybe there's a rogue env var somewhere <thorwil>jpoiret: not compiling in either case. it’s substitute vs prepackaged binary. <thorwil>`guix shell --pure blender -- blender` has the same result (X Error of failed request: BadAlloc (insufficient resources for operation)) <jpoiret>hmmmm, the prepackaged binary might not use guix's packages at all <jpoiret>maybe there's a mismatch between the X that's running on the foreign distro and the libraries in guix that blender depends on <thorwil>i guess so, but don’t know how to diagnose further, or what to do about it in general <thorwil>a few weeks may have passed since i used guix blender the last time, successfully <jpoiret>unfortunately it seems that the usual method to debug this is to git bisect <jpoiret>did you upgrade the blender package? <jpoiret>or upgrade your X server on the foreign distro? <jpoiret>you could use `guix pull --list-generations`, and use the commit sha of the last working generation with `guix time-machine --commit=<sha> -- shell blender -- blender` <thorwil>and X server upgrade may have happened ... i do not always pay attention to system upgrades, as it all tend to just work <jpoiret>if that still works, then it should be an update to blender that broke it, if it doesn't then that might be external factors <jpoiret>well, recently xorg-server 21.1 got released, so there may be breakage <jpoiret>we're using that on c-u-f, if you're brave you could try `guix time-machine --branch=core-updates-frozen -- shell blender -- blender` <jpoiret>(warning: you may have to compile a bunch of things locally) <thorwil>jpoiret: thank you for your thoughts. since i need a workingblender right now, i will just use the prebuild one and check the situation with guix again at some later date <thorwil>oh, and the entire output of `guix pull --list-generations` does not contain “blender” here. which makes me wonder what there was to update about blender <jpoiret>thorwil: guix pull lists your guix generations, not when and how the packages updated. You can also use `guix package --list-generations` to see generations of your packages (that may be the easier option too, whoops) <abralek>Hi everyone. So I hit this error: Unsafe AuthorizedKeysCommand "/gnu/store/5n6wigbpffpy6x453ckf35rrc0vi0lai-ldapsearch-sshkey-1.0/bin/ldapsearch-sshkey": bad ownership or modes for directory /gnu/store <abralek>Would it be good idea to patch ssh daemon to ignore /gnu/store? <abralek>The /gnu/store has drwxrwxr-t (root:guixbuild) permissions. The program must be owned by root, not writable by group or others and specified by an absolute path. <M6piz7wk[m]>I JUST HUGGING FIXED MY HUGGING HOMEWORK AND IT BUGGED AGAIN CAUSING EVEN MORE DATA CORRUPTION <vivien>Libreoffice hasn’t even finished compiling here <vivien>(sorry in english it should be "isn’t finished") <vivien>Are there interpretation differences? <nckx>jackhill: <Adding [zswap] as initramfs module doesn't work.> Like, at all? <brendyyn>isn't -> is not. hasn't -> has not. 'is not' means right now something isnt the case. 'has not' means in the past up until including now something has not occured yet ***unmatched-parent is now known as unmatched-paren
<unmatched-paren>I thought packaging Wike would be a good way to learn how to make Guix packages. <brendyyn>libreoffice hasn't finished building yet. The libreoffice build isn't complete. <nckx>jackhill: I build in zswap for the same reason. ☹ There are a few such ‘select M for low-feature demo mode I guess’ pseudomodules in Linux (pstore comes to mind). It's frustrating. <brendyyn>looks like it would use meson-build-system <unmatched-paren>it build correctly, but when i run it it barfs out a bunch of errors <nckx>brendyyn, vivien: It's partially specific to software. You'd never say that a building hasn't finished building. I don't think I'd say it of software either, but it sounds less wrong there, at least. <brendyyn>nckx, you would say the package hasn't finished building <nckx>Maybe? Honestly can't say, once you start thinking about it etc. ☺ <brendyyn>thinking about grammar may result in dizziness <nckx>Yeah, you're right, I might, brendyyn. I'd say it sooner than I'd type it though. <brendyyn>unmatched-paren, bit of a random guess but i wonder if using python-wrapper will help <unmatched-paren>installing python-wrapper didn't resolve it, if that's what you meant <florhizome[m]>How would I go on best to analyse the processes after I run guix command? <florhizome[m]>i found some articles of civodul uses the kernel perf tool but it’s a bit over my head I fear. I would like to show/analyse which processes make the generating profiles step for a profile containing iconthemes/gtkthemes so incredibly slow <brendyyn>unmatched-paren, i notice the nix package substitutes @PYTHON@, and some guix packages do too <unmatched-paren>should i just use the wike commit hash marked 'Release 1.6.1' since it doesn't seem to have any release branches or tarballs? <nckx>If there's a git tag marking that release, set it as version and use (commit version) or (commit (string-append "v" version)). <nckx>We currently use tags over raw commits if they exist. <nckx>This may change some day but hasn't yet. <nckx>lfam: I can't/won't build/unpack a kernel (on battery), but I see that we had CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL=y in 5.4 (only); how did we lose that…? Shall we return to that? <nckx>It's quite possible we don't support it (yet) but that's a wild difference, and should be kept in mind, I guess. <nckx>I wish they gave rough overhead estimates. <Guest58>is it possible to copy files to the home directory of a user in a guix package? <Guest58>im trying to write a package for my dotfiles so that they would be installed automatically <unmatched-paren>i think there's some vim plugin packages that do something pretty similar, copying themselves to the user's vim autoload directory <unmatched-paren>there's probably some (get-environment-variable "HOME") that you could call <roptat>Guest58, no it's not possible: a package can only install to the store <roptat>(getenv "HOME") will give you /homeless-shelter <roptat>you can manage dotfiles with guix home <Guest58>but this installs the files under /gnu/store <Guest58>like even if i use absolute path to copy file it still adds that path to the path of the package in /gnu/store and puts it there <Guest58>uh which suggestion sorry i disconnected earlier cant see it <roptat>Guest58, right a package can only install to the store <roptat>Guest58, to manage dotfiles, you can use guix home <Guest58>ye but that wont install them automatically along with the system when i run `guix system init` right? <Guest58>well isnt there a way to hack my way around it <Guest58>like in one of the build stages write the copy commands manually <roptat>no there's really no way around, by construction, a build does not have side-effects on the system <nckx>You can't save anything outside of /gnu/store/<hash>-<package name, version>/ at all. <nckx>There is no (pretty-please (install "foo" "/home/Guest85")). <jpoiret>builds take place in an isolated environment using namespaces <roptat>mh, you could use the special-file-service-type (or whatever it's actually called) in your os configuration to instal files to /home on reconfigure <nckx>You'll have to write a service. <unmatched-paren>from what i can see in gnu/packages/vim.scm, copy-build-system can only put stuff in ~/.guix-profile, but it works for vim plugins because of ~/.guix-profile/share being a shared data folder, correct? <Guest58>ok question is it possible to run for example if statements when installing the system like when running `guix system` tell it if the machine has less than 20gb of storage dont install a specific package? <nckx>unmatched-paren: It puts things in /gnu/store, then assumes that these will be symlinked into ~/.guix-profile because this is what happens by default when a user run ’guix install PACKAGE’. <nckx>But it's actually not a great assumption, it works only in that specific case and breaks if you use any other profile location. It's a good-enough-for-now hack. <nckx>Profile directories are ‘union’ symlink trees of all the corresponding /gnu/store items of all packages in that profile. <unmatched-paren>so if i had /gnu/store/blahblah-1/bin and /gnu/store/blahblah-2/bin, they'd both end up in ~/.guix-profile/bin? <roptat>Guest58, in the system configuration you could have something like (packages (append (if (system-storage-lower-than 20) '() `((,foo))) ... %base-packages) <roptat>(where you need to define system-storage-lower, of course) <nckx>Guest58: Your system configuration is just a Scheme programme that returns an <operating-system>, so you can calculate whatever you want at evaluation time, including whether the current machine has N GiB of disc space on / at the moment you run ‘guix system init’, ‘guix system reconfigure’, &c. <nckx>You could even write an system.scm that includes icecat as a system package only if you evaluate it at midnight. <nckx>But once you return the <operating-system> and let Guix build it, the list of system packages (and everything else) is frozen. <Guest58>ye nix is basically deprecated by guix i doubt u can do that with nix lol <nckx>unmatched-paren: We do not explicitly approve (nor disapprove) this. <nckx>Guest58: Nix might claim that as an advantage, it's more sandboxed, reproducible (no explicit access to system state), etc. <nckx>We put ‘hackable’ on our home page and get away scot-free ☺ <nckx>Guix extends that quality of Guile/Scheme itself: functional when you want it, but not limited to it. <nckx>(Well, with limits, of course. <nckx>#<hexchat>:2:1: unexpected end of input while searching for: ) <fcw>I am trying to package Shutter, a screenshot tool written in Perl (https://github.com/shutter-project/shutter). It installs, but there are errors when I try to run it. Nothing happens after the errors are printed. No window appears, and the program does not exit. The errors appear to be related to Gtk: "GLib-GObject-WARNING **: cannot register <fcw>How should I investigate the problem? Any hints? <lilyp>fcw: mess with GI_TYPELIB_PATH until it makes sense <fcw>It includes lots of Perl libraries that are not yet in Guix. <M6piz7wk[m]>How do I install guix on system with just WiFi exactly ? Its failing post partitioning <jpoiret>how is it failing exactly? is the installer image the """"stable"""" or latest one? <M6piz7wk[m]>I have TTY with terminal so I guess I can connect there ? *M6piz7wk[m] failed to find the command for that <fcw>lilyp: "GI_TYPELIB_PATH=~/.guix-profile/lib/girepository-1.0/ shutter" didn't help. What are the other values for GI_TYPELIB_PATH that make sense? <lilyp>fcw: you need to bind it appropriately in some wrap/post-wrap phase during installation <M6piz7wk[m]>Is that I cant connect bcs its non-free firmware for the WiFi thing <fcw>lilyp: Thanks for the tip. I will look for examples in the Guix repository. <vivien>M6piz7wk[m], do you get pinged on other channels with matrix? <unmatched-paren>when I was installing debian, the netinst non-live wouldn't let me connect to wifi, but the live image did <roptat>unmatched-paren, 'invalid field specifier' means there's a syntax error in a record <Franciman>is there any external wifi adapter you suggest for using with guix? <roptat>unmatched-paren, that's why good indentation and coloring is essential :) <roptat>unmatched-paren, can you share what happened? I'd like to see real-world examples of "invalid field specifier", I have a patch that might improve debugging that a bit <roptat>I want to make sure it would give you a useful hint <unmatched-paren>roptat: unfortunately i'm reduced to working in nano for now until i get nvim nightly working, so the syntax highlighting is not what i'm used to <unmatched-paren>error: (modify-phases %standard-phases (add-after (quote unpack) (quote skip-gtk-update-icon-cache) (lambda _ (substitute* "build-aux/meson/postinstall.py" (("gtk-update-icon-cache") "true")) #t)) (add-after (quote glib-or-gtk-wrap) (quote python-and-gi-wrap) (lambda* (#:key outputs #:allow-other-keys) (let ((prog (string-append (assoc-ref outputs "build") "/src/wike"))) (wrap-program prog ( <unmatched-paren>quasiquote ("GI_TYPELIB_PATH" = ((unquote (getenv "GI_TYPELIB_PATH")))))) #t)))): invalid field specifier <roptat>right, we could improve that too <fcw>unmatched-paren: Why don't you use vim with vim-paredit? <ss2>Hello, would someone have a look at this: https://paste.rs/web, plase? I'd like to substitute a line in a file, but it always errors out, and it doesn't make sense. Somehow the file is never found, but it it there. <unmatched-paren>fcw: i use nvim with tree-sitter, which works for common lisp, but it doesn't have a scheme parser (yet), so paredit might be an idea <roptat>when I edit packages it unbalances parenthesis, insists on rebalancing by inserting a parenthesis on the second-to-last character of a line... it's terrible <NePank>Hi folks. I'm new new to Guix and I would like to know if it is possible in Guix System to declare/install user specific packages via config.scm? Like in NixOS with a command "users.users.alice.packages = with pkgs; [ emacs ];". I did RTFM for last few days, but sadly I was not able to find the answer. <nckx>Unless this is a very hands-off way of asking for a code sample 😃 <apteryx>fun, linux-libre can now build reproducibly on core-updates-frozen, and the fix was trivial: 01ea70a29c5c1ded31c37ce8c43192bc1956b2ca <nckx>ss2: "pulsectl-21.10.5/" prefix is suspicious. Are you sure the build isn't already happening in it? It should be. <unmatched-paren>i've now got to the point where guix has stopped complaining about my .scm file and meson has started complaining about... something. Progress! <nckx>apteryx: Oh neato, thank you! Trivial but you did it. <ss2>the output in that is kept in /tmp has pulsectl-21.10.5 as tree structure <nckx>Yes, but the first thing you'd do if building it yourself would be to cd pulsectl-21.10.5 && ./configure && … <nckx>Since it's almost universally desired, it does so in 'unpack. <unmatched-paren>data/meson.build:9:0: ERROR: Tried to assign an invalid value to variable. <ss2>isn't that what substitute* does? This procedure is put after 'unpack too. <nckx>I don't understand. Is what? <nckx>fcw: Absolutely fine. It should be, if you're up for it. <unmatched-paren>what am i doing wrong here? i have absolutely no experience with meson <jpoiret>NePank: I don't think it is the case. Guix user profiles aren't managed by `guix system` yet, and I don't think they should really be, because users may want to use a different guix than the one used by guix system <lilyp>fcw: parallel-build? doesn't come from perl-build-system, but gnu-build-system, where it ought to be documented <unmatched-paren>because i mostly use languages with baked in build systems like rust and ocaml <nckx>ss2: Substitute is just a minimal Schemey sed-alike. It doesn't chdir away from your pwd. <lilyp>the only good thing about rust is that meson now has an unstable module for it <nckx>Relative paths are just that. <ss2>nckx: alright, I can just leave out pulsect-version then! <lilyp>maybe some day we'll have a "sane" build system for rust <nckx>Since 'unpack chdirs to what it heuristically thinks is the correct directory, which here is pulsectl-blah, your file name needs to start from there. <unmatched-paren>lilyp: what problems has cargo caused for you? personally i've always found it works well <lilyp>but that aside, what's your substitute* <nckx>apteryx: Oops… I've had (setenv "KBUILD_BUILD_HOST" "gnu") (setenv "KBUILD_BUILD_USER" "guix") in my kernel since $forever, and I never thought to check Guix proper. Sorry about that. <nckx>With comment ;; From <Documentation/kbuild/reproducible-builds.rst>. <nckx>Which might be a better ref than some LWN article FWIW. <nckx>ss2: You can stop writing #t) at the end of phases & snippets, even those targetting master. There are obsoleted by core-updates. <vivien>native-inputs is for compilers and code generators, inputs is for the installed program dependencies <vivien>I’m glad you didn’t ask for propagated-inputs ^^ <nckx>unmatched-paren: inputs are built for the architecture of the final output, native-inputs for the architecture the build is being run on. Only differs when cross-compiling. <nckx>unmatched-paren: No, don't blindly map it to other names. <vivien>In cargo, it’s more complicated ^^ <nckx>They might happen to be the same but it's pointlessly risky to equate them. <nckx>I'm sure there are differences. *nckx 's never used cargo. <lilyp>I like Gentoo, because it shows how dependencies can be a clusterfuck <vivien>I mean, for the rust build system in guix, it’s complicated <nckx>But in most package managers that have ‘dependencies/dev-dependencies’, ‘dependencies’ means ‘these are things I have to make available at run-time’. Guix doesn't do that, at all. <fcw>nckx: How do I make sure that I have placed the correct packages in inputs and native-inputs? <nckx>inputs is only consulted at build time. Never at installation (=profile generation) time. <fcw>Is there a way to make the build fail if I placed a package in the wrong category? <jpoiret>damn, the c-u-f webkitgtk{,-with-libsoup2} deps are quite a blocker for me to work on the branch :( although ci just caught up with me, so I'll do something else in the meantime <jpoiret>also i might need to patch gtk, and that'll entail rebuilding webkitgtk... gnome-shell really is a pain, just for gdm <nckx>fcw: Good question! I… can't immediately think of a test that isn't: if you package builds and runs fine both when cross-compiled and not, you probably got it right? ☺ <unmatched-paren>nckx: that kind of sums up a lot of programming "if there's no errors, assume it works and you'll be ok probably maybe" :) <nckx>When cross-compiling and your build scripts invoke a programme that's in non-inputs inputs, the build will generally fail. But it's possible that the build system interprets the failure to run as ‘disable foo support’ and just gives you a subtly broken package, so it's not fool-proof. *nckx is in an unsheltered car and it just started to hail. I will take my leave to protect my paint job. o/ <nckx>s/non-inputs/non-native/, sorry. <lilyp>vivien: it's when rain droplets turn to ice mid-air <lilyp>well, ninjas are usually tasked to kill people, so it's no wonder <unmatched-paren>The Python python kills you with a toxic spit known as the 'unreadable stack trace' <vivien>It’s also known to swallow all your memory in one piece <jpoiret>you haven't seen an eval guile backtrace then i guess :) <jpoiret>"in unknown-file:4: (_ _ _ ...) invalid type to apply: <#oe5o85o8>" <vivien>The deadliest guile backtraces happen when you have circular module inclusion <unmatched-paren>can i use regexes in substitute* or is it just plain text substitution? <jpoiret>hmmm, I'm getting "ld: /gnu/store/xidfq8arwkpcvw085kdnvicc4294p314-profile/lib/crt1.o: in function `_start':" while trying to use gcc in a `guix shell gcc-toolchain gtk` on c-u-f <lilyp>vivien: still half as much memory as your typical JVM <jpoiret>"(.text+0x20): undefined reference to `main'" <nckx>unmatched-paren: Moreover, the string is parsed as a regexp regardless of your puny human wishes, so you must always escape ‘.’ and ‘(’s, etc. And since it's a Guile string, you get to write "\\(Oh, hello\\.\\)". Fun! <nckx>"\\(Not \"confusing\" at all\\.\\)" <jpoiret>uhmmmm, do not read my previous two messages (who doesn't check that the code they're compiling has a main???) <vivien>Don’t forget that the regexp are written as guile string literals, so if you need to match the backslash character it’s really \\\\ <nckx>The point is that I do try to forget. <vivien>Also, if you put a dot in your regexp, it will also match a literal dot, so you won’t know your regexp is broken. <roptat>(it's the same as the currently present ocaml4.07-charinfo-width-1.1.0.tar.gz, but renamed... its source is no longer reachable) <vivien>The certificate looks good to me here on tor <nckx>I don't want to mess with berlin's configuration too much. <nckx>I know, but I don't understand. <roptat>I think you're just missing nss-certs <nckx>☝ applies to most things I know. <nckx>I should not need to install nss-certs on berlin though. <vivien>nckx, look if SSL_CERT_DIR contains multiple entries <vivien>If it does, then guile will fail because it does not support multiple directories <nckx>roptat: So I manually set SSL_CERT_DIR and it works. It was set to 2 (identical) entries. No, nss-certs is not in my profile (nor should it be AFAIK). <nckx>Oh thanks vivien, yes, I noticed that too :-/ <nckx>It's downloaded but currently stuck at ‘warning: SQLite database is busy’. <nckx>No, does not seem to be. <nckx>roptat: JSYK, not all can succeed because of (at least) ocaml-csexp-1.5.1-checkout <roptat>"cannot build missing derivation" is a cuirass error :/ <nckx>The derivation is there and fully built (/gnu/store/ffrfi4x82lgpm9lig2n376zc5q0p427l-webkitgtk-with-libsoup2-2.34.1 et al), but we knew this already :) <jpoiret>ah, looks like it's registered as succeeded now, i was too hasty. Guix won't refresh substitutes again though, any way to force that? <nckx>It caches foundness for a while in .cache/guix/substitute. <nckx>You can delete that and retry. <jpoiret>doesn't seem to work (let me say i'm using ./pre-inst-env) <M6piz7wk[m]>i can already see how painful it's going to be to find compatible parts for the visionbook to make it to run libre things u.u <nckx>jpoiret: Are you sure you're requesting exactly /gnu/store/ndpi72gv60v2g1gwyhds9d49dkbn0m00-webkitgtk-with-libsoup2-2.34.1.drv ? <nckx>Setting aside ./pre-inst-env for a while, when you run ‘guix build /gnu/store/ndpi72gv60v2g1gwyhds9d49dkbn0m00-webkitgtk-with-libsoup2-2.34.1.drv --substitute-urls=https://ci.guix.gnu.org’ (because the version of Guix is then irrelevant) with a clean cache, does it still not find anything? <nckx>Doesn't help that Visionbook does not turn up many English results for us Englishes. <nckx>unmatched-paren: Key-value look-up in an ‘association list’. `(("key1" . "cool value") ("key2" . "no I'm cooler") (2 . "keys can be anything") ("so can values" . #t)) <nckx>Not a Guix thing, but Guix uses them muchly for inputs etc. See the Guile manual. <unmatched-paren>so (assoc-ref outputs "blah") looks in the 'outputs' list for 'blah'? <nckx>If you write them like we do in Guix, `(("key" ,value)), note that (assoc-ref "key") will return (list value). You don't always need to know this in Guix but it can be relevant sometimes. <nckx>unmatched-paren: Exactly. <jpoiret>actually, no i don't have the same derivation, that's weird. I'm one commit ahead of the eval commit <vivien>unmatched-paren, you need to substitute that file <vivien>Replace 'gtk-update-icon-cache' with 'true' <vivien>(usually it’s done in a phase after 'unpack) <nckx>Ungh, Cuirass doesn't update ‘failed (dependency)’ failures when the failure is resolved :-/ <nckx>I have clicked on ‘Restart’ at least 60 times so far. <nckx>And with it hidden in a drop-down, x 2 that. <unmatched-paren>i tried to substitute the whole call to call() with a blank but that doesn't fix it either <nckx>Why does replacing it with ‘true’ not work? <jpoiret>funnily enough, it substitutes the doc properly (?) <lilyp>(substitute* "build-aux/meson/postinstall.py" (("'gtk-update-icon-cache'") 'true')) <nckx>Are you sure the substitution has effect? (You can add ‘plonk’ or whatever on the line after the substitute* call, and run with --keep failed.) <vivien>You need to keep the single quotes around 'true' <vivien>'true' is a coreutils program that always succeeds, whatever the arguments <nckx>unmatched-paren: You should not get ‘name 'true' is not defined’ if you used quotes. <nckx>That's why ‘exact same‘ and ‘nothing relevant’ are generally met with distrust here ☺ <nckx>Even when used with good intentions. <vivien>("desktop-file-utils" ,desktop-file-utils) <nckx>unmatched-paren: Right, and that's exactly why I distrust such statements. It happens a lot. ‘No, nothing new/relevant. No really. Nothing. Oh, that? Well, it had other lines around it, how could I have seen it!’ Meanwhile, my forehead is a bloody mess. <nckx>podiki[m]: I'll apply it without the copyright lines if that's OK. <vivien>I also have 52009 if "someone" has time :) <unmatched-paren>ok now i'm getting the same error that i had a few hours ago at the start <podiki[m]>(soon I'll try to update everything again, I think all will be good for me on c-u-f except that pesky python-nautilus I have to figure out) <vivien>unmatched-paren, I’m not sure I was there a few hours ago, could you describe the error again? <vivien>unmatched-paren, congratulations! <bost>Hi. Do you know what to do to get the UTF chars displayed? <unmatched-paren>i just spent a few hours of torture... building a wikipedia reader :p <podiki[m]>nice work unmatched-paren, some packages are pretty trivial once you get the hang of it, others you gotta keep learning new tricks for <lilyp>bost: you're probably just lacking a font that has them: install one (like google-noto), then refresh your fc-cache <PotentialUser-6>I've recently installed guix on Fedora 35 via install script and installed some packages from there. But when I try to launch any application from wayland, I get this error: <PotentialUser-6>(geany:17678): GLib-GIO-ERROR **: 21:25:53.098: Settings schema 'org.gnome.settings-daemon.plugins.xsettings' does not contain a key named 'antialiasing' <podiki[m]>unmatched-paren: you can do guix install $(guix build -f file.scm) <unmatched-paren>the damned package has infected my brain and now i can't stop thinking about it >:( <podiki[m]>or temporarily in a guix shell I think, with guix shell -f file.scm <vivien>You’ll keep thinking about it every wiking hours of your life :) <vivien>Not sure that’s the correct grammar <vivien>unmatched-paren, that’s a python program, right? <lilyp>PotentialUser-6: I don't think we currently build gnome stuffs with wayland in mind, you'd have to fix that <vivien>You need to wrap the GUIX_PYTHONPATH <lilyp>c-u-f probably does, tho, so no need to worry <bost>lilyp: Ok. I'm trying... <lilyp>GUIX_PYTHONPATH is not yet a thing on master, is it? <vivien>unmatched-paren, look at gnome-tweaks for instance <lilyp>unprefixed PYTHONPATH it is :P <vivien>I know gnome-tweaks is a python app with libhandy dependency <vivien>But that’s on core-updates-frozen <vivien>I don’t know if it depends on libhandy on master <lilyp>It does, but I don't think it does wayland on master <PotentialUser-6>lilyp: meaning? I've installed guix package manager on fedora 35. how am i supposed to fix this? <vivien>unmatched-paren, is there a wrap phase? <lilyp>PotentialUser-6: If you want to do it the hard way, you can find all the packages and add wayland as an input <lilyp>and fix the builds so that they do wayland <lilyp>Or you wait until Guix has Wayland Gnome like the big distros :) <vivien>unmatched-paren, your application is probably using python-pygobject. This library will try to find libhandy in GI_TYPELIB_PATH, so you better wrap the programs setting this variable <vivien>Wrapping a program means moving the program to program.real and creating a shell script that will set up some environment variables and then call the .real program. <lilyp>the nasty bits that vivien just said are covered by the wrap-program procedure <lilyp>PotentialUser-6: How do you do what? <vivien>unmatched-paren, on core-updates-frozen, there’s a phase modification: (add-after 'install 'wrap <vivien> (@@ (guix build python-build-system) wrap)) <vivien>That’s so that python will find python-pygobject <vivien>Then, for python-pygobject to find libhandy, you need the extra GI_TYPELIB_PATH wrapping <unmatched-paren>so i'll just copy and paste the wrapper stuff in gnome-tweaks into my recipe and see what happens <vivien>Don’t forget to add libhandy as an input <lilyp>again, vivien's being unhelpful with the c-u-f tips <lilyp>look at how gnome-tweaks does it on master and copypasta :) <vivien>(also I’m not super thrilled about gnome-tweaks using (@@ module private-variable) on core-updates-frozen) <lilyp>vivien: you can fix that, though <lilyp>use (assoc-ref python:%standard-phases 'wrap) <bost>lilyp: looks like cleaning the font cache really helped `fc-cache --verbose --force`. Thanks <lilyp>It's aliiiiiiiiiiiiiiiiiiiiiiiiiiive! <unmatched-paren>But when I click a link 'WebKit wasn't able to find a WebVTT encoder. Not continuing without platform support for subtitles.' <M6piz7wk[m]>that hugging libreoffice on guix hugged up my homework again <nckx>M6piz7wk[m]: Is this on Guix System (assuming not, considering previous chats)? <nckx>Or Guix's LibreOffice package? <yewscion>Sorry if this is a basic question, but I'm having difficulty with my Guix binary install's pkg-config. It cannot find guile; and it looks like even though I have guile installed through Guix it did not symlink the appropriate .pc file into the profile, or even include the .pc file in the store. I've SSH'd into my server's system install, and it <yewscion>seems the same there. Is there something I am missing? <nckx>SRT files but FOR THE WEB because, oh fuck if I know. <nckx>It's probably JSON wrapped in HTML5 for maximal webbiness. <oriansj>unmatched-paren: WebVTT are subtitles <vivien>yewscion, are you sure you installed pkg-config from guix too? <nckx>M6piz7wk[m]: <this> is not something I can parse. ‘Yes, it is Guix's package’? <lilyp>nckx: it's actually SRT plus a little extra <unmatched-paren>okay so i'll add srt2vtt to inputs and see what happens because that's all that comes up when i ask guix search for VTT <nckx>Little bit of extra Web magic. <lilyp>but everyone knows that real people use ASS <yewscion>vivien: I am; `which pkg-config` returns `$HOME/.guix-profile/bin/pkg-config` in both cases. <lilyp>no really, look at the wikipedia entry *M6piz7wk[m] is making 8 copies <nckx>M6piz7wk[m]: On which distribution? *M6piz7wk[m] added guix non-free like 20 min ago to it which shoudn't affect the package <nckx>Not that it's an excuse but I use LO on Guix System and haven't had such issues. *M6piz7wk[m] needed to build the iso u.u <lilyp>okay, I take back everything <lilyp>"Metadata information can be added in a JSON-style format" <vivien>yewscion, if PKG_CONFIG_PATH does not include something about .guix-profile, you need to set up your shell <M6piz7wk[m]>nckx: it seems to be unable to auto-save and then just gets stuck in an infinite loop <M6piz7wk[m]>this is working with a file that was most likely imported from a proprietary software <M6piz7wk[m]>bcs the text is all mangled and the teacher who made it doesn't know how to format the text <nckx>M6piz7wk[m]: Do you have any idea if this is reproducible in a way that isn't ‘type stuff for 8 hours straight; observe crash’? <M6piz7wk[m]>so it's just mess of text fields so that he can add superscript.. <nckx>It's a cursed file? Does it crash rather soon? Could I reproduce it? <M6piz7wk[m]>i just working and then suddenly it fails to do autosave and ruins my life <nckx>Apparently you can run ‘soffice --backtrace’ or ‘soffice --strace’ (before the crash happens) to get backtraces. <yewscion>vivien: $PKG_CONFIG_PATH returns `$HOME/.guix-profile/lib/pkgconfig:$HOME/.guix-profile/share/pkgconfig`; Is there somewhere else that needs added? <lilyp>M6piz7wk[m]: pro tip: save the file as .txt <vivien>yewscion, so you did guix install guile, and pkg-config --cflags guile-3.0 fails? <lilyp>get rid of all the styling and embrace simplicity 😎️ <M6piz7wk[m]>the pdf file that i was given from the school is probably made in something made from adobe based on what the teacher told me indirectly <M6piz7wk[m]>so i guess the repro would be sh!%!@ in pdf file using adobe and then import it in LO as odt <vivien>yewscion, there are other parallel discussions, so that’s for you: nckx asks whether PKG_CONFIG_PATH has literally $HOME in it, or is it just you that replaced /home/yewscion to protect your privacy? <yewscion>nckx: not literal $HOME, just cannot share full directory structure. It is pointing to my actual home directory, though. <nckx>Sorry for not nickpinging I'm hella distracted myself. <nckx>That would've been easy but oh well. <vivien>Is there a guile-3.0.pc file in $HOME/.guix-profile/lib/pkgconfig? <lilyp>why is webvtt even a topic right now? <nckx>unmatched-paren: makeGStreamerElement("webvttenc", nullptr); <yewscion>vivien and nckx: It's working now; I restarted my session entirely. Might have been something related to my employer's modifications to Ubuntu, I dunno. <nckx>is the code leading up to this. <vivien>French speakers here suddenly want to ride bikes in the woods <nckx>So I'd start by installing all the gst-plugin packages in the same profile, unmatched-paren. <unmatched-paren>lilyp: because wike hangs when opening certain articles and complains about webvtt in the console <lilyp>the guixy way is to patch your GST_SYSTEM_PLUGINS_PATH <lilyp>oops, my bad, it's actually GST_PLUGIN_SYSTEM_PATH <nckx>Guix is very festive. We hope you like wrapping packages. <podiki[m]>(praise the CI for libreoffice substitutes on c-u-f!) <vivien>Will we have substitutes for christmas? <lilyp>unmatched-paren: btw. for gst plugins using suffix is the way to go <lilyp>I think for christmas I'll change one bit in a very important hash. <lilyp>Then I'll be the villainess who stole Christmas. <M6piz7wk[m]>nckx you should be able to reproduce the behavior by using random odt file and then openning it in a text editor and break it and then wait for LO to do autosave <M6piz7wk[m]>it seems that the failure is LO being unable to save the file and the auto-save lacking any timeout for the task that breaks everything *M6piz7wk[m] doesn't know how to break odt file that way <nckx>Ah, so: create lol.odt, save lol.odt, corrupt on-disc lol.odt with favourite text editor, wait for the next auto-save to hit? Can do. <vivien>M6piz7wk[m], that’s a novel way to sabotage your homework <nckx>I'm not sure I expect it to ‘work’ but can do. <drakonis>corrupted file format causes LO to crash <lilyp>on a related note, why would you ever want to modify imporant-homework.odt while LO claims the lock? <lilyp>sounds like intentionally taking a laser cannon to the knee <drakonis>its one way to shoot oneself at the foot <vivien>Maybe that’s a part of an elaborate plan: produce a corrupted garbage file for the deadline, then wait for the teacher to come back to you, and send the final work (you’ll have a few more days to finish it :)) <nckx>vivien: I might have, if not done, considered doing that. <podiki[m]>(so we have to put something like "late, incomplete or corrupt files..." etc) <nckx>A significant number of people think corruption == can't be deliberate human action. <lilyp>unmatched-paren: let me get back to you in just a sec <vivien>If you need to send your homework as an email, you can also pretend email delay by changing your system time before sending the mail <podiki[m]>(libreoffice substituted, but qtwebkit no...and I guess that one goes single thread so it takes a while) <lilyp>it's gst-plugins-bad, who would have thunk? <podiki[m]>which leads to llvm and rust not being built, and thus a lot of stuff <lilyp>Real pro tip: save the mail as mbox, then edit the date <nckx>Real pro tip: run your own mail server, forge more headers. *nckx has not done this, for the record. <lilyp>none of that works in my university though, we either have submission systems with file upload or worse need to tag our submissions in git <vivien>Real pro tip: use your social engineering skills to guess the name of the first teacher’s pet, and mess with the inbox <lilyp>Real pro tip: Guess the name of the teacher's pet and write your own grade. *podiki[m] covers his teaching eyes <lilyp>Well, there is M-x guess-teacher-pet-name-dwim <podiki[m]>that's a great one; used it in a class on math mistakes (lots of integer overruns, not sanitizing things, so like "None" in a database of driving tickets or something....) <nckx>I have done what I described above, ran ‘echo RINGDONGHELLOTHISISCORRUPTION | dd skip=100 of=/tmp/lol.odt’, but LO doesn't seem to mind. <nckx>Auto-save set to minutely. Manual saves also work fine. <nckx>Assuming that LO reads the on-disc file at all is IMO a leap. <nckx>I'll try a few more random offsets but I do not expect great things from this low-budget fuzzing expedition. <lilyp>nckx: everyone knows you need /dev/urandom for best results <nckx>s/skip/seek/, typo was here. <nckx>lilyp: I don't want to be left eternally frustrated if one run actually happens to work and I never manage to reproduce it again 😃 Although, yesh, I could store a copy each time. <podiki[m]>so putting exclude in setup.py isn't stopping it from doing stuff on python setup.py install <lilyp>unmatched-paren: lgtm, but you might want to restrict gst-plugins-bad to just the vtt thingy <podiki[m]>can I ignore the error, or temporarily move the files and back for guix install phase? <lilyp>there's a procedure gst-plugins/selection that does just that <unmatched-paren>so ("gst-plugins-bad-vtt" ,(gst-plugins/selection "gst-plugins-bad" "vtt"))? <nckx>Auto-saves don't actually modify the original file at all. <lilyp>not quite: #:plugins '("vtt") <nckx>M6piz7wk[m]: Honestly, what weird things are you doing. You still haven't explained how you discovered this very foot-bangy-offy looking ‘bug’. <unmatched-paren>("gst-plugins-bad/vtt" ,(gst-plugins/selection gst-plugins-bad #:plugins '("vtt"))) is failing with 'unknown location: quote: bad syntax in form quote' <nckx>This allays none of my worries. <nckx>unmatched-paren: Can you paste the whole package? <lilyp>unmatched-paren: btw the plugin is actually subenc <podiki[m]>if I wanted some files to avoid the python setup.py install, I could move them directly to their store location before the install phase? <nckx>Works if I add ‘#:configure-flags '("-Dbogus=flag")’. Guix bug? Didn't check. <nckx>After #:plugins '(…), that is. <lilyp>perhaps, try #:configure-flags '() too <nckx>`(,@(or configure-flags '())) in gnu/packages/gstreamer.scm must be buggy. Masked because it's never called without configure-flags in Guix itself. <unmatched-paren>oh i think there's another plugin in gst-plugins-bad that's necessary <unmatched-paren>because the 'Portal:The arts' page is blank with only setenc enabled <unmatched-paren>whereas it errors if there's no gst-plugins-bad, and works fine with every bad plugin enabled <nckx>Or maybe other gst-plugins-*. <lilyp>unmatched-paren: do you get some nifty debug output? <nckx>unmatched-paren: find $(guix build gst-plugins-{bad,base,good,ugly}) -path '*/gstreamer-1.0/*' <nckx>Yes there are prettier-output ways. <nckx>They take longer to type :) <vivien>I’ve finally upgraded my guix home :) <unmatched-paren>looking through that list, i think it might be better to just add all of them <vivien>So now everything seems to work correctly, although I’d like to have issues 51948 and 52009 before the Big Merge, and maybe the static networking service <KE0VVT>I stil cannot install apps on the Guix installer while I'm installing the system. <vivien>KE0VVT, the installer isn’t a live demo <vivien>I don’t think you can install apps on it <KE0VVT>vivien: Good thing I have IRC running on another computer. <nckx>vivien: It is, though, and you should be able to. <unmatched-paren>yeah i'll just do ,gst-plugins-bad and explain in a comment that it requires several <nckx>Possibly after starting cow-store so you don't fill up your RAM with functional goodness. <nckx>If you can't guix install libreoffice in the installer, that's a bug. <KE0VVT>nckx: I ran "guix install weechat" in another TTY once I got the install doing its thing. <nckx>vivien: Put more succinctly, ‘live demo’ != ‘desktop’. <KE0VVT>I mean, a live desktop would be really cool, but I just wanted to use WeeChat. <nckx>I install lots of stuff during the average install, although emacs being there by default is already a back-up OS. <KE0VVT>nckx: The installation of WeeChat went normally, but my shell could not find "weechat". I even tried starting another instance of Bash and seeing if it would reload the "$PATH" or something. <nckx>^D and <Return> to ‘log out’ back in? <nckx>KE0VVT: Which image was this? <nckx>Guix should have printed instructions, at least. <KE0VVT>nckx: Instructions are on TTY 2. <nckx>Simply typing ‘bash’ at the bash prompt isn't supposed to reload $PATH. If it did that would be a bug. <nckx>KE0VVT: Instructions as part of the command itself. <nckx><Simply typing…> But logging out & back in is. <KE0VVT>I did Ctrl+D and Enter in this TTY. WeeChat was still not there. <nckx>& what does ‘guix package -I’ say? <KE0VVT>nckx: "guix package -I" says nothing. I'm not sure how to paste the contents of "$PATH" when I'm on this other TTY inside an SSH session. <nckx>Right. I'm mainly interested in whether it contains ~/.guix-profile/bin but I'm almost certain that it does. <nckx>You simply didn't install weechat. <nckx>I'm not disputing that you typed something, but weechat isn't installed. <jgart>should any calls to "(invoke "mv" ..." be rewritten to "(rename-file ..."? <jgart>I see a few in the code base <nckx>KE0VVT: What does ‘guix package -l’ say? (just to troll people with a bad font.) <nckx>(But also because I wish to know.) <KE0VVT>I run "guix install weechat" again, and it just says "The following package will be installed: ..." but nothing else. <KE0VVT>nckx: root's Guix profile does not exist. <nckx>But ‘guix install’ should create it IIUC. <KE0VVT>nckx: No grafting, no file movement, no downloading. <nckx>Unless this is some known bug that I missed getting fixed. <nckx>jgart: Wow. Feel free to fix them, making sure to compare the output to be sure. <nckx>Or use them as easy first patches of course. <KE0VVT>nckx: Most likely. I downloaded from the first big option on the download page to get the system installer. <KE0VVT>Didn't look at the version number. >_< <nckx>It's almost certainly the stable one then. <KE0VVT>nckx: By the way, the installer cannot see fancy quotes. <nckx>I will definitely forget not to use them. <KE0VVT>I only use straight quotes for code, like in GNU Info. *nckx is booting the installer. *nckx is booting the installer again. Why is ‘-accel kvm‘ not the default!? <KE0VVT>I wish I could run VMs. My X200 can't. <lilyp>unmatched-paren: you probably want git format-patch <unmatched-paren>the git manpages really ramble on... is there a more concise description anywhere? <nckx>KE0VVT: I was in that situation for many years and I still run too few VMs today, out of habit. <nckx>unmatched-paren: The canonical (also, correct) answer would be ‘git commit && git format-patch -1’, not ‘git diff | whatever > patch’. <nckx>‘git commit -a’ to be precise. <nckx>KE0VVT: I downloaded the ‘x86_64’ image from https://guix.gnu.org/en/download/. I then booted it (in QEMU but doesn't matter), switched to tty3 immediately, ran only ‘guix install weechat’, then typed ‘wee<TAB>’ and it completed to weechat which runs fine. <nckx>I'm reassured for us, but do wonder what went wrong on your end. <nckx>‘It should just work’ etc. <KE0VVT>nckx: Did you do it after installing? <lilyp>doesn't work when you're on gmail tho <podiki[m]>on the rename-file, install-file, etc.; what should I use to move a whole directory into the output directory? <nckx>lilyp: It has a Gmail tab and sendgmail is in Guix; is it broken? <nckx>So that taints manners somehow? <lilyp>ah, right, sendgmail works, but it's not "out-of-the-box" as far as my concerns go <lilyp>plus I prefer not to bootstrap an entire ecosystem just to send mail <nckx>I just saw some fixes float by the ML. <lilyp>Those fixes usually tell you to allow "insecure apps" or something of the sort <nckx>But anyway, don't use GMail. <nckx>Simple life hack. You're welcome. <lilyp>Well, point taken, but I've got a different hack so I'm fine 😎️ <KE0VVT>It is hard to find email hosting. <nckx>lilyp: Wasn't aimed at you personally! <KE0VVT>singpolyma: I have email, obvi... oh, that works. <KE0VVT>singpolyma: Yeah, I have an indie email account, but it is not open to people, so I can't recommend it to others. <singpolyma>tilde.team is open to anyone who can talk about why they want to join and has email and jabber among other things <KE0VVT>singpolyma: Nice, considering dismail.de is no longer accepting applications. <podiki[m]>lilyp: copy-recursively I think it is (odd, others are delete-file-recursively, but ok) <nckx>lilyp: Thanks for the patch! Now that I have time to look at it… `(,@(or configure-flags '()) is… weird? I wonder where that got cargo-pasted from. <lilyp>I don't think I've cargo-pasted it, but there's definitely one superfluous occurrence because I wasn't thinking too hard back then *nckx makes note to git blame first next time. <nckx>Here's another reason that I don't use VMs as much as I should: I use qemu-system, and after loadkeys dvorak-programmer (no idea if related, I just can't type qwerty), the keyboard soon gets into a state where I type lowercase but things act like shift is pressed (Tab goes backwards in the installer, - and _ are still swapped, etc.). If I hit caps lock I type caps whilst these things now act normally as if shift isn't pressed. <nckx>So it's like the VM has both shift + caps lock keys ‘stuck’ in virtual hardware. I think. <nckx>Is this familiar to anyone? <podiki[m]>that's happened to me in a vtt nothing to do with dvorak, no idea why either <nckx>Stuck down (pressed at once), to be precise. Pressing my real physical shift key releases the virtual one. I think. <nckx>At least that's the only mental model that makes sense to me. <podiki[m]>in my case maybe cause of something gone wrong with X and how the keyboard is being read? (was always in some emergency situation, hence the tty) <nckx>This is Sway. QEMU itself might or might not be using Xwayland, just to add another layer of craziness. <nckx>Abstraction: it was a good idea, up to a point. <nckx>But we might want to give it a think. <nckx>podiki[m]: Thanks for the feedback! VTT? <nckx>(Linux) virtual terminal? <nckx>podiki[m]: So a raw kernel VT, not kmscon (which is what the Guix System installer uses — the VT you see is actually running in user space, hence cool things like Unicode support, oh wait KE0VVT reported that's broken). <nckx>That rules out kmscon being to blame at least. <podiki[m]>this was pre guix at least, not sure about on guix <podiki[m]>I don't know what kmscon is, but this was with early KMS if that is helpful <nckx>kmscon is just the terminal emulator the installer uses. <nckx>It uses modesetting, but modesetting can be (and often is) used without kmscon, just the built-in kernel VT. <nckx>If you can scroll back with shift+PgUp on a recent kernel, you're using kmscon. <podiki[m]>fortunately I haven't run into this emergency VT need on Guix System so far... <podiki[m]>but my guess when this happened for me was what X was doing with the keyboard (something was unresponsive in X), and I also to caps lock to ctrl mapping with xkb <darth-cheney>hey all, I'm using Emacs installed from guix on a foreign distro <darth-cheney>For whatever reason I cannot get emacsclient to connect to a running emacs daemon <nckx>The fake installation ENOSPC'd. Oops. Let's install weechat anyway! <darth-cheney>It keeps telling me it cannot find the socket. All my googling has failed me <nckx>darth-cheney: Mine is /run/user/1000/emacs/server <darth-cheney>Is it possible my regular init.el is screwing things up? <lilyp>nvm, nckx has the right path *roptat just pushed coq updates :) <roptat>our ocaml and coq packages are now *mostly* up-to-date <darth-cheney>nckx: there's nothing there either. that's the other possible location people were talking about on SO <lilyp>but tmp-based emacs servers were around sometime IIRC <nckx>…or not, because cooking is dark magic. darth-cheney: I used ‘sudo ss -l | grep emacs’ (probably not the 1337est version but it works) to find mine. <mala>I have some updates to guix that I need to use for my local laptop (mainly an update to mesa). Right now I'm keeping them in a local branch of the main guix repo, which I fast-forward occasionally. In my current setup, this means I have to disable authentication and allow downgrades. Is there a better way? Maybe creating a separate channel for my changes? <vivien>mala, the core-updates-frozen branch is more up-to-date, maybe you could try it? <nckx>Get commit access, forget --disable-authentication exists. /s You could create a channel, mala, but then you'd have to manually sync (and seed with the current committers) the keyring branch. <darth-cheney>nckx: yeah that commant returns no results at all for me <nckx>I'm assuming these are patches to Guix itself, not something that could go in a separate channel altogether. <nckx>darth-cheney: And yet you're certain that a daemon's running? <nckx>A successful one that some emacsclient can connect to? <nckx>Not exactly what I asked 😉 <darth-cheney>No I've never been successful connecting the client that's the issue <nckx>I realised that after I sent the first line. <nckx>All with Guix's emacs server + client? <nckx>Have you tried without any custom configuration? <darth-cheney>though I'm using the flat channel because I needed nativecomp <darth-cheney>nckx: what's the quick command to load a different init file? <nckx>mv ~/.my-init.el{,.bak} ? 😛 I thought you meant a custom init.el you were using. <roptat>mh, what's the difference between max-silent-time and timeout? <nckx>roptat: max-silent-time is how long it goes without printing a byte, timeout is how long it's been running since launch. <mala>nckx, well they're patches to package definitions that should be accepted upstream eventually. If I extracted the out into a separate channel (without a history), that would work, right? What do other people do with local changes? <roptat>nckx, do you know the default values? <darth-cheney>Do you all have any strategies for this? Do people keep different configs for daemon mode? <nckx>Plus this is one of those fun things you get to chase from maxSilentTime to max-silent-time with perhaps a few things inbetween. <lfam>sneek: later tell nckx: I actually noticed that too. I don't know where it went after 5.4... <darth-cheney>It's like when I load my normal config it never actually puts the process to the background. It just sits there in the terminal running <sneek>Welcome back nckx, you have 1 message! <sneek>nckx, lfam says: I actually noticed that too. I don't know where it went after 5.4... <nckx>Just dumping that before I forget ☺ <nckx>lfam: So I got to wondering: should ‘we’ just build linux-libre with the newest GCC, since it can only add real security benefits? <roptat>I can't find a default value for timeout, max-silent-time it 3600 (1h) <lfam>roptat: It might be in the daemon? <lfam>What about set-build-options in (guix store) <roptat>it only sets the option if it was specified on the cli <Noisytoot>darth-cheney, emacs -ql <file> might work (-q makes it not load init.el, -l <file> makes it load <file>) <roptat>well, the weird thing is that for cuirass it's building ocaml, but really it's failing in a dependency, camlboot, which also has a cuirass spec and that built fine... <lfam>I don't think that setting the timeouts / silent times in package definitions has ever been effective on CI <darth-cheney>Noisytoot: Thanks. Loading without my normal init causes everything to work as expected. So now it's just a matter of hunting things down in my config... <rekado_>FWIW, I’m on c-u-f and blender starts up fine <nckx>lfam, roptat: No, that was a Hydra (real Hydra) thing. <nckx>(Not that real a Hydra. Dial it back.) <abralek>I hit this error: Unsafe AuthorizedKeysCommand "/gnu/store/5n6wigbpffpy6x453ckf35rrc0vi0lai-ldapsearch-sshkey-1.0/bin/ldapsearch-sshkey": bad ownership or modes for directory /gnu/store <abralek>Would it be a good idea to patch ssh daemon to trust /gnu/store directory? <abralek>AuthorizedKeysCommand says The program must be owned by root, not writable by group or others and specified by an absolute path. <nckx>It satisfies all those claims. <nckx>Why is it checking /gnu/store at all? <nckx>abralek: This is just typical noisy OpenBSD security theatre, but still, adding all of /gnu/store sounds risky. Anyone can write anything there, they just can't choose the permissions or prefix. <abralek>Not really, /gnu/store is owned by the root, the group is guixbuild and it has to have write access, hence drwxrwxr-t <abralek>nckx: Guix System makes it read only anyway afaik, same thing with foreign distros. Basically ssh daemon checks every directory up to the root for those permissions <nckx>Yes, so the documentation is wrong. <nckx>Or at least omits this crucial additional restriction. <theruran>how to get DrRacket working OK on Guix System? <nckx>Of course I don't blame SSH for not checking for read-only Linux bind mounts. <nckx>lfam: <we could do that> OK, that would require you (or anyone, but currently you) to configure the kernel with GCC 11/12/… too, because it directly affects the resulting .config and which options are presented in the UI. <nckx>And you currently use GCC 8.3 ☺ <lfam>Yeah, I've been working on the 5.15 configs in that manner <lfam>With Guix's toolchain, that is <lfam>We (one) could also re-do the 5.10 configs in a similar way <nckx>That would be safest, else building them with GCC 11+ would ‘unlock’ those options at Guix build time, and choose whatever upstream's default is, which we probably want to review at least once. <lfam>It would be a significant amount of configuring. I guess that it would be necessary to re-do the 5.10 configs on the 5.5 configs, since I think that was the last one that Mark did <lfam>IIUC the Git history correctly, we never had configs for 5.6, and then I started with 5.7 <lfam>Oh, maybe the last one by Mark was 5.4 <nckx>I (naively?) think it shouldn't ask too many questions, it's just the (scriptable) each-version thing that's tedious. I'm willing to take care of the GCC bump as long as I have your blessing. <nckx>But that'll be in nckx timeframes so not today. <lfam>I'd estimate that each kernel upgrade brings one or two hundred new questions. So going from 5.4 -> 5.10 would be a lot <lfam>I remember that doing 5.4 -> 5.7 was a lot of work <lfam>Like, my method would be to copy the 5.4 config to the 5.10 source tree and then do `make oldconfig` <lfam>I think it's fine to use a newer GCC <lfam>Something I've been wondering about (I promise it's related) is can we install mosh on the berlin server? <nckx>I meant the few questions added by having newer CC_HAS_FOO definitions. <nckx>Well, yes, but it's dead. <lfam>Maybe we have another fast server that I could test kernel builds on? <lfam>It's just that the typing latency is way too slow with berlin for me to do a lot of work there comfortably <nckx>Right, that might not have occurred to me. <lfam>bayfront is way faster than any other computer I have access to <lfam>I wonder how the latency is <nckx>It's fine from Europe. :shrugs apologetically: <lfam>berlin actually got better when I moved to NYC <nckx>There's also p9 ☺ Should work in theory. No idea how fast it is compared to x86. <lfam>But it's still kind of slow <nckx>(Cool! The moving. At least it sounds cool, mainly because it has the words ‘moved to NYC’ in it, which we are universally conditioned to find cool.) <ss2>nckx: thanks btw for early on. I was off to quick again and didn't thank yet. <nckx>But berlin's firewall blocks the UTP traffic that makes it so. <lfam>Thanks, it's a big and important change in my life <rekado_>please tell me what ports you need opened for mosh and I’ll open a ticket. <nckx>UDP 60000 -> 61000, doesn't mention if inclusive, so inclusive to be safe. <lfam>I'd guess that 100 ports would be enough :) ***TheOwlLady is now known as myrcy
*nckx bins the mail they were writing to rekado_. <lfam>It picks a port in that range for each connection over mosh <nckx>lfam: mosh picks, I don't know if we can/want to make it harder on ourselves. <nckx>It may well try them in order from 60000 now, but I assume it's no harder (or riskier) for the firewall admins to allow 1000 ports instead of 100. <lfam>It's lunch time for me now <nckx>Enjoy your fancy bagels or whatever. <nckx>…that was not deliberate. <podiki[m]>I updated stuff, added packages, did a crude hack of copying files to /tmp so they don't get compiled and copying them back... <podiki[m]>to now be boiled by the sanity-check and what I fear are very old pieces of code in upstream <nckx>Maybe, this is just a guess, set PYTHONPATH or GUIX_PYTHONPATH before 'check? Or first add some (display (getenv …))s to see what they are? <nckx>* before 'sanity-check, although 'check would still work of course. <nckx>KE0VVT: Whilst pretending to listen to conversation at dinner I think I figured out what's going on: did you install weechat whilst the installation itself was running? The installer starts cow-store before starting the installation, so you'd be installing weechat to the virtual temporary store overlay on /mnt (not /mnt/gnu/store! but one that transparently provides the live medium's /gnu/store with more space than you have RAM). When the installer finishes it <nckx>helpfully stops the cow-store service again, losing all changes made after it was started. <nckx>So the installer medium boots a fully functional live system, but then the installer UI mucks with very global state in such a way that it acts weird when it's running. <nckx>At least that's my hypothesis. <podiki[m]>nckx: guix_pythonpath didn't do anything, and at least one of the errors was that a module doesn't have an attribute (which I think means it found the module at least) <nckx>I assume you uppercased it in code, and yeah, I'm not a Python wizard, that sounds plausible. <nckx>Unless Python modules can extend base objects somehowe. <abralek>rekado_: I saw a mail thread about ldap authentication the other day. Are you still using that approach? Or maybe you found a better way to do pam? <podiki[m]>I worry it is that python-nautilus is very old and no longer matches what's in current graphene, etc <nckx>‘Let's check the homepage!’ —404. ‘…let's check the other homepage!’ —redirects to a totally different project with no explanation. <nckx>You're certainly right about that. <lilyp>GUIX_PYTHONPATH is a c-u-f thing, it's PYTHONPATH for us normies <lilyp>fair enough, I might have missed a byte <podiki[m]>guix refresh -l for python-nautilus: gnome-shell-extension-gsconnect@33 nextcloud-client@3.1.3 syncthing-gtk@0.9.4.4-1.c46fbd8 <podiki[m]>my god...tell me syncthing-gtk (which is why I care about python-nautilus) is using the wrong nautilus (should be the file browser one)...... *janneke resurrects cross-building of help2man (guix dependency) and nghttp2 (git-minimal dependency) on c-u-f <podiki[m]>so much time spent........ I guess I can send this diff to the bug list in case anyone else tries to tackle python-nautilus (which fails on c-u-f) <podiki[m]>yes it is the wrong nautilus (I think it wanted nautilus-python it is for nautilus the file manager integration) <janneke>now gdb-minimal still fails to cross-build for the (child)hurd <nckx>At least you learnt… well, you must have learnt something, probably, we hope. <podiki[m]>doesn't help fix python-nautilus on c-u-f, but I can send a patch to remove the input from syncthing-gtk <podiki[m]>leaving only wine standing between me and c-u-f completeness <podiki[m]>nckx: I'll submit that diff I pasted earlier, since it has new package defs and my hacky workaround for python-nautilus, but I'll take a break from trying to fix it <nckx>I'm kind of relieved that syncthing-gtk doesn't require a clearly unmaintained package last released in 2016. <nckx>There's also CLI if you really want the CL part. <nckx>If nmtui is just too glitzy and modern for you. <nckx>M6piz7wk[m]: Does ‘iw list’ see it? <nckx>Assuming you have iw installed. <nckx>Or can install it without wireless fi. <nckx>The kernel is not seeing your device. <nckx>Considering I know why and (honestly) can't help debug it, this is probably for another channel. I'm sorry though. I honestly thought you'd be OK. <nckx>Does not sound glitchy, merely unsupported. <nckx>I guess using the devil's installer still requires more dancing with him later and it's not automagical. <nckx>Yeah that's not a feature. *M6piz7wk[m] goes in forsaken then <nckx>Might also be firmware-related. <podiki[m]>or make sure you've pulled and system reconfigure; or else when c-u-f hits newer mesa may resolve that <podiki[m]>other things depending on a 2016 python-nautilus is perhaps worrisome, but I'll just send the work in <nckx>nautilus-python, which you implied was a different project? Maybe also mistake? <podiki[m]>again I feel like it is for nautlius the file manager, but need to track down the source... <nckx>M6piz7wk[m]: Inside voice please, some Guixers are sleeping. Really, if I had a clue I'd try to help. <podiki[m]>...yeah think it is too, maybe can just remove it <KE0VVT>nckx: The installer was running, doing all of its boring downloading stuff, yes. <podiki[m]>should that be one patch removing as input to all affected? and the package itself? <nckx>Sorry you wasted so much time on it, but you still found a real (and arguably far sneakier) bug in multiple packages. <KE0VVT>nckx: I thought it might have been running the intaller. Now I have an installed system for playing on. <nckx>KE0VVT: Yeah… so at the end the installer (programme) does the low-level equivalent of ‘uninstalling’ everything that was installed during the installation, no matter who did it, assuming that it was the only thing creating new /gnu/store items. <KE0VVT>nckx: Would I be able to install WeeChat first, and then run the installer, and usse WeeChat while the intaller is running? <nckx>This assumption usually works, but it's a bit ugly, and arguably unreasonable. <nckx>I'm going to report this as a bug. <KE0VVT>What the... I search "keyboard" in Overview and get No Results. <nckx>I don't know what Overview is. <KE0VVT>Hm, this version of GNOME does not have the setting for enabling the Compose key. <nckx>M6piz7wk[m]: One thing I'd add to that link I posted is to run the daemon with --disable-chroot (sic, no irony allowed) <nckx>KE0VVT: If you use keyboard-layout in your system configuration you can add (e.g.) "compose:102" to the list of #:options. <Noisytoot>KE0VVT, Maybe it's in GNOME Tweaks (which needs to be installed seperately) <nckx>That's a eurocentric value but I'm sure there are others. <KE0VVT>nckx: Will it put Compose on Caps Lock? <nckx>Not this, 102 is the key next to left shift on ANSI (‘big-ass’) Enter keyboards. <nckx>I'm sure there's a value for what you want. <nckx>GNOME just exposes these values as pretty pixels, it's just XKB under the hood, nothing new. <nckx>less $(guix build xkeyboard-config)/share/X11/xkb/rules/base.lst <KE0VVT>nckx: xkb? Is this not using Wayland? And I thought GNOME used IBus. <nckx>I doubt very much that it's using Wayland. <KE0VVT>Hm. GNOME About is broken. OS name: Unknown. Device name: [blank]. <nckx>Still, bug reports welcome! <KE0VVT>nckx: I've been using Wayland all the time, what's unusable about it? *dstolfa_ notes that he has yet to see a system where GNOME is not broken <nckx>KE0VVT: Nothing. I use it as we speak. That was about GNOME About. <KE0VVT>dstolfa_: Not broken on Fedora, unless you are using a subversive version of "broken". <nckx>If that's the level of bug that catches your attention first we're doing better than I expected. <KE0VVT>nckx: Oh yes, this system works way better than it did when I last used it. It even had Polari! <dstolfa_>KE0VVT: i've had GNOME stop responding on fedora multiple times... <dstolfa_>and i've had it misbehave very creatively on RHEL and Ubuntu too :P *dstolfa_ absolutely detests GNOME, but he detests the alternatives even more somehow <dstolfa_>it doesn't work correctly with thunderbolt docking :P <nckx>You need to understand that whilst GNOME About missing some fields is a legitimate bug that we'll gladly help fixing, it is not the kind of thing that people will *care* about here. Not really. <dstolfa_>KE0VVT: don't get me wrong, it's the best option out there for free software, i just still hate it :D <nckx>If you think that kind of polish is important (valid viewpoint), you will have a hard time. <KE0VVT>nckx: I know we're all nerds here, I just try to dogfood for when regular users want to use GNU/Linux. <KE0VVT>nckx: I'm just trying it, I'm not migrating. I just reinstalled after KDE borked my GNOME. <nckx>Well, not just that, but there are plenty of bigger fires still, even in the coming GNOME 40 on c-u-f. <nckx>I'm not saying nerds don't care about details. Hahaha. Haha. *nckx goes to tweak the pixel spacing of their swaybar emojos. <KE0VVT>nckx: I like Sway, but it can't type Japanese. <KE0VVT>I'm such a picky pain, aren't I? <KE0VVT>I have this beautiful GNOME desktop running smoothly on a barely-maintained OS, and yet I complain. <dstolfa_>i like sway too, but last time i used i3 i got pain in my hand from the keybindings, and i legitimately couldn't come up with better ones than the defaults :( <KE0VVT>dstolfa_: I tried remapping i3 to GNOME keybindings, but that was tricky. <nckx>It's OK to be picky, just don't pick pot shots :) It's trivial to fill 50 lines of #guix scrollback with ‘and this is broken, and this doesn't work, and this is bad, and this sucks’ and have all points be valid. It's just… we know. <nckx>Not talking about you specifically BTW. <KE0VVT>nckx: And then the Nix people come and stick their tongues out. <nckx>But if gripes aren't followed by ‘…and here's what I found out about the cause’ or ‘…and here's a patch to fix it’ (doesn't matter if it needs work!), well, such people tend not to integrate well. <nckx>I'm a bit grumpy, apologies. Again, not aimed specifically at you. <KE0VVT>Keep in mind, I'm also angry at myself for not having the skill to tackle the problems. <nckx>KE0VVT: Are you a ‘Nix person’? I mean I know who you are, but I haven't been following Nix much lately. <dstolfa_>nckx: hope whatever is making you grumpy gets resolved soon! <nckx>Distro integration is really hard and then people keep releasing new software. :) <KE0VVT>nckx: No. I have never used Nix. But whenever Nix people bring up Nix and I said, "Oh, I know about that, I've used Guix..." they laughed and condescended on how primitive Guix is. <nckx>dstolfa_: Ta. It will, I'm sure. <KE0VVT>nckx: Packaging is hard, let alone integration. I can't even package Linux for Fedora. :-( <podiki[m]>after that I can bug people to restart i686 CI jobs to see if wine will finally build <dstolfa_>KE0VVT: packaging the kernel correctly is non-trivial <dstolfa_>there are *tons* of configuration options and it requires a lot of testing, depends on the toolchain, etc <nckx>KE0VVT: <on how primitive> That's sad. I may not have been paying attention the past year, but I *know* Nix. It's great, but that attitude is extremely misplaced. There are plenty of disgusting skeletons in Nix's closet that Guix doesn't share, some of them even load-bearing. <dstolfa_>well, if firefox is packaged wrong, people complain that their browser doesn't work. when their linux is packaged wrong, they don't boot :P <KE0VVT>nckx: And the GNU turns people off, which is a shame. People are just too lazy to add their own repos, I guess. <civodul>roptat: yay, congrats on the 32-bit ocamlboot! <sneek>civodul, you have 1 message! <sneek>civodul, apteryx says: re gnome 40 vs 41; the later is supposed to be some kind of improvement/refinement of 40, so I'd expect that the components from either mostly work together (and they seem to for the most part from what I can see). <KE0VVT>nckx: Is it true that Nix package definitions contain shell and Awk? <roptat>civodul, thanks, it was long overdue ^^' <dstolfa_>... and escapes for strings that contain that shell and awk :) <KE0VVT>Nothing spectacular in 41. 40 is just fine. *dstolfa_ looked at nix's source a few times and was left horrified <jackhill>wooo, my main profile can finally built fully on core-updates-frozen. Time to switch over my workstation I guess :) <KE0VVT>dstolfa_: So I'm spoiled by the Lisp. <nckx>Everything between '' is shell code. <nckx>(runHook is not Nix language here.) <rekado_>abralek: I’ll need more context to answer. If you mean Guix System with ldap accounts: I did have some success, but haven’t used it in years. <KE0VVT>nckx: Wow, that is very different from the Guix packages I see. I can manipulate everything with S-expressions. <jackhill>woo indeed. Now I get to see if the software actually works in addition to building :) Also, other folks probably depend on different software than I do, so I'll hopefully have time and motivation to help them too. <ss2>nckx: looking at that.. I was just about to say that I whished packaging for Guix would be easier.. <rekado_>easier … by gluing together stringly typed snippets of shell code? <jackhill>of course aacgain isn't packaged for guix… something for the todo list! <nckx>Not a deliberate choice (you can guess my search strategy by the ‘aa’ bit :) but yes! <ss2>no, not really. :) I'm just slightly confused with my own understanding of Guix packaging. <podiki[m]>civodul: I think you had commented/fixed the python-graphene stuff earlier, I've just submitted a patch to remove python-nautilus which was part of that discussion (turns out it is the wrong nautilus) <sailorCat>Hi, I need help with the bluetooth service. I've added it to config.scm as '(bluetooth-service #:auto-enable? #t)' then reconfigure the system,and when I try to 'herd start bluetoot' I've got an error. There is my log https://pastebin.com/Aq2CP1PN <nckx>Do you have dbus-service? (Possibly included in a default list such as %desktop-services). <nckx>I don't but I think it should be included. Hm. <sailorCat>but herd: service 'dbus-service' could not be found *janneke fixes (cross-)building gdb-minimal for the Hurd on c-u-f <nckx>sailorCat: And does ‘pgrep dbus-daemon’ return PIDs? Here it returns 2, not sure if that matters. <KE0VVT>OK, so (keyboard-layout (keyboard-layout "gb")); how to add compose to this? <nckx>sailorCat: It won't show up in herd. I'm not very familiar with D-Bus but it should run as your user, not system-wide (so no, I don't know what the system-wide ‘dbus-service’ truly does; probably just makes a warm bed for dbus). <nckx>(keyboard-layout (keyboard-layout "gb" #:options '("compose:caps"))) ; KE0VVT <janneke>grmbl, why does paste.debian.net think my patch is spam? <nckx>sailorCat: Damn, I was hoping dbus wasn't running which would be far easier to debug ☺ <nckx>bluetooth ‘just works’ here, always has: Status of bluetooth: It is started. <nckx>KE0VVT: This is extensively documented in (guix)Keyboard Layout. <jpoiret>dbus-root-service is the system dbus, while your user dbus service should be started by your desktop manager <jpoiret>one thing which could not work is when you start your window manager through shell <sailorCat>I have a dbus-daemon from by user and from gdm *nckx doesn't use GDM either, what are they even doing here. ‘Support.’ As if. <KE0VVT>Does "guix system reconfigure" need to be sudone? <nckx>sailorCat: I have one for nckx and one for message+ so it's probably not dbus. Which, again, sucks, because it would be trivial to start. <jpoiret>weird that this error pops up though <rekado_>KE0VVT: you can also do “guix system build” first and only do the “reconfigure” with sudo. <jpoiret>the dbus service shepherd name is "dbus-system" <jpoiret>can you check with `herd status dbus-system` that it's properly running? also using `dbus-monitor --system` as root might help <nckx>jpoiret: <dbus-root-service is> Ah, thanks. <dbus-system> Of course, because what else would ‘dbus-service’ create 😒 Now we can keep track of 4 different names which is 4 times the fun. <rekado_>are there any more patches y’all want me to apply today? My list only looks like this: '(52009) <sailorCat>When I've tryied to launch 'libexec/bluetooth/bluetoothd' manually I've got 'D-Bus setup failed: Connection ":1.125" is not allowed to own the service "org.bluez" due to security policies in the configuration file'. Does it ring the bell? <nckx>rekado_: <guix system build> That is highly… true, but what kind of use case would that address? <jpoiret>heh, if you don't know how dbus operates it's just one mystery after another (i'm looking at the me from before c-u-f sprint) <KE0VVT>I can see why that Arch user switched to Guix. This is slick. <nckx>sailorCat: Are you in the lp group? (Yes, ‘line printer’, aren't historical Unix names fun.) <jackhill>jpoiret: I'd totally take your dbus and other desktop technologies course! <KE0VVT>I wouldn't mind a line printer and a teleprinter terminal. <jpoiret>bluetoothd should be launched as root iirc <jpoiret>jackhill: oho, i am but a simpleton trying to make sense of the behemoths that are (e)logind/dbus/polkit and friends <nckx>KE0VVT: Seeing a teletype actually print the UNIX log-in & shell prompt on paper is… it makes you feel things. *nckx felt things anyway. *nckx totally a real human. <sailorCat>nckx: I've added myself to the lp group recently, remind me please how to apply it without a reboot? <KE0VVT>nckx: That's my ideal date, a trip to a computing museum. <jpoiret>sailorCat: are you running the latest guix? <jpoiret>i haven't been on master in a while but bluetooth should work out of the box there, especially without polkit/dbus problems since they'd be mostly the same for everyone <KE0VVT>singpolyma: What's wrong with that? How else is somebody going to get their hands on a PDP-10? <KE0VVT>Does it re-download everything? I'm just changing my keyboard. <Inline>is that because the mobo has no adapters on it ? <Inline>wth, even my laptop can bluetooth <nckx>KE0VVT: If you pulled in the mean time (and you should) it will update the whole system. <nckx>So it's for a good cause. <jpoiret>you can just (with-ellipsis ::: (...)) if they're too costly for you <nckx>Here … just copy-paste this one. <jpoiret>anyone else on c-u-f having broken hide/show password icon in gdm? <jpoiret>i compiled the example gtk password prompt with gtk4 and it works properly, so I'm puzzled a bit <rekado_>nckx: oh, I don’t know. Some people prefer to only bother the root user when it is actually needed. <rekado_>I do that sometimes when I expect the build to take a long time. I just build first and when the only remaining work is to switch to the system and update grub I’ll type my password. <nckx>Plus, you reminded me to file a tangentially related bug :) <nckx>Well, not bug, but problem. <rekado_>I always enjoyed visiting the “Museum fur Verkehr und Technik” (“new” name since 96 is “Deutsches Technikmuseum”) in Berlin. They have a replica of the Zuse Z1, and a working copy of one of the newer Z* machines. <rekado_>I don’t recall seeing any teletypes there, though <nckx>Don't they also have a YP-1? Heard that from someone. They sat on it. I was jealous. Not positive which museum it was. ***TheOwlLady is now known as myrcy
<rekado_>vivien: re 52009: would it be possible to patch the mkdir invocations instead of wrapping? Or perhaps to use wrap-script instead of wrap-program? *apteryx is now running their profile using core-updates-frozen <rekado_>nckx: I opened a ticket to open the ports for mosh <apteryx>the whole system, or just user profile? <nckx>How grumpy are they generally about such requests? Are they something we should minimise, or conversely take more advantage of? <rekado_>apteryx: I just reconfigured as well, so … I’ll try rebooting tomorrow <rekado_>nckx: they aren’t grumpy about requests, generally. Just kinda slow, especially when there are some roundtrips to confirm things. <apteryx>worst case you can boot the N-1 generation :-) I guess it should be fine (I have yet to try myself but others have shared encouraging reports) <rekado_>booting older generations is a bit tricky because early boot is invisible on this librem 13… <rekado_>but it’s not like blindly editing settings in the BIOS, something I remember I had to do much more often than it would seem sensible in my youth <nckx>The other thing that would be nice to have on berlin is IPv6, via an HE tunnel, which is also blocked somewhere at the network level. I don't know if we discussed this here previously (didn't make notes…). <nckx>That's clear, that's good. *nckx makes a note of *that*. <rekado_>AFAIU it’s on somebody’s TODO list since forever, but it would require some switch upgrades that somebody else would need to do… <rekado_>a couple of people here are pretty unhappy about this while others have learned to incorporate a shrug in their daily choreography. <jlicht>This is a totally OT question, but has anyone been able to run guix on a Tesla? Would love a photograph of that (e.g. guix pull outpu?) for a short presentation I'm working on. <rekado_>tesla coil or that computer on wheels? <nckx>I prejudicially assumed those things would be Tivoised/DRM'd out of the wazoo. <nckx>Now I'm forced to look up whether they run Gentoo. <jlicht>roptat: yeah had that running as well :D <jlicht>nckx: They probably are; not that I am not asking someone to break DRM or anything terrible like that. Just, if they happen to come across a machine that somehow would be able to run guix, I'd be interested in a picture ;) <nckx>I'd break it if I had one. <nckx>If anyone wants to sponsor this, call me. <singpolyma>I know an activist with one, but they have been a bit wary of hacking it too hard yet, because it could be a very expensive brick <sailorCat>Ok. I've restarted the dbus-system service and everything hangs (I've logged out and nothing reacts on my keyboard). So, power off/on and bluetooth works. <jlicht>Does c.u.f. Gnome finally have working bluetooth in the settings GUI, by the way? <sailorCat>I'm not sure about the Gnome. But blueman-manager certainly works 