<zimoun>apteryx: about blog post, LGTM. :-) (I was waiting it as inspiration for the GuixHPC one ;-)). Aside, I do not know if it worth to mention the “new” Cuirass 1.0 and the “new” translation tooling. <nckx>Not all translations in progress are advertised; only those considered sufficiently complete. <zimoun>nckx: thanks. For Dutch, it is 92% of the manual, right? <nckx>I'd be redonkulously surprised. I don't think a Dutch translation *exists*. <nckx>Oh, the 92% is for Guix (the software) itself. <zimoun>ok, now make sense. Sorry for the noise. Fancy interface. :-) <ss2>wooo, up and running again! <bone-baboon>ss2: To get up and running you pulled that commit and then reconfigured? Now you are not getting that ssh error message? <ss2>the weird thing was, that, the guix-daemon was offloading while reconfiguring and downgrading. <ss2>but I couldn't as a user. <ss2>Sadly, I through away that checkout I had there. I switched to previous generation, checked out, then downgraded. <ss2>Just noticed this while writing a bug report. <rndd>is there any example of packaged racket code ? <ss2>anyway, I'll pull again. At least the host is working again. <ss2>hm, how do I force to offload a build? <ss2>this is even weirder now. The current pull as user failed, but as root it didn't, then I rolled pull and system config, rebooted, and the root's current pull fails now. ***stikonas_ is now known as stikonas
<roptat>sneek, later tell civodul the warnings are also all present in the English version, so we should fix it too, but at this stage I think it's too late for version-1.3.0 and we should simply ignore the warnings, wdyt? <derivates>Hello, how can I solve this issue: guix system: error: the group `guixbuild' specified in `build-users-group' does not exist <derivates>should i add that as a user? probably not right? that's some stuff for guix-daemon <vagrantc>is there a way to specify multiple bootloaders? in short, i want to use u-boot's EFI implementation to load grub-efi ... <vagrantc>but it *seems* to my limited eye i can either do u-boot-boot-loader *or* grub-efi ... not both <vagrantc>my workaround was to install one generation with u-boot, and then another with grub-efi, but this really just uses whatever last version of u-boot happens to be written to boot media <lfam>It's on a distro besides Guix System, right? <lfam>They did mention a service, which leans towards Guix System... it's surprising if the guixbuild group is missing on Guix System <lfam>I got the Macchiatobin working with GRUB on UEFI, for Debian at least <vagrantc>haven't yet really tested it, but i have a workaround patch for linux-libre@5.12 for the pinebook-pro ... basically applying the same patch from @5.10 and @5.11 <lfam>And the GbE NIC works with linux-libre, which is the main thing I was worried about <lfam>We also (as a project) placed an order for some Honeycombs <vagrantc>lfam: should i CC you on an update once i test it or should i just push it? it'll regenerate the tarballs, which i somewhat dread :) <mekeor[m]>hey guix! is it possible to specify a file://-path (instead of a https://-uri) to point to a guix-channel in ~/.config/guix/channels.scm? <lfam>I was thinking maybe we should restrict application of this patch to relevant systems. That is, to aarch64 <vagrantc>lfam: still think i should send you a couple mustangs? 8-core, 16GB ram, sata ... <lfam>Let's wait and see how things are going with the Honeycombs in a couple weeks <vagrantc>lfam: that would be fine by me, though not sure how to restrict by arch <lfam>Let me try to find an example <vagrantc>i mean, i could take a stab at it, but the sheer amount of time to test that it works is intimidating :) <vagrantc>probably should also rename that one-liner patch <vagrantc>so someone with greater confidence in applying it mgith be a better use of everyone's time :) *vagrantc admittedly did the last kernel build by disabling the deblobbing *gasp* <lfam>Time is the most precious thing we have <vagrantc>oh, since using u-boot's EFI implementation uses u-boot's device-tree ... i was going to test by patching u-boot instead, which is a much faster build :) <vagrantc>though gets into weird issues with device-tree skew if the kernel version and u-boot device tree drift too much <vagrantc>but was pretty cool to see the guix logo from grub on the pinebook pro :) *lfam has to re-grok (gnu packages linux) every time <lfam>I don't understand why the make-linux-libre procedure isn't used (instead we use make-linux-libre* IIUC) <vagrantc>yeah, i get a little lost with function names that are nearly identical <vagrantc>my very nice mustang guix installation does not appear to be loading grub. <lfam>The things you find while grepping: "NOTE: Applying these patches is order-dependent!" <vagrantc>ok, manually loading the appropriate grub from the EFI shell worked ... *vagrantc feels like an oafish ogre bumbling around in EFI shell <lfam>Well I don't know how to accomplish what I suggested <lfam>So it's fine to keep the status quo <derivates>lfam: sorry, i went back to another build! don't know what the issue was but i reverted to a previous commit of my build. I am using GNU GUIX Distro <lfam>Huh, I don't know what went wrong derivates <lfam>That stuff should all be handled automatically on Guix System <apteryx>I'll start the release cutting machinery (which is not great, building stuff strictly in series IIUC) <vagrantc>lfam: i had figured out how to do it for linux-libre-arm64-generic at one point, but i've been going for the regular linux-libre package lately... <roptat>apteryx, did you run "make download-po"? <roptat>yes please (and run "make" just to be sure the manual po files are OK) <roptat>(oh, probably make release will check that? not sure) <apteryx>yeah, I think so, although it's not bad to run make before <apteryx>the doc-po-update target is now combined with download-po, right? <nabataeus>lfam: I'm installing from live USB, I get locale errors when I try to boot <nabataeus>the qemu image isn't working it gives a kernel panic with some error code <lfam>nabataeus: Locale problems shouldn't block booting. Can you be more specific? <nabataeus>lfam: well I don't really know because it gives a "Can't set locale" error on startup and it just loops constantly printing it without outputting trace or anything <lfam>The stable version, meaning you used the 1.2.0 installer image? <lfam>What kind of computer are you using? <lfam>Also, I know you said that you don't want to use QEMU, but I tested it anyways. I downloaded the QEMU image and followed the instructions that are linked to from the download page. It works fine for me on an x86_64 computer <lfam>Maybe you forgot to decompress it? <nabataeus>I forgot that I didn't have AMD-V set in BIOS <nabataeus>regardless though, what do you mean what kind of computer? <lfam>Like, 64-bit Intel / AMD, ARM, etc? <lfam>Just the type of processor <lfam>I'm not sure what happened with the system that you tried to install :/ <lfam>It sounds like maybe it wasn't configured correctly, but it's hard to debug if you can't boot <apteryx>it's the copy on write native format of QEMU <nabataeus>do I have to decompress it or do I just boot the image? <apteryx>roptat: by the way civodul was mentioning we should perhaps mention the translation work that went into 1.3.0; is there something particularly noteworthy you'd like mentioned? <apteryx>(for the web site release blog post) *vagrantc pouts at building /gnu/store/fsgv20vzd8rwyr84mj5x9079fb1gpnc4-linux-libre-5.11.19-guix.tar.xz.drv <lfam>nabataeus: No, you don't have to decompres the 1.3.0rc2 image that apteryx suggested. We decided to stop compressing it because it caused a lot of "forgot to decompress" bug reports :) <vagrantc>oh, i wanted to build linux-libre@5.12 anyways... so ... :) <vagrantc>hmmmm... wonder what it would take to build patched .dtb files from devicetree-rebasing and then passing those device-trees in from extlinux instead of the in-kernel ones <nabataeus>lfam: ah, well my issue in the vm wasn't because of the compression really, I noticed the format <lfam>1.3.0rc2 is better anyways :) <nabataeus>I don't think guix supports my keyboard drivers though <nabataeus>I've encountered a lot of issues with locales on my keyboard on previous systems <nabataeus>I'm using a really old dell office keyboard that I got from my father's basement <lfam>I guess I didn't even know that keyboard drivers could be troublesome <lfam>We use the linux-libre kernel, which removes non-free / proprietary drivers from the kernel <nabataeus>unfortunately as well, my AMD Radeon is also very old, it's a proprietary R5 M240 <nabataeus>on the other hand though what are some decent distributions you recommend? I'm mostly intrigued by the package manager nonetheless <nabataeus>so I guess I'll install it alongside some other system <xelxebar>nabataeus: FWIW, you (or anybody for that matter) could technically mantain a channel that contains stuff not acceptable for the main channel. <xelxebar>I'm sure there's information online about how to build a custom kernel with guix or something. <apteryx>roptat: the messages.mo files should be ignored, perhaps? <vagrantc>is there a way to get grub-efi to install to /boot/efi/EFI/boot/bootaa64.efi instead of /boot/efi/EFI/Guix/grubaa64.efi ? <roptat>apteryx, yes, ignore the .mo files <roptat>otherwise, add the new po files, they're additional translations (maybe add them to NEWS too :)) <roptat>apteryx, regarding translation, I think it's worth mentionning the new section of the manual that can help get translated, otherwise the current NEWS file looks good for translations <vagrantc>does guix system init mess with EFI variables? <vagrantc>i think that might be what borked my EFI <apteryx>roptat: ah, the new section is only on the master branch I think <apteryx>it's useful! I could follow it to commit the new translation files, thank you. <apteryx>I've cross-referenced in from release.org *vagrantc struggles to not see *.org as a domain name *apteryx now good for ~5 h long 'make release' <apteryx>roptat: mhh, have you ever seen this: Makefile.am: error: 'version.texi', included in 'doc/guix.fa.texi', also included in 'doc/guix.texi' <roptat>oh, there's an issue with fa it seems <roptat>maybe it didn't translate "version.texi" to "version.fa.texi" <roptat>can you add the translation to po/doc/guix-manual.fa.po? <apteryx>as in, sed 's/version.texi/version.fa.texi/' -i po/doc/guix-manual.fa.po ? <roptat>no, because you can't modify msgid <roptat>set the msgstr related to "version.texi" to "version-fa.texi" <roptat>and the one related to "contributing.texi" to "contributing.fa.texi", it's also missing <roptat>also, do the same thing for version.texi in guix-manual.it.po <roptat>really? I don't seem to have the same files <apteryx>did you git pull on version-1.3.0? I had already pushed the files <roptat>I was looking at the repo behind weblate <apteryx>OK, not sure about that, I ran 'make download-po' perhaps an hour ago <apteryx>is the translation repo actively changing at the moment? (I thought it was frozen) <roptat>ah, I fixed these files and forced them into the weblate repo at that time, but you probably cloned it before <roptat>no, we're good, I only pushed small fixes that prevented me from building them, to check the parenthesis warnings ludo was talking about <roptat>before pushing the changes, it's important to run make once, to make sure everything builds, and you don't commit something broken <apteryx>is there something I need to run to fix the build system? autoreconf -f is still complaining <roptat>hm... remove the translated texi files and run bootstrap again <roptat>it's important to run bootstrap and not just autoreconf, because it first creates dummy files so autoreconf doesn't complain, if they don't exist yet <apteryx>right, I had run ./bootstrap already :-) <apteryx>retrying after: find -name *-??.texi -delete <apteryx>ah you mean after clearing the files <apteryx>more like: find -name '*.??.texi' -delete, actually <apteryx>the previous errors have been moved into: ./doc/guix.fa.texi:16: @include: could not find version.fa.texi <roptat>right, that should be taken care of by bootstrap <roptat>otherwise, "cp doc/version.texi doc/version.fa.texi" <roptat>going to bed now, I hope you'll manage, otherwise, let's talk tomorrow :) <apteryx>you are correct, I had to run bootstrap right after clearing translated texis <apteryx>ah, the bootstrap script creates @include directive which uses 'version-fa.texi', not 'version.fa.texi' <apteryx>seems more common to use .LANG.texi, so I'll adjust the bootstrap script. <apteryx>bah, it just keeps coming: ./doc/guix.it.texi:16: @include: could not find version.it.po <vagrantc>the v1.3.0 seems to have a bit of cruft in the annotation: v# v1.3.0 ***iyzsong-- is now known as iyzsong-w
<drakonis>hmm, is it viable to have parsers for guix configs written in another syntax? <jackhill>That's the beauty of having everying embedded in a programming language. As long as you produce the right datastructures at the end. <drakonis>was having a discussion on the matter elsewhre <jackhill>if I remember correctly, there was a proof of concept JSON manifest support somewhere <jackhill>drakonis: cool, did y'all come to a similar view <jackhill>whether or not we'd want to include support in guix proper for any particular format is another question. <drakonis>s-exps are simple, but it is always interesting to be able to parse configs written in other syntax <jackhill>and there's also wisp, s-exps without the parens :) <lfam>Has anybody got a systemd service for the Cuirass remote worker? <lfam>I will "take my answer off the air" <efraim>was that one of the GSoC options? <efraim>apparently stow doesn't like working on symlinks <efraim>* taking the symlinks and symlinking them to elsewhere <drakonis>someone actually went and wrote guix/nix in racket <drakonis>this seems to be strongly racket centric <drakonis>ah, wait, it does other package types too. <abralek>I came across with a case where I want to build a VM with an extra drive. Basically I want to build a VM with imap server and a maildir dataset for testing purposes. I have found this guys gnu/system/vm.scm:<virtual-machine> but it doesn't have an option to propagate qemu options to virtual-machine-compiler <abralek>I would like to ask would it be ok to add extra-options to it for such a case? Or there is better way to do it? <sneek>civodul, you have 1 message! <sneek>civodul, roptat says: the warnings are also all present in the English version, so we should fix it too, but at this stage I think it's too late for version-1.3.0 and we should simply ignore the warnings, wdyt? <civodul>roptat: sounds good, we'll take care of it later! <PurpleSym>Is it somehow possible to pass a command to `guix system container`? I would like to run a single program in an OS container and retrieve its exit status/stdout/stderr for system integration tests. <civodul>PurpleSym: no, you would need to add a service/activation snippet to the OS config that runs the command <PurpleSym>I’m assuming that’s because the system is not completely initialized until shepherd ran all activation services? <PurpleSym>(i.e. manually invoking call-with-container is not going to help either?) <civodul>you need to first be sure you need a full-blown Guix System, which is what 'guix system container' gives <civodul>if you're code has to run after some services have been started, then you probably need to make it a shepherd service <PurpleSym>I’m testing a PAM module, which needs a running LDAP server and some configuration, so `guix environment` is probably not going to help here. <PurpleSym>Hm, maybe I can get results via a file system shared with the host. <civodul>PurpleSym: yes, you could use a VM with a 9p mount, like we do for system tests ***zap1 is now known as zzappie
<civodul>mothacehe: did you see the fixes that landed in Guile 3.0.7? finalizer pipe and all *civodul was pretty excited :-) <ss2>hey civodul! I just replied to <ss2>entered too quickly^^ <brendyyn>has anyone looked at Maxim's qtbase 6 patch? <civodul>brendyyn: i haven't, but it looks like something we want <brendyyn>civodul: if you think the qtbase rename is ok, then could you maybe push that so that it doesnt cause lots of conflicts with later patches? unless you think thats not an issue <brendyyn>since it edits a large number of packages <civodul>brendyyn: i haven't looked at it so didn't know about the rename <civodul>let's check that with Maxim after the release :-) <ss2>With the same checkout I provided? <pkill9>basically if you put a package source in a specified directory, guix will rebuild the software with that source when you run it if it changed <civodul>mothacehe: i had overlooked that one, my bad! <mroh>civodul: I will take a look at the configure-flags for libmediainfo (which seems to break mediainfo). Thx for review! <zimoun>civodul: about exception, I am not sure to memorize your answer yesterday on #guile. For instroducing new exception (basically for importers), is it ok to use the Guile 3 API? Or should the code still remain on catch/throw? <zimoun>another question related to Julia update, is it possible to apply patches located in source, some with the option “-p1” and others with “-p2”? <apteryx>roptat: I made a few commits locally that improved things a bit, but I'm still stuck on the translations; for example, 'make doc/guix.it.info' now gives './doc/guix.it.texi:16: @include: could not find version.it.po' <bdju>I found a reproducible (on my end) crash in qutebrowser but I think I'm lacking debug symbols to get good info out of gdb. I'm not sure which packages I need a debug output added for. probably qutebrowser itself, but maybe certain dependencies <civodul>apteryx: doesn't ./bootstrap generate those? <apteryx>it was generating version-LL.texi files; fixed that so that to 'version.LL.texi' files <civodul>zimoun: no it's not OK yet to use the Guile 3 exception API; use SRFI-34 or 'catch' <apteryx>what it generates are doc/guix.LL.texi, that refered to version-LL.texi <apteryx>not sure how that used to work, mmh. <civodul>hmm "make" on version-1.3.0 works for me <apteryx>have you pulled? there were translation updates <apteryx>does 'make doc/guix.it.info' succeed? <zimoun>civodul: thanks. Ah it was this SRFI-34 I was looking for. My memories were saying SRFI-64 and it does not make sense. :-) <civodul>apteryx: "rm -f doc/guix.it.{info,texi} doc/contributing.it.texi && make -j5" works *civodul tries "guix build -f doc/build.scm" <efraim>can I use (guix utils) in (guix build go-build-system)? <roptat>apteryx, it's "version-it.texi", not "version.it.texi", very important as automake cuts at the first dot to find the extension iirc <roptat>(so you'll have to fix the po file) <apteryx>roptat: 'who' generates the 'version-LL.texi' files? <roptat>not sure exactly, there's something in automake or texinfo that reads the file and generates them <civodul>apteryx: try "make doc/version.texi" maybe <civodul>31 ./doc/guix.it.texi:16: @include: could not find version.texi <civodul>there's an Automake-generated rule for that <apteryx>yes, that comes from the @include directive generated by the bootstrap script <civodul>yes, but anyway, you're missing doc/version.texi <apteryx>that progressed onto: ./doc/guix.it.texi:13178: @include: could not find os-config-bare-bones.texi <civodul>there's a makefile rule for that, too :-) <civodul>perhaps we got the dependencies wrong <apteryx>I fixed that locally yesterday by adding a prerequisite on it <apteryx>after that's done, I'm back to the original problem I faced yesterday: Makefile.am: error: 'version.texi', included in 'doc/guix.it.texi', also included in 'doc/guix.texi' <roptat>apteryx, there needs to be a translation for "version.texi" in po/doc/guix-manual.it.po <apteryx>I don't understand why that's not reproducible on your side though. There must be some cluft in my tree that 'git clean -xfdd' doesn't get rid of? <roptat>did you run make download-po again? <apteryx>no, I'm just using what's in the version-1.3.0 branch already <roptat>(nothing changed in the repo since I went to bed btw) <apteryx>IIRC we discussed running download-po again yesterday but decided it wasn't necessary <roptat>just download-po, that'll make your life easier, the content of the weblate repo is clean right now <roptat>then git clean and restart at bootstrap, and it should work way better <apteryx>that still doesn't explain why civodul is not able to reproduce what I'm seeing :-/ <civodul>i didn't start from a fresh clone and this whole process is stateful :-/ <apteryx>on my side it's reproducible after 'git clean -xfdd' or in a new clone. I'll 'make download-po' :-) <civodul>"guix build -f doc/build.scm --cores=1" passes though <civodul>and it's close to the "ground truth" in my view <apteryx>Autoconf question: when are AC_CONFIG_FILES files generated? I thought it should be at 'configure' time <apteryx>but 'scripts/guix' prooves otherwise <civodul>scripts/guix is generated via a makefile rule <civodul>the files in AC_CONFIG_FILES are generated at configure time, by the config.status script <civodul>don't worry too much about it though ;-) <apteryx>yeah, I'd like to understand if me adding a bunch of guards (pre-requisites) in Makefile.am for 'pre-inst-env' is pertinent or not <civodul>BTW, we usually arrange to never delete tags from upstream since they might have been mirrored in the meantime <civodul>(for the release, i'd typically push tags once "make release" has completed) <roptat>apteryx, on a clean repo (version-1.3.0 on the latest commit with no local change and no additional local commit), "make download-po", commit the changes, git clean -xfdd and make passed on my machine <apteryx>roptat: good. I'm at the 'make' step <apteryx>that said, we have nice artwork with 1.3.0 ;-). I shouldn't have pushed that tag in the first place. <apteryx>I can create a new v1.3.1 tag after release just to be sure people are using what's intended <civodul>apteryx: let's keep v1.3.0 for this one <apteryx>roptat: make passes here also, but 'make doc/guix.it.info' still fail <apteryx>Makefile.am: error: 'version.texi', included in 'doc/guix.ko.texi', also included in 'doc/guix.texi' <apteryx>that's on version-1.3.0 with guix-manual.{fa,fr,it}.po refreshed following 'make download-po' <roptat>again, I'm on top of latest version-1.3.0 with no local changes except for make download-po <roptat>so maybe one of your local changes did something wrong? <apteryx>there's no more local changes except those of download-po :-( <roptat>or you're not running make before trying to build the translated manual <roptat>(well, make itself should build the translated manuals) <apteryx>will try on a 2nd machine. I'm starting to doubt physics ;-) <roptat>oh, I see guix-manual.ko.po has the wrong translation for "version.texi" <roptat>but I don't know why it works here and not for you ... <roptat>it seems you'll need to change po/doc/guix-manual.ko.po: "version.texi" should be translated with "version-ko.texi" and "Top" should be translated with "Top", not "정상" <roptat>(I just pushed to the weblate repo with these changes) <roptat>(although you don't need to run download-po again, just apply these changes locally) <apteryx>so after 'make', to trigger the problem, all I need to run is 'autoreconf -f' <roptat>I see, I didn't run autoreconf again <apteryx>yeah, not sure why it doesn't trigger the problem when it first runs <roptat>because bootstrap creates dummy files that work fine <roptat>but after translation, the files are not fine anymore and autoreconf then fails, not great <apteryx>I mean, I do: './bootstrap && ./configure --localstatedir=/var --sysconfdir=/etc && make && autoreconf -f' <apteryx>the files from bootstrap should still be there, no? <roptat>no, make replaces them with the actual translation <roptat>I mean bootstrap generates dummy doc/guix.*.texi and stuff <roptat>but after make, they are replaced with the actual content, which is not fine anymore <roptat>anyway, after fixing po/doc/guix-manual.ko.po as I told you, git clean -xfdd, make && autoreconf -f pass! *civodul goes afk for a while; ttyl! <apteryx>roptat: the download-po targets takes a lot of time, but it doesn't seem to make use of either CPU or network much; any idea where the bottleneck comes from? <apteryx>I see msgfilter is running with a handful of CPU percents use. <roptat>yeah, I think msgfilter is the bottleneck <apteryx>autoreconf -f exited with 0, woohoo! <apteryx>pushed latest translation fixes to version-1.3.0 <apteryx>'make release' should be done in a few hours... and we can release tonight, EDT. <vivien_>I’m happy guile does something for mingw users, although it’s probably not useful for guix <roptat>wingo, I don't think so, it's too recent, we would have to test a new rc, and that will never end :) <roptat>let's break master and finally release 1.3.0 :) <davexunit>I think guix should have a guile package that is safe to upgrade as soon as a new guile release comes out <davexunit>I always want the latest guile as soon as it is released, but even guile-3.0-latest cannot be upgraded without considering how it might break some other things. <nckx>Did booting with nomodeset not work? <nckx>What happens then? The exact same thing? <kotik>Yeah, exact same thing happens <nckx>(To complicate matters, none of the ‘error’ messages quoted have anything to do with the problem. Not one. So we're errorless.) <kotik>Hm, I should check, I don't remember <leoprikler>In your case it might not be, but also read the rest of the message. <leoprikler>kotik: That graphics card probably does not like linux-libre. Try to get a minimal setup (bare-bones.scm) working instead of full-blown desktop.scm <raghavgururajan>leoprikler: Regarding "Although in this case, it's probably sane, since you're using an extra output, but do verify Remmina to work as intended without it." <kotik>leoprikler: thank you, I'll try <apteryx>kotik: I think the nomodet kernel option might help <kotik>apteryx: I've tried this option already with no luck <rndd>is there any example of command line programm written in common lisp and packed with guix? <apteryx>kotik: OK. Then I have no clue. I have bad experience recent AMD GPUs that insist on having a binary blob to do anything. <leoprikler>not sure how command-liney it is, but we do have at least one browser packaged <kotik>apteryx: thank you, anyway, I'll try bare-bones.scm setup or non-libre kernel maybe then <leoprikler>raghavgururajan: the point was to add it to vnc, but whatever <chikamungus>Hi lovelies! What is meant to be the correct behaviour re .xsession files with gdm? I found that it didn't add an extra menu option but any desktop I selected would be ignored and my xsession would be run instead <chikamungus>...all I really want to do is run some xinput, xmodmap and xcape commands before my desktop is run. Maybe there's another way of doing it <derivates>hello, is it possible to modify packages without creating an actual channel? <leoprikler>derivates: yes, you can put packages into single guix.scm files <leoprikler>chikamungus IIRC there's a key to toggle between sessions (F2 maybe?) <apteryx>kotik: what are the symptoms? no video output? error message? <Ikosit>Is it possible to install a package to a specific directory, other than /gnu/store ? <apteryx>I reckon that card probably needs the amdgpu driver. We have it packaged as xf86-video-amdgpu; you could add this to the list of xorg modules in your xorg-configuration <derivates>leonprikler: nice, looking forward to my builds of the st tools <apteryx>now the question is would that be enough to get working 2d without the firmware blobs; I hope so but I'm not sure <chikamungus>leoprikler: I don't really understand. I normally select different desktop sessions via the dropdown menu but if I have a .xsession file, whatever desktop I choose is ignored and the xsession file run instead <rndd>Ikosit: "guix package -i packet -p /directory/" <clacke>rndd: sbcl is written in itself and is in guix <rndd>clacke: yeeee but i was looking for something easier. but thanks, this is also and idea <leoprikler>you could also put this into bash_profile or zprofile depending on your shell and whether you want that <chikamungus>maybe I'll try the slimm login manager. Itcertainly seems popular <leoprikler>raghavgururajan: how is a cycle created both ways? *vagrantc is partial to the "login" login manager :) <kotik>there is an interesting line `error in finalization thread: Success`, error message "success" :) <apteryx>that's actually not an interesting line, it's present on every boot of the Guix System <raghavgururajan>Btw, remmina is multi-protocol client. Would adding it to vnc be counter-intuitive? *raghavgururajan needs beans (looks at nckx) <apteryx>kotik: are you sure it hangs, rather than simply black out? if it's the later, it could be just the video driver <clacke>rndd: wow, I've tried to look around for a command line tool among the sbcl-* packages, but I'm on my phone and it really seems to be all libraries. <leoprikler>perhaps, but it's still preferable to yet another single-package module <apteryx>you can perhaps get a hint about this by seeing disk activity passed the apparent hang <civodul>apteryx: great that you were able to fix things and run "make release"! <leoprikler>of course we could try to merge vnc into rdesktop unless I'm missing something <civodul>wingo: i'll take care of 3.0.7 right after the release (i have a local patch locally) <apteryx>civodul: phew, yay! the 'Post a news item on the web site' will happen automatically following the blog post, right? <civodul>apteryx: yes: you'll have to move the file to posts/ and change its 'date' field <apteryx>civodul: in release.org it says the 'news will end up on planet.gnu.org and [...]'. What will end up there is actually the content of the blog post, right? <raghavgururajan>leoprikler: Can I rename remmina.scm to remote-desktop.scm? We can move contents of rdesktop.scm and vnc.scm to there? <clacke>if you're on a proper computer, maybe try looking for things that use both asdf-build-system/sbcl and build-program *raghavgururajan now really goes and gets some coffee. <rndd>clacke: there is no build-program <kotik>:apteryx yeah, it just hangs, no black out, cpu does not do anything (it is silent) <clacke>no package in guix uses build-program with asdf-build-system/sbcl? <rndd>clacke: maybe i missed something. give me and example of "build-program", please <chikamungus>it seems slim doesn't honour .xprofile either. This is madness. There must be some mechanism whereby I can configure my bits and bobs <civodul>apteryx: yes, every blog post eventually shows up on planet.gnu.org and planet.scheme.org <leoprikler>IIRC the "shell and everything"-agnosting profile is simply called .profile <leoprikler>and you want to run that code always or only in graphic sessions? <chikamungus>I mean I could just run my script from emacs startup or when I open a shell in another window manager but really it's something I'd like to always run, even if I decide to futz about with some other crazy desktop environment <leoprikler>also exwm not setting up correctly is a known bug <chikamungus>CM-& is tricky on this thumb keyboard without my script! <chikamungus>I'll cope. Thanks for all the suggestions leoprikler <leoprikler>drakonis: I heard you like guix, so we put guix into our language-specific package manager. <drakonis>this aims to do what guix did later down the road <drakonis>i have a feeling it might be able get further ahead than either nix or guix due to racket being much more mature in various regards <drakonis>one of the things that bothers me about guix's package build scripts is that it has a bunch of bespoke functions for interacting with the filesystem <drakonis>not being able to invoke the usual coreutils as functions is a strange affair <drakonis>gash and gash coreutils currently exist but only for bootstrapping, they're not being used for packages <zimoun>if upstream provides patches, then where should they be located? inside ’source’ or is it ok to have them in ’arguments’ add-after unpack? <zimoun>corollary, is it possible to apply patches located in source, some with the option “-p1” and others with “-p2”? <vldn>how to append to the operating-system definition within a second file? like defining new packages <leoprikler>zimoun origin patches, and there's an extra flags field that often goes unused <pkill9>so xiden is going to deprecate guix? D: <zimoun>leoprikler: thanks. But is it possible to use the patch-flags with 2 different options depending on patch to apply, namely -p1 and -p2? Or do I have to write a manual “dispatcher” for this option? <davexunit>guile provides posix features and it's easy to shell out to an external program <davexunit>not sure what the issue is. I've always thought it was much better than any other language I've used. <leoprikler>the issue is, that I can't just write (ls '-lah) of course :) <leoprikler>why would you ever want to (invoke "ls" "-lah") inside build? Surely the way I wrote it is much more beautiful. <drakonis>i'd prefer to have a function that imitates coreutils behavior <drakonis>rather than shelling out to something that might break <dustyweb>drakonis: I don't know all that much about xiden <dustyweb>but I suspect it's fairly racket-oriented <davexunit>like, we wrote a container implementation with guile. the posix layer is quite good. <leoprikler>Guix went for general and free software on day 0. <dustyweb>in that maybe it'll be easier to package xiden things than guix things <dustyweb>*I* mean it'll make it easier to deal with Racket packages packaged in Xiden <dustyweb>than Racket packages packaged with the current tooling <davexunit>so what's the point? that we should stop guix and use xiden? <dustyweb>I was there for the talk and talked a bit with them afterwards <dustyweb>I don't think this needs to be framed as an us-vs-them thing <dustyweb>if there's a langugage-oriented package manager that's taking a more guix/nix like approach, isn't that better for us in a sense than all the others taking the "flat" imperative approach? <davexunit>it's weird to suggest guix is somehow broken because of an aesthetic opinion about posix api <dustyweb>most likely, we'll have an easier time getting along with their things than others <leoprikler>Which makes writing another functional package manager from scratch in Scheme nearly pointless. <leoprikler>Except of course for the "It's not our flavour of Scheme" side of things. <dustyweb>my personal preference is to get racket stuff packaged in guix <drakonis>well, racket has tricks guile does not have <dustyweb>most likely, some good ideas might be explored there, and what might come out of it are "some good ideas to absorb into guix" <dustyweb>I don't think xiden has much in terms of users right now <dustyweb>there's no need for hand-wringing, or framing things in terms of conflicts <drakonis>there's not a lot of users because it just got published a month or so ago <dustyweb>drakonis: anyway, if you're excited about it, go explore, and report back! but keep it positive <drakonis>racket is very cool and i'd like to see what can be done with something as powerful as it <drakonis>not needing to be initially a shim around the nix daemon could make a huge difference <drakonis>and i'm aware of work regarding freeing guix from such a burden <drakonis>but starting without such restrictions could allow for a lot of interesting features <drakonis>guix is fantastic but can always improve <drakonis>i've noticed an interesting thing in xiden btw <apteryx>civodul: is overdrive1 reachable by SSH for you? <apteryx>seems offloading hung on /gnu/store/qwijp5kjrfa0zgcwmmaj0qy0fxgks4g7-guix-1.3.0.drv <civodul>apteryx: it's apparently reachable, yes <civodul>"guix processes" shows: LockHeld: /gnu/store/376hml2clvfb2cjf4g0x8ndkdcbar3rj-guix-1.3.0.lock <civodul>apteryx: looks like tests/workers.scm is stuck <civodul>well dunno if it's stuck or just taking time <drakonis>hmm, is there anything in the works for sandboxed application execution? <civodul>drakonis: flatpak absolutely requires "sandboxed execution" because users end up running untrusted code <civodul>that said, you can use "guix environment --container" to do that <drakonis>i was talking about writing some code to sandbox entire distributions using guix <drakonis>as a migration avenue, as there are some things that sadly require a lot of effort to package <pkill9>someone said the qubes tooling could be added and add qubes functionality as wlel <drakonis>like some python packages that require rust <pkill9>i would like sandboxing, maybe using apparmour or something <civodul>apteryx: tests/workers.log is empty; i think your best bet is to try again <leoprikler>raghavgururajan: v6 addresses the file issue, but I still believe your REMMINA_PLUGIN_PATH is insufficient (start with REMMINA_PLUGIN_PATH=".") <roptat>maybe the joke is that part 5 is followed by part 8 :) <leoprikler>insufficient as in "it does not do what you want it to do" <leoprikler>Now try that again with REMMINA_PLUGIN_PATH already set to some value, even a bogus one. <roptat>is that because it can contain only one entry? <mbakke>there are some strange (test) failures in the Shepherd with Guile 3.0.5 and 3.0.7. "herd no-such-action root" turns into (shepherd-command (version 0) (action status) (service root) ...) and gives no output. <mbakke>yet "herd no-such-action foo" works: (shepherd-command (version 0) (action does-not-exist) (service foo) ...) <raghavgururajan>leoprikler: I tried ".". I now understand. Will do the separator as roptat suggested. *raghavgururajan play with the cat <apteryx>civodul: eh, at least they mentioned Guix... <nckx>(cons* ☕ raghavgururajan) ; I was out. <apteryx>civodul: retrying 'make release', take 2. <leoprikler>raghavgururajan: I don't quite see what the benefit of that would be over hardcoding the path though. Am I missing something? <drakonis>rather, how does it translate to shepherd? <roptat>oh, I didn't know about this project, but that sounds exciting :) <roptat>(to be honest anything goblins related is exciting :p) <drakonis>does it actually make shepherd faster and more flexible :V? <roptat>well, not faster, but probably more features <drakonis>it'd probably make shepherd faster by the virtue of being async <roptat>"GNU Guix with GNU Shepherd brings POLA to software deployment", not sure how though <drakonis>has anyone taken up any gsoc projects this year? <roptat>I think the fsf is not part of gsoc anymore, so not sure what's the status <dustyweb>drakonis: it probably means that a) you could do remote administration of a machine easier and b) it would be possible to have multiple shepherds on the same machine, collaborating <raghavgururajan>leoprikler: [1] I don't know how to hard-code it [2] If things are good as-is, it would be one less work for me. :) <leoprikler>the thing was hardcoded before your patch so it confuses me why that patch is necessary *raghavgururajan check compatibility with non-guix systems. <lfam>I'm trying to use `guix system` on Debian aarch64. When I do a command like `guix system build config.scm`, it returns after doing no work <lfam>Does anybody know what's up with that? <lfam>`guix build hello` works okay <lfam>Even appending -n or -d to the `guix system build` command does nothing <iskarian>Does Guix prefer dynamic executables which NEED libc.so to have glibc as RUNPATH or should that be omitted since the interpreter is in glibc and will find libc.so there? <lfam>I guess it's problem with my config.scm. The templates have an effect <drakonis>dustyweb: but it can be used for improving shepherd's performance, right? <drakonis>seems like something it requires as a baseline to achieve the proposal's goal <raghavgururajan>leoprikler: IIUC, were you suggesting the value for REMMINA_RUNTIME_PLUGINDIR to be the path to plugins output? ***Noisytoot is now known as Sigyn
***Sigyn is now known as Noisytoot
<dustyweb>drakonis: I dunno is performance a problem in shepherd? <dustyweb>of all the complaints about shepherd, performance isn't a significant one I've heard yet <leoprikler>raghavgururajan: the separation into plugins output is also something I don't get with the current setup <leoprikler>like, currently you have the choice between "no plugins" and "the plugins you would have got if you didn't mess with it in the first place" <leoprikler>whereas with a proper PATH variable you could at least argue "yeah, the user can put their own $PWD in front of that and load some extra stuff" <raghavgururajan>v1 was like that. Just thought users could use remmina for SSH+SFTP, without plugins. <vldn>how to show the config.scm options in cli? <vldn>like a extended help for guix system <lfam>vldn: You can consult the manual <raghavgururajan>Shall I proceed or you think output 'out' being minimal with SSH+SFTP is better? <vldn>how can i search the manpages from the command line? :D <vldn>like info guix -search service-type or something <lfam>Maybe somebody else is an info expert :) <vldn>maybe --index-search="service-type" ? ^^ <civodul>it's the "release effect", a close relative of the demo effect *vagrantc awaits v1.3.0.1 tag :) *raghavgururajan makes the remmina patch less complicated <apteryx>vagrantc: eh, I fear I'm back to conservatively pushing tags only once the release artifacts have been built, summarily validated and uploaded ;-) ***rekado_ is now known as rekado
<vagrantc>apteryx: thanks for all the work on it! :) <vagrantc>trying to figure out how to add an argument to supply an additional firmware <vagrantc>but i'm not clear on the scoping of the "scpfirmware" variable <vagrantc>wondering if some interaction between make-u-boot-package and make-u-boot-sunx64-package <cbaines>does scpfirmware just need unquoting, so ,scpfirmware ? <vagrantc>think i tried that, but let me see if i can get an error <vagrantc>guix build: error: /home/vagrant/src/guix/gnu/packages/bootloaders.scm:777:4: package `u-boot-pinebook@2021.04' has an invalid input: ("scpfirmware" "crust-pinebook") <vagrantc>do i need to render the scpfirmware string as something else? <cbaines>I think that's better, but it looks like the value of scpfirmware is a string, whereas it should be a package <vagrantc>if i can get this working, suspend (and noteably, resume) might work on the sunxi pine* boards <vagrantc>oh, could i instead pass the package as the argument? <vagrantc>- (let ((base (make-u-boot-sunxi64-package "pinebook" "aarch64-linux-gnu"))) <vagrantc>+ (let ((base (make-u-boot-sunxi64-package "pinebook" "aarch64-linux-gnu" "crust-pinebook"))) <cbaines>Yeah, I would pass a package in, rather than a string *vagrantc conspires to add or1k cross compiler to guix <jonsger>raghavgururajan: kill -p9 or something like this? <cbaines>raghavgururajan, what signal are you sending icecat? <cbaines>different signals have different effects <pkill9>raghavgururajan: if you want to aggressively kill a process, use `pkill -9` :D <cbaines>raghavgururajan, the relevant signals here are TERM and KILL <cbaines>TERM is the default, but generally processes don't survive SIGKILL <pkill9>raghavgururajan: pkill -9 icecat? <cbaines>raghavgururajan, I'd send the signal to the main icecat process by PID <vivien_>Also, maybe it’s easier to reboot the computer <pkill9>raghavgururajan: does `pgrep icecat` return the process? <cbaines>raghavgururajan, you're trying to kill a zombie <cbaines>and zombies can't die, they're already dead <pkill9>is there a way to tell linux to target the brain? <vivien_>(not surprised ICEcat has a frozen window) <cbaines>raghavgururajan, what window manager are you using? it sounds like the problem is more with it. <leoprikler>raghavgururajan: wrap-progs should be wrap-typelibs and probably added after 'wrap <Formbi>texlive complains that it can't find lmodern.sty even though I installed texlive-lm <cbaines>civodul, both the Accept header and extensions should generally work, but I think I'm not quite using the value coming back from request-accept properly... <rekado>Formbi: when you install texlive packages into your profile things should just work, thanks to the profile hook that sets up a texlive configuration. <civodul>cbaines: yes, but it works with ".json" anyway <civodul>i wonder if the arguments to most-appropriate-mime-type are reversed actually <cbaines>civodul, yeah, it does look like they might be