IRC channel logs


back to list of logs

<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.
<zimoun>why does <> list only 6 translations when <> shows many more? Especially Dutch, Portuguese (Brazil), Slovak. Do I miss something?
<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> agrees.
<nckx>Oh, the 92% is for Guix (the software) itself.
<zimoun>All the G_ strings, right?
<zimoun>ok, now make sense. Sorry for the noise. Fancy interface. :-)
<zimoun>this time, Good night.
<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>hi everyone!
<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.
<ss2>anyways, off 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?
<sneek>Got it.
<roptat>apteryx, ^
<roptat>sneek, botsnack
<derivates>Hello, how can I solve this issue: guix system: error: the group `guixbuild' specified in `build-users-group' does not exist
<derivates>I literally just added tlp as a service
<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
<vagrantc>not very guixy
<lfam>derivates: It sounds like these steps were omitted when installing Guix:
<lfam>It's on a distro besides Guix System, right?
<lfam>Oh, they left
*vagrantc waves to lfam
<lfam>They did mention a service, which leans towards Guix System... it's surprising if the guixbuild group is missing on Guix System
<lfam>Howdy vagrantc
<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>That's great vagrantc
<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 :)
<mekeor[m]>sounds awesome :O
*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>roptat: sounds reasonable
<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...
<nabataeus>anyone here?
<lfam>Yes we are here
<roptat>apteryx, did you run "make download-po"?
<apteryx>no! I should?
<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>it doesn't let me in
<nabataeus>as well as,
<nabataeus>the qemu image isn't working it gives a kernel panic with some error code
<nabataeus>but I don't really want to use qemu
<nabataeus>I'm installing it on hardware
<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
<nabataeus>I'm using stable version
<lfam>The stable version, meaning you used the 1.2.0 installer image?
<vagrantc>oh wow, etc/committer.scm !
<nabataeus>lfam: indeed
<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
<apteryx>nabataeus: it could be useful if you tried this VM image:; which is about to be released in 1.3.0 proper.
<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
<nabataeus>apteryx: what's a qcow2 file
<nabataeus>I'm absolutely new to this
<apteryx>it's the copy on write native format of QEMU
<nabataeus>Copy On Write
<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>works fine on windows
<lfam>I'm sorry
<nabataeus>no need to apologise
<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
<nabataeus>in very rare cases like this one
<nabataeus>it's usually alright
<lfam>We use the linux-libre kernel, which removes non-free / proprietary drivers from the kernel
<nabataeus>yeah I know that, I read the wiki
<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: that's what I get after running download-po:
<apteryx>roptat: the 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
*vagrantc struggles to not see *.org as a domain name
<apteryx>roptat: new translations pushed!
*apteryx now good for ~5 h long 'make release'
<apteryx>roptat: mhh, have you ever seen this: 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
<roptat>the others are correct
<roptat>(at least for these strings)
<apteryx>there's .ko also
<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>or 2, not sure
<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
<apteryx>OK! I'll run it again then
<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>sorry about that ^^'
<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>no worries; so I got the following changes:
<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>OK, will use ./bootstrap
<apteryx>more like: find -name '*.??.texi' -delete, actually
<apteryx>OK, seems to work
<apteryx>spoke too soon :-D
<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>thanks for the help!
<apteryx>good night!
<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/ @include: could not find
*apteryx zzz
<vagrantc>the v1.3.0 seems to have a bit of cruft in the annotation: v# v1.3.0
<vagrantc>but happy to see a tag ... :)
***iyzsong-- is now known as iyzsong-w
<drakonis>hmm, is it viable to have parsers for guix configs written in another syntax?
<drakonis>ie: not s-exps?
<jackhill>drakonis: I don't see why not.
<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
<drakonis>but yes
<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 :)
<drakonis>oh yes.
<jackhill>drakonis: ah! Here's the JSON package definition thing I was remembering:
<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>and how are you still awake
<drakonis>time zone magic it seems?
<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
<tissevert>hi guix !
<drakonis>ah, wait, it does other package types too.
<drakonis>very neat.
<abralek>hi guix
<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?
<civodul>Hello Guix!
<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.
<jeko_>Hey Guix !
<civodul>hey jeko_!
<civodul>PurpleSym: yes, you could use a VM with a 9p mount, like we do for system tests
<mothacehe>hey guix!
<civodul>howdy mothacehe!
<jeko_>yo mothacehe
***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?
<ss2>just wanted to say that I was told to write a message to
<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>ss2: d'oh!
<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 :-)
<brendyyn>ok priorities :)
<civodul>ss2: i think i can reproduce it
<ss2>With the same checkout I provided?
<pkill9>i have an idea
<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
<mothacehe>civodul: yes great job! I guess we can close the Guile bug I opened here:
<civodul>mothacehe: i had overlooked that one, my bad!
<civodul>but yes, looks like we can close it
<mroh>civodul: I will take a look at the configure-flags for libmediainfo (which seems to break mediainfo). Thx for review!
<apteryx>zimoun: hello!
<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>apteryx: hey! :-)
<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/' now gives './doc/ @include: could not find'
<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>moin apteryx!
<civodul>apteryx: doesn't ./bootstrap generate those?
<civodul>the version.LL.texi files
<apteryx>it was generating version-LL.texi files; fixed that so that to 'version.LL.texi' files
<apteryx>now get the above error
<civodul>zimoun: no it's not OK yet to use the Guile 3 exception API; use SRFI-34 or 'catch'
<apteryx>actually it wasn't generating them
<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
<civodul>nothing has changed makefile-wise
<apteryx>have you pulled? there were translation updates
<civodul>yes, i did
<apteryx>does 'make doc/' 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. :-)
*apteryx retries
<civodul>apteryx: "rm -f doc/{info,texi} doc/ && make -j5" works
*civodul tries "guix build -f doc/build.scm"
<efraim>can I use (guix utils) in (guix build go-build-system)?
<civodul>efraim: yes
<civodul>it's all "host-side" code
<roptat>apteryx, it's "version-it.texi", not "", 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>that's the first error you have
<civodul>31 ./doc/ @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/ @include: could not find os-config-bare-bones.texi
<civodul>there's a makefile rule for that, too :-)
<civodul>try just "make" maybe?
<civodul>perhaps we got the dependencies wrong
<apteryx>I fixed that locally yesterday by adding a prerequisite on it
<apteryx>like so:
<apteryx>after that's done, I'm back to the original problem I faced yesterday: error: 'version.texi', included in 'doc/', also included in 'doc/guix.texi'
<roptat>apteryx, there needs to be a translation for "version.texi" in po/doc/
<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
<apteryx>should I run it after all?
<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 :-/
*apteryx clones anew
<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
<civodul>go figure!
<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 for 'pre-inst-env' is pertinent or not
<civodul>which commit is this?
<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>civodul: the guard I was thinking about would be this:
<apteryx>civodul: about tags, I agree.
<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
<civodul>that's okay
<apteryx>roptat: make passes here also, but 'make doc/' still fail
<apteryx>perhaps that's not a good test?
<civodul>ah so it still fails?
<apteryx>autoreconf -f (after tagging) too
<apteryx> 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'
<apteryx>(and commited locally for now)
<civodul>did you run "make doc/version.texi"
<civodul>or "rm doc/stamp-vti"?
<roptat>apteryx, it passes here
<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
<apteryx>I did run 'make'
<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 ...
<apteryx>did you run 'git clean -xfdd' ?
<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)
<roptat>this is the diff I see from the top of version-1.3.0:
<apteryx>so after 'make', to trigger the problem, all I need to run is 'autoreconf -f'
<apteryx>reproducible on 2nd machine
<roptat>I see, I didn't run autoreconf again
<apteryx>yeah, not sure why it doesn't trigger the problem when it first runs
<apteryx>(as part of bootstrap)
<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?
<apteryx>Ah, OK.
<roptat>no, make replaces them with the actual translation
<roptat>I mean bootstrap generates dummy doc/guix.*.texi and stuff
<roptat>to please autoconf
<roptat>or automake
<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!
<apteryx>sounds good!
*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
<roptat>it creates lots of processes
<apteryx>autoreconf -f exited with 0, woohoo!
<apteryx>pushed latest translation fixes to version-1.3.0
<apteryx>roptat: thanks for the help!
<apteryx>'make release' should be done in a few hours... and we can release tonight, EDT.
<wingo>with guile 3.0.7? :)
<wingo>(probably not i'd guess ;)
<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 :)
<wingo>i figured ;)
<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.
<raghavgururajan>Hello Guix!
<kotik>Tried to meet guix but failed at the very beginning :)
<nckx>Did booting with nomodeset not work?
<kotik>no, it doesn't...
<nckx>What happens then? The exact same thing?
<kotik>Yeah, exact same thing happens
<nckx>Which GPU do you have?
<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
<nckx>Hi Raghav.
*nckx aways.
<kotik>Radeon RX 560
<raghavgururajan>leoprikler: Why using env-var dangerous?
<raghavgururajan>I got the idea from pidgin patch.
<raghavgururajan>purple_plugin_path = g_getenv("PURPLE_PLUGIN_PATH");
<leoprikler>It *can* be dangerous, see breaking Emacs.
<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
<rndd>hi guix!
<raghavgururajan>IIUC, if remmina works without its other output, things are good?
<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
<raghavgururajan>Regarding module, I think moving to vnc.scm would cause same effect of cyclic-dep, if I add #:use-module (gnu packages rdesktop).
<raghavgururajan>leoprikler, ^
<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
<Ikosit>Oh, nvm
<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
<leoprikler>Ahh, okay, then I understood you wrong.
<leoprikler>Perhaps you can source .profile instead?
<chikamungus>I'll have a look into that
<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
<chikamungus>alas gdm ignores ~/.xprofile
<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 :)
<chikamungus>vagrantc: that may give me the zen I seek
<kotik>apteryx: just some log messages, I've included them into issue
<raghavgururajan>leoprikler: I spoke too fast. I was about to notify you.
<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
<civodul>by default it happens every hour
<apteryx>yep, OK
<apteryx>civodul: in it says the 'news will end up on 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
<leoprikler>rdesktop already means remote-desktop :P
*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 and
<civodul>(no action needed)
<leoprikler>chikamungus: you mean ".profile", right?
<chikamungus>I do?
<leoprikler>IIRC the "shell and everything"-agnosting profile is simply called .profile
<chikamungus>I want to autorun my script on xorg startup
<chikamungus>does xorg run .profile?
<leoprikler>it should IIRC
<chikamungus>I'll give it a try... back soon!
<leoprikler>did it work?
<chikamungus>neither gdm nor bash run .profile !
<leoprikler>and you want to run that code always or only in graphic sessions?
<chikamungus>always - it sets up my keyboard
<leoprikler>in that case why not put it into bash_profile?
<chikamungus>because exwm doesn't run bash_profile
<raghavgururajan>leoprikler: Moved it to vnc.scm in v6. :)
<leoprikler>hmm, then put it into your .exwm?
<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
<chikamungus>but yes... there are solutions
<leoprikler>there is always the source command :)
<leoprikler>also exwm not setting up correctly is a known bug
<leoprikler>things should work fine in other wms
<drakonis> this is very weird to find out about
<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:
<leoprikler>Probably not
<pkill9> /hyperbole
<drakonis>i bet dustyweb would be all over it
<drakonis>he's our local racket lover
<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
<drakonis>racket also provides that
<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 :)
<drakonis>yes :v
<drakonis>sure i'll take that
<davexunit>who the hell would want that lol
<davexunit>(system* "ls" "-lah")
<leoprikler>why would you ever want to (invoke "ls" "-lah") inside build? Surely the way I wrote it is much more beautiful.
<davexunit>I don't think it is
<drakonis>i'd prefer to have a function that imitates coreutils behavior
<drakonis>rather than shelling out to something that might break
<davexunit>racket people can fun messing with that
<davexunit>all the academics
<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.
<dustyweb>whereas guix is fairly "general"?
<drakonis>it can go for general later
<leoprikler>Guix went for general and free software on day 0.
<dustyweb>xiden might still be good for guix
<dustyweb>in that maybe it'll be easier to package xiden things than guix things
<drakonis>general means managing everything
<leoprikler>you mean raco things?
<drakonis>not just raco things
<drakonis>its in the talk
<dustyweb>*I* mean it'll make it easier to deal with Racket packages packaged in Xiden
<drakonis> one of the questions is related to it
<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
<drakonis>i see
<drakonis>interesting then
<drakonis>the point is to aim to be better
<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>"but racket is so much more fun than scheme"
<dustyweb>racket is mostly scheme
<dustyweb>(and even includes scheme)
<dustyweb>guile is also mostly scheme ;P
<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
<drakonis>it is partially why i'm excited
<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"
<drakonis>true that
<dustyweb>I don't think xiden has much in terms of users right now
<dustyweb>I could be wrong
<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
<drakonis>it isnt a competition
<drakonis>that talk
<dustyweb>more than a few months ago
<drakonis>i linked it
<dustyweb>er, more than a month ago
<dustyweb>about half a year ago
<dustyweb>was that talk
<dustyweb>drakonis: anyway, if you're excited about it, go explore, and report back! but keep it positive
<drakonis>i meant repo being published
<drakonis>of course
<dustyweb>great :)
<drakonis>i'm excited to see what comes out of it
<drakonis>racket is very cool and i'd like to see what can be done with something as powerful as it
<drakonis>unburdened by its legacy
<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
<drakonis>it has a concept of launchers
<apteryx>civodul: is overdrive1 reachable by SSH for you?
<apteryx>ah nevermind it works
<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>though it seems to have stalled :-/
<civodul>apteryx: looks like tests/workers.scm is stuck
<civodul>spinning at 100%
<civodul>well dunno if it's stuck or just taking time
<drakonis>hmm, is there anything in the works for sandboxed application execution?
<drakonis>something to replace flatpak
*civodul stumbled upon which looks like a joke
<civodul>drakonis: flatpak absolutely requires "sandboxed execution" because users end up running untrusted code
<civodul>that's quite different here
<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>late last week that is
<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>civodul, why is that a joke?
<roptat>maybe the joke is that part 5 is followed by part 8 :)
<raghavgururajan>leoprikler: Insufficient as in non-functional?
<leoprikler>insufficient as in "it does not do what you want it to do"
<raghavgururajan>But it did. :P
<raghavgururajan>Worked in both pure and impure env.
<raghavgururajan>*both in
<raghavgururajan>Or you mean ununtended effect?
<leoprikler>Now try that again with REMMINA_PLUGIN_PATH already set to some value, even a bogus one.
*raghavgururajan tries
<roptat>is that because it can contain only one entry?
<raghavgururajan>You meant bogus one in native-search-path right?
<leoprikler>roptat: ding ding ding
<roptat>in that case set (separator #f)
<roptat>in the native-search-path
<raghavgururajan>Ah I missed the separator
<raghavgururajan>I came across it some where. gajim or gst.
<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>dustyweb: how does this influence shepherd?
<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?
<drakonis>it would be a significant boon
<roptat>probably not
<roptat>well, not faster, but probably more features
<drakonis>goblins does async, doesnt it?
<roptat>ah in that sense, right
<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?
<drakonis>ah, its not even on gsoc this year
<roptat>I think the fsf is not part of gsoc anymore, so not sure what's the status
<drakonis>a shame.
<drakonis>that one looks really good
<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
<drakonis>i see
<raghavgururajan>oh ...
<iskarian>morning guix :)
*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 to have glibc as RUNPATH or should that be omitted since the interpreter is in glibc and will find 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
<drakonis>its the lack of parallelism
<dustyweb>yes that one is true
<dustyweb>yes it could help there.
<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.
<raghavgururajan>Okay, no problem. I will just use one output.
<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
<vldn>from the cli?
<vldn>ah info guix
<lfam>Yes, that too :)
<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>apteryx: i hope it works this time!
<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! :)
<raghavgururajan>leoprikler: Does v9 look good?
<vagrantc>goodbye matrix bridge
<vagrantc>anyone able to help with this patch?
<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?
<vagrantc>or evaluate it or something?
<vagrantc>or throw more , at it? :)
<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
<cbaines>where is it defined?
<vagrantc>oh, could i instead pass the package as the argument?
<vagrantc> (define-public u-boot-pinebook
<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")))
<vagrantc>that's how i'm passing it
<cbaines>Ah, I see
<cbaines>Yeah, I would pass a package in, rather than a string
<vagrantc>will try
<civodul>welcome back, Matrix friends! :-)
<raghavgururajan>I am unable to kill hanging icecat
<raghavgururajan>neither kill nor pkill works.
<vagrantc>cbaines: that was it, thanks!
*vagrantc conspires to add or1k cross compiler to guix
<jonsger>raghavgururajan: kill -p9 or something like this?
<raghavgururajan>jonsger: `kill -p9` as a command?
<cbaines>raghavgururajan, what signal are you sending icecat?
<raghavgururajan>I usually do pkill icecat
<raghavgururajan>cbaines: Is there an aggressive option?
<cbaines>different signals have different effects
<pkill9>raghavgururajan: if you want to aggressively kill a process, use `pkill -9` :D
<raghavgururajan>pkill9: IceCat is still breathing.
<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?
<raghavgururajan>pkill9: Tep even after that.
<pkill9>my life is a lie...
<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
<raghavgururajan>vivien_: I have a lot in progress. :)
<cbaines>and zombies can't die, they're already dead
<cbaines>(and probably not breathing either)
<cbaines>that's what the Z's mean
<raghavgururajan>I am not able to create new icecat window.
<pkill9>is there a way to tell linux to target the brain?
<raghavgururajan>There is also hang window stuck on my wm.
<cbaines>what's a hang window?
<raghavgururajan>Like window named "GNU Icecat"
<raghavgururajan>frozen window.
<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
<leoprikler>or even after glib-or-gtk-wrap
<leoprikler>otherwise lgtm at a glance
<leoprikler>I trust you that it builds and runs :)
<raghavgururajan>My laptop restarted itself.
<raghavgururajan>leoprikler: Ah cool!
<raghavgururajan>Yep, I am using it to access bayfront atm. ;-)
<leoprikler>does it have that slick GNOME 3 Feel?
<civodul>cbaines: "wget --debug --header='Accept: application/json' -qO -" returns HTML
<civodul>am i missing something?
<civodul>ah i can add ".json", perfect!
<Formbi>how do texlive packages work?
<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.
<Formbi>well, it doesn't
<civodul>cbaines: yes, but it works with ".json" anyway
<civodul>i wonder if the arguments to most-appropriate-mime-type are reversed actually
<civodul>but my mind is too fuzzy to decide
<raghavgururajan>> leoprikler‎: does it have that slick GNOME 3 Feel?
<raghavgururajan>Yep, using dark-mode.
<cbaines>civodul, yeah, it does look like they might be