IRC channel logs
2022-11-11.log
back to list of logs
<rekado>I???m glad that apteryx???s fears of storage corruption / file system damage were unfounded <civodul>rekado: oh you know that qla2xxx failed from messages on the serial console? <civodul>anyway thanks for handling this again! <rekado>civodul: apteryx shared some output from later attempts to boot the server <awb99_>I did 'guix system delete-generations' <awb99_>And it is downloading substitutes <iyzsong>it needs update the grub menu, by running the current grub <awb99_>So delete-generstions upgrades the grub bootloader? <awb99_>It could just use the grub loader that is installed, or not? <awb99_>If I just want to free some disk space ... <awb99_>That this exact operstion first adds more disk space. <lechner>awb99: i think it's logical. previous system generations are available in the boot menu, so when you delete them Guix does what it takes to update the menu <awb99_>The menu config needs to get updated. <iyzsong>also the grub package may not in previous systems, its generated menu entries are in. <awb99_>But why upgrqde the grub bootloader? <awb99_>That should happen when I do a system reconfigure. <lechner>maybe it's to make sure the system boots. GRUB is kind of an end-to-end solution <acrow>awb99: guix is a declarative model, so when you delete a generation guix reconfigures to make the system match the prior generation's declaration; the boot loader, or other packages may change and the boot loader menu is certainly going to change. The prior generation might have different package versions or other package dependencies that need to be brought into sync too, so guix is doing a lot for you to be able to maintain <acrow>declarative control of your system. <iyzsong>awb99_: i think this issue can be fixed. current the menu entries are all in one file generated by grub in a install-bootloader script, if we can make every entry a seperated file, then delete generations is simple as delete those entries files. <iyzsong>there is bootloader spec about that from systemd, but i think grub haven't implement it. <apteryx>rekado: glad the SAN problem got resolved <rekado>more plymouth fun: the reason for displaying the splash screen late was due to the very long default device delay in plymouth <rekado>they wait for 8 seconds since plymouthd startup before they go looking for display devices. <unmatched-paren>rekado: are you working on getting a plymouth splash screen set up for guix system? <rekado>8 seconds is longer than the whole boot process of a Guix VM. <rekado>so when I reduced the delay to something between 2 or 4 seconds it???s all fine. <rekado>unmatched-paren: it needs to be started earlier so it???s a little more complicated than that <rekado>currently it is implemented as an extension to boot-service-type (not a shepherd service) <rekado>but once I???ve worked out some kinks I???ll have to move it into the initrd again <rekado>started out with adding it to the initrd, but testing changes like that is just too damn slow <rekado>(rebuilding the initrd and everything else downstream of it takes too long) <rekado>this derivation from Oct 3 builds fine: /gnu/store/janlafi5f1b9yjg4c961nmi3b865hpry-guile-aiscm-0.24.2.drv <silicius[m]>lately this weird started happening to my system that /tmp sometimes disappear <yarl>I am using emacs's eshell with tramp to play on a remote guix system. The problem is I have no access to programs installed on my guix home. For example git. I tried to add "~/.guix-home/profile/bin" to "tramp-remote-path" but that did not work. <rekado>re guile-aiscm: looks like two different versions of protobuf are used <yarl>Does someone uses emacs + guix this way? <yarl>Oh, it did work, I don't know what I did... <Kabouik>Anyone using emacs-plantuml-mode and PlantUML SRC blocks in org-mode? I'm getting an issue which I think might be related to Guix because the package manager installs an executable and not a jar file, and org mode expects a jar file <Kabouik>I set (setq plantuml-default-exec-mode 'executable) but that does not seem to be enough. <rekado>how does the issue manifest itself? <rekado>I???m struggling to understand the conclusion about the jar file <Kabouik>I may have not explained why I think that. This is what I get when I C-c C-v C-e in the plantuml block in org mode "/gnu/store/d99ykvj3axzzidygsmdmzxah4lvxd6hw-bash-5.1.8/bin/bash: line 1: java: command not found" <Kabouik>So somehow either org mode, or plantumml-mode, or org-babel do not take into account the value I set for plantuml-default-exec-mode. <rekado>after ???M-x toggle-debug-on-error??? you should be able to see a backtrace <Kabouik>Note that this may very well be because I use plantuml-mode from MELPA and not from Guix (I have multiple packages from MELPA because they were not available in Guix, and that somehow locked me into using MELPA most of the time because the Guix emacs packages would often have conflicting dependencies) <rekado>oh, mixing stuff from MELPA and Guix might be a bad idea, because the Guix stuff might find the MELPA stuff first (and vice versa) <Kabouik>Yes, that is why most of my packages are now from MELPA, regrettably, and I know sometimes the Guix versions are patched a bit or preconfigured. As is the case with plantuml-mode apparently (guix edit emacs-plantuml-mode@1.4.1 shows some of the custom changes, maybe I should try to replicate them in my init.el) <Kabouik>It's nice, but it lacks the custom changes of manually written Guix patches <Kabouik>And now that I use some of those packages, using those from the Guix channel is difficult due to conflicting dependencies <Kabouik>So on the one hand you have more packages but less tailored to Guix system, and on the other hand fewer packages that are specifically made to work with Guix; and you can't really combine them <Kabouik>I think that's part of why plantuml doesn't work right on my setup <lechner>Kabouik: Hi, would a solution be to upstream some of the patches? <Kabouik>Probably, but I feel I'm already locked in with too many unofficial emacs packages <lechner>Forked packages seem like escape hatches for what should be declarative choices in the upstream packages <unmatched-paren>raghavgururajan: the thing that reduces blue light from your screen during the evening/night? <unmatched-paren>i tried to use ``gammastep'' (redshift-alike for wayland) before but my kernel panicked :) <raghavgururajan>I'm using (service home-redshift-service-type) in the home-services. <rekado>Kabouik: we have a branch wip-node-14 and wip-node-importer that contains an importer <rekado>(don???t know which is more recent) <minima>hi, my emacs doesn't seem to be able to find aspell, despite the fact that that is installed and so is aspell-dict-en - i'm on a guix system <minima>however, i noticed that if i guix install aspell and aspell-dict-en as a user, then it works <tricon>minima: how do you have it installed when it is not working? <tricon>when installed as a system package, what does `which aspell' return? <rekado>weird: we use two different versions of evolution-data-server in the same gnome system <minima>tricon: good point, let me see... it says "no aspell in..." and then a list of locations <tricon>minima: when i add aspell to my sys packages, `which aspell' returns it at: /run/current-system/profile/bin/aspell <minima>hey tricon thanks for checking for me, yes i have aspell in my system definition, but i must be doing something wrong then - let me see if a new reconfigure will fix this <apteryx>rekado: I think it was part of the struggle of having GNOME 42 on master <lilyp>where's the old data server still used? <xd1le>raghavgururajan, glad you are well and recovered now <3 <djeis>Does anyone have an example of the right way to add an extra menu entry for an alternate kernel and initramfs that are already in your boot folder when you've also got the store on a btrfs subvolume? <djeis>Because it looks like the logic for handling a subvolume store unconditionally adds the store prefix to the kernel and initramfs paths of every menu entry, generated or manually entered. <gnucode>raghavgururajan: awesome! glad to hear it! <gnucode>I am working on my only guix related project, improving opensmtpd. And here lately I've been having a massing drawing-war with a work friend. She keeps drawing me missing teeth. I've been drawing her in return with a moustace. That's been pretty fun. :) <f3n1x>haha. I see you, with your moustace ...Never forget to have fun ! gnucode . BTW, when i grow up ;-) , me too i will run a guix server for the essential services (mail, xmpp,... etc) like you are doing. how is it going with opensmtpd ? <f3n1x>Actually, as a guix newbie, i'm having fun trying to make my laptop's wifi card work. First things first ? Let's see !... <f3n1x>Question : the manual suggests '$ guix pull' <f3n1x>'$ sudo guix system reconfigure /etc/config.scm' in order to keep guix updated. I'm missing some basics here... Is '$ sudo -i guix pull' discouraged ? If yes... why ? <tricon>f3n1x: it's not necessary if you're on Guix SD: running `guix system reconfigure ...' will use the current version of Guix for the user. <tricon>`sudo -i guix pull' is going to update Guix for the root user. <GNUtoo>djeis: AFAIK grub doesn't have the notion of subvolumes, it just sees subdirectories, and on regular distributions that is handled by generating a GRUB configuration that ends up with the right paths that work for grub <f3n1x>tricon and guixers , ah... nice to know, what confuses me is the fact that if i run 'guix pull' i can see the OS upgrading the kernel package, as long as if i run 'sudo -i guix pull' ? Is there any practical difference ? thanks, thanks, thanks <djeis>GNUtoo: I should have been clearer, I???m trying to figure out what I should put as an extra menu-entry in the bootloader section of my guix system config. <gnucode>f3n1x: definitely. :) I actually am not using guix system to run my own mail server yet...Since it is probably going to be a while before my service is merged into guix properly, I have been thinking that I should set up a channel, so that others can try out my opensmtpd service that has proper guix records. <djeis>I???ve recently moved one of my machines over to guix system, but I kept around the btrfs subvolume and /boot folder from the previous distro I was running. While I sort out all of the driver stuff with running guix system on this box I???d like to be able to boot the old distro. The obvious thing to me was to add a menu entry to the grub config guix generates, but I don???t see a way to refer to the old kernel and initrd. If I just give the paths to <djeis>those files, guix prefixes them with the path of my btrfs subvolume for the store when it generates the grub config. <f3n1x>gnucode , ah.. nice to know ! Let me know if you set up the channel. So that maybe i can try ? <GNUtoo>configfile /path/to/grub.cfg can load other other grub.cfg <GNUtoo>so just loading the grub.cfg from the other distribution maybe works, for me it always worked <gnucode>f3n1x: sounds good. I'll probably blog about it when I do. gnucode.me <gnucode>there are some example menu-entries for when I was dual booting guix and debian. <apteryx>nckx: the new block group tree btrfs option will become available only with linux-libre 6.1 <apteryx>(out of context, but I think you said it should already be available on berlin, which has 6.0.7 right now) <apteryx>it looks like deleting the huge *.bak files under /var/log/anonip/ brings the system down to its knees <apteryx>or does anonip manages the .bak and .bakbak files itself? <apteryx>and attempting to delete these somehow cause shepherd to hangup? <apteryx>so either deleteing huge files performs abysmally on btrfs (haven't seen that on my local machine, but then I don't have 5 TiB files lying around), or the SAN performs abysmally itself. <jonsger>logrotating is a bit manual on Guix :( <apteryx>yes, it's not great. I have a task to improve its guix-exposed config for a start <apteryx>you can already do everything, I think, but you'll have to stitch the various config files yourself from scratch <pkill9>I'm wondering how difficult it is to detect if substitutes are available for specific packages when upgrading profiles <pkill9>and not upgrade if none are, cos I think it's a big usability block <pkill9>it makes me not want to jam all my main desktop packages in guix home <pkill9>tbf guix home builds from manifest and doesn't use current generation at all <pkill9>infact I could probably put some code in that uses guix data service to find last version of guix with substitute for it available <pkill9>like that snippet for guix channels <pkill9>problem solved! (assuming it works) <pkill9>ty for everyone who input into this conversation <abhicherath[m]>is guix.gnu.org down? (actually, does it have a statuspage somewhere?) <gnucode>pkill9: why does guix take so long to update packages? but pacman or apt is much faster? <gnucode>pkill9 I haven't actually done any benchmarking <itd->abhicherath[m]: server doesn't look down to me, but the website doesn't load <awb999>guix substutute servers are down again. <pkill9>gnucode: I don't know the details exactly, but basically because pacman/apt is I think basically just a static database of binary files and where to get them, e.g. an sqlite database or a plaintext file (not sure the details), but guix computes the database of binary files <pkill9>assuming there are substitutes for that database available, the part htat takes the longest is computing the guix derivation, i think <pkill9>once it's got the derivation and knows which substitutes to get, then it downloads them. if there aren't subsittutes for guix available, then it's compiling all the package definitions <pkill9>i probalby didn't explian that very well, also I don't know the details, that's just what I believe it to be <lilyp>I think part of it is also the fact that guix rebuilds much more than apt or pacman <lilyp>on debian, if something needs openssl, it knows to find it in /usr/lib <lilyp>in guix, that path changes all the time so packages need rebuilding <gnucode>lilyp: ahh. that actually makes a ton of sense. <lilyp>there also seems to be some noticable overhead in doing guile things ??? adds about a second or two on bad days for startup <gnucode>hmmm. basically having a /gnu/store means updating packages will probably be a little slower. <lilyp>not that debian is better in this regard with apt being written in python <lilyp>but weird microoptimizations aside, it's basically a) more packages get rebuild and b) more source builds are done <lilyp>guix is in fact a great step upwards from gentoo thanks to substitutes, for example :) <lilyp>set up your substitute server, it's more fun than distcc <vagrantc>guix substitute: warning: ci.guix.gnu.org: connection failed: Connection timed out <apteryx>it seems to be caused by me deleting the huge (multi-terabyte) backup log files of nginx/anonip <apteryx>currently 12T out of 28T are nginx logs... <civodul>maybe you can ionice the "rm" process? <apteryx>default is best-effort, which should be ok? <apteryx>seems better! thanks for the suggestion <vagrantc>yeah, log rotation with some reasonable compression algorithm ought to help with that <vagrantc>presuming the logs are resonably compressable <gnucode>apteryx: do we really need 12T of log files? <apteryx>if it was just me, they'd go to /dev/null and the problem wouldn't exist. that said, it *could* be interesting to crunch some stats from anonymized logs, such as how many individual users are using the build farm, how much data is being pulled out of it, etc. could then be used to figure out if web crawlers are abusing it (in terms of used bandwidth). So nice theoritical applications which we <apteryx>I know that civodul has used them in the past to figure out some ration of gzip vs lzip downloads <apteryx>that data was useful and was used as one of the rationale behind sunsetting gzip substitutes availability <apteryx>but to answer your more specific question of "do we really need 12 TB of logs", no :-) <gnucode>apteryx: hahah. :) disk space is usually cheap. :) <civodul>apteryx: yeah it's nice for stats and debugging, but we surely don't need that much :-) <rekado>oh, someone just caused a full rebuild of the Java bootstrap <rekado>maybe this would have been better on a branch???? <gnucode>rekado: is there something that emails you when a full rebuild happens? Or do you manually have to check ? <civodul>apteryx: i can't seem to connect to berlin <civodul>BTW, rm (unlink(2)) is usually a cheap operation <pkill9>I see plymouth is packaged, anyone have an example of using it? <apteryx>civodul: not on Btrfs if the file is huge and/or fragmented a lot apparently <apteryx>I'm deleting the last 4.5 TB file (it's been going for a while) hold on <apteryx>pkill9: I think rekado is experimenting with it <pkill9>it creates a bootup splash screen doesn't it? <pkill9>yea, how far back does it do so? after grub I assume <lilyp>we're obviously doing this wrong <lilyp>if crypto bucks taught us anything then it's that we have to make everyone download the 4.5tb log file <Kiran>Hey everyone! What's the proper way to configure a combination of DHCP and static networking? I've tried to declare both in my system services but get the "networking is provided more than once" error. <rekado>civodul: I???m connected via SSH now <civodul>Kiran: hi! it may well be impossible right now <civodul>rekado: me too, seems to be back to normal <Kiran>Really? Even for separate interfaces? <rekado>pkill9: it???s not something you can just install and use <rekado>it needs to be part of the initrd, it needs to be configured so that it finds its plugins, it needs to be started at the right time, etc <rekado>and it still may need some patches to make it do the right thing under these hostile conditions <rekado>huh, there are no callers of make-essential-device-nodes. <apteryx>rekado: I've manually rotated the https?.access.log files; it seems nginx or anonip continues writing to the renamed files, so probably it needs to be kicked <twopubsolar[m]>can you compile haskell programs with dependencies into executables?