<str1ngs>janneke: also pushed some minor fixes for Emacsy's 'end-of-line <vagrantc>janneke: hurd's moving at glacial speed ... so it's going pretty fast now? :) <Formbi>str1ngs: so is it now possible to properly use C-m as RET? <Formbi>currently I have a thing that does (insert #\newline), but it acts like C-j in Emacs <str1ngs>though (insert #\newline) should replicate that <str1ngs>Formbi: does this work for you? (define-key global-map (kbd "C-m") (lambda _ (insert #\newline))) <nckx>pkill9 <instagrafting>: A fork exploring that would be interesting to watch, but I don't think it would get very far. Different minor/patch versions of packages regularly add or remove dependencies and features, break compatibility with the previous dot release, and introduce new behaviour and bugs. <nckx>Even identical VERSION fields can identify completely different package expressions with wildly different dependencies causing totally different build results. Things quickly become undebuggable. Yet another non-functional package manager--just the ebuilds are written in Guile now. <vagrantc>wow. "guix build iwd" on armhf is triggering a kernel panic! <nckx>Er, I'd heard the build was broken but they forgot to mention that detail. *vagrantc is filing a bug report <vagrantc>maybe it doesn't kernel panic all systems... <vagrantc>apparently, i have a local patch to remove it as a network-manager dependency from early/mid june ... so clearly i should have filed a bug a long time ago :/ ***ChanServ sets mode: +b *!*@xmpp.snopyta.org
***gyuiste was kicked by ChanServ (User is banned from this channel)
*vagrantc should try building iwd on different hardware to see if it's the same problem <vagrantc>anyone want to help troubleshoot new diffoscope test suite failures? we're a few versions behind and i haven't been succesful at figuring out what's breaking <raghavgururajan>> [07:29:27 PM] gyuiste has been kicked by ChanServ: User is banned from this channel *vagrantc has trouble figuring out how to debug pytest under guix <nckx>That is not a value judgment. If nobody in #guix is using snopyta except one, and that person is bad, snopyta is the best pattern to ban. ***ChanServ sets mode: -b *!*@xmpp.snopyta.org
<raghavgururajan>I primarily use disroot.org, but it their network is down, I use snopyta.org as secondary backup. 😅 <nckx>raghavgururajan: So is kiwiirc and many others. They are also abuse magnets. I had never heard of snopyta. <nckx>A ban pattern is just an imperfect technical solution and does not impugn anyone's niceness. *nckx welcomes all of snopyta. <Formbi>str1ngs: I have that particular thing *nckx welcomes all subnets and ptrs! <raghavgururajan>The last thing I want to see is "raghavgururajan has been kicked by ChanServ: User is banned from this channel". <Formbi>and when I press C-m when I'm in ibuffer, it just inserts a line and doesn't switch to a buffer <nckx>raghavgururajan: I understand, but nor do I want to see multiple porn links. Hence ‘imperfect’ 🙂 *raghavgururajan knows the best intentions of nckx :-) <nckx>That said I usually set ‘spam’ as the ban reason instead of none (which gives you the generic ‘User is banned...’), that was an oversight on my part. <nckx>‘User’ makes it sound personal and I understand why it felt that way. ***gyuiste is now known as guiyrte
<nckx>Sorry about that. Welcome! <guiyrte>Anyway, I wanted to ask, if I need to restart the machine after installing guix on debian. <nckx>guiyrte: snopyta was previously abused by a spammer. <guiyrte>It is a running server. So I am icky to restart <nckx>guiyrte: You don't strictly need to, but I don't know the exact command(s) needed to apply the changes. ‘. /etc/profile’ is one of them. <vagrantc>shouldn't need to reboot after installing guix... <guiyrte>Okay. I am connected from dismail via snopyta though. <vagrantc>presuming you've edited the appropriate ~/.bash* or other files <nckx>Shouldn't /etc/profile.d/guix-whatever take care of that? If not, can it be fixed to do so? <vagrantc>oh, didn't know there was a profile.d snippet :) <nckx>Not to contradict vagrantc. Just: enough bugs have been caused by new users adding random things to ~/.bash* that I'm weary. ***caleb_ is now known as KE0VVT
<vagrantc>been a while since i installed guix on anything but guix ... *nckx will not for AFK they go. <nckx>vagrantc is better hands than I am on a foreign distro. Good luck! <vagrantc>you'll need luck if all you have is my half-remembered advice :) <str1ngs>guiyrte: you do not need to restart the machine assuming you used guix-install.sh? ***ezzzc63 is now known as ezzzc6
***jonsger1 is now known as jonsger
***ezzzc67 is now known as ezzzc6
<nckx>New in Linux 5.8: BCACHE_ASYNC_REGISTRAION <nckx>Just in case you ever feel bad about a typo you pushed. <jackhill>nckx: ha! Thanks for that. I'm usually the typo-prone one in my circles! <raghavgururajan>It took 15min for `guix build` command to even show 'the following derivations will be built'. <nckx>raghavgururajan: I didn't see anything odd. I'll take another look. <nckx>Hah, well, it's currently building 12 packages, 5(!) of which are iso9660 images. <nckx>I suspect that's all, and things will return back to normal. <nckx>It's not ideal to build these all at once on rotating drives. It's much slower than one at a time. But that's Cuirass: it doesn't know that. <raghavgururajan>Rotating disks are bottle-neck. Any plans to replace them with SSDs? <nckx>Not that I know of. I don't think it's been discussed. <nckx>raghavgururajan: Bayfront has two 4 TB hard drives in a RAID10 configuration (2.8T of 3.6T used). We could probably get away with less but that's still 2 expensive SSDs. <nckx>Someone adding bcache support to Guix would be more cost-effective... 😉 *raghavgururajan looks at the cloud <nckx>I cannot imagine that being cheaper and more performant than either local HDDs or SSDs. 😳 <nckx>That said it is not a market I'm at all familiar with. People sell cloudy block devices now? Zany. *nckx thought ‘on a Linode’ was deliberate 🤷 *nckx -> zzz. Good night everyone. <sneek>Welcome back vits-test, you have 1 message! <sneek>vits-test, str1ngs says: I will see what I can do about *Messages* buffer. thanks for testing it's appreciated. <raghavgururajan>sneek: later tell nckx: Is bayfront back to being busy again? That is, the state where it was under routine build and gc, two months ago? I am stuck gc lock again. :( <raghavgururajan>sneek, later tell civodul: Do you find the newly revised article from Oliver good for publishing? *tmp-nick-vits `(,@(alist-delete "mailutils" (package-inputs emacs))) || fuuuu.jpg *tmp-nick-vits Die schlau Germans: "dick" means "thick". Ama not wanna be thick. <cheim0>vits-tmp-sorry: I too have been thinking about mailutils@3.10 <vits-tmp-sorry>cheim0: It builds (is mailutils just for POP3 (do i read the comment right)?): <str1ngs>vits-tmp-sorry: if you don't use mailutils then pop3 is not secure. if you don't use pop3 you should be okay ***vits-tmp-sorry is now known as vits-test
<cheim0>vits-test: yes you understood my comment :) <vits-test>cheim0: Great. Now Emacs has pictures & Meta-sends-escape. <apteryx>hmm, how do I run the daemon locally? sudo -E ./pre-inst-env guix-daemon --build-users-group guixbuild --substitute-urls='https://ci.guix.gnu.org' --max-jobs=4 works, but then it fails finding the signing keys because it looks under /usr/local: guix offload: error: getting status of `/usr/local/etc/guix/signing-key.sec': No such file or directory <apteryx>I've reconfigured my checkout with ./configure --localstatedir=var --sysconfdir=/etc but still (I haven't ran make clean-go -- should I?). ***apteryx is now known as Guest19503
***apteryx_ is now known as apteryx
<zjgkkn>vits-tmp-sorry: Thanks! Now i can install emacs. <zjgkkn>Now it's building rust compiler chain since 1.19 to build icecat. Guess it will be long on 2006 CPU. ***jess is now known as meow
<jonsger>zjgkkn: you should get substitutes for them ***meow is now known as jess
<nckx>Every Web site needs a nice Guix logo! ‘NGOs’ is probably not a good fit for us, though. <sneek>nckx, raghavgururajan says: Is bayfront back to being busy again? That is, the state where it was under routine build and gc, two months ago? I am stuck gc lock again. :( <nckx>I know that's an old message but bayfront is completely idle (both CPU and I/O) at this time. <nckx>GCs on CI/substitute servers (which deliberately keep huge stores) with spinning drives (to store said stores affordably) simply takes a long time. It's all done while holding an exclusive lock to keep the code simple and minimise the chance of bad things happening, but it's very inefficient. <PurpleSym>xournalpp is crashing with the following error on a foreign distro: Gtk:ERROR:gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Icon 'image-missing' not present in theme Tango (gtk-icon-theme-error-quark, 0) <sneek>civodul, you have 1 message! <sneek>civodul, raghavgururajan says: Do you find the newly revised article from Oliver good for publishing? <civodul>raghavgururajan: sure, i'll have to look <civodul>(great if someone else does, too :-)) <efraim>does anyone have a libproxy.so.1? I'm touching up the efl definion in preparation for efl-1.25.0 <efraim>it's nice that bayfront has plenty of space again, I'm just glad I added diffoscope to my profile there. rebuilding ghc daily wasn't fun <andreas-e>efraim, I do have a libproxy for x86_64 on my laptop. Do you want me to send you a "guix pack" of it, or what is your purpose? <efraim>andreas-e: what package does it come from? <efraim>I couldn't find a copy of it on my machine or on bayfront <efraim>... I guess that would be fairly obvious <apteryx>is there any tool that's similar to 'time' except willa also report the max RAM the process used at the end of it? <civodul>time(1) (the command, not the shell built-in) shows that under "maxresident" <apteryx>I did have to run distclean in order for my local guix-daemon to honor --sysconfdir <apteryx>should we add this --sysconfdir=/etc in the manual? It seems useful next to the mention this, close to where the suggested command to run the guix-daemon from a checkout is. <efraim>'git clean -dfx' is probably faster :) <apteryx>ah, thanks, I should have thought about that :-) <apteryx>civodul: I'm testing your guile-ssh bugs workaround <apteryx>using offload on core-updates was near unusable in the current state, so that'll be a good test <civodul>i mean, good that you're testing :-) <civodul>i'm surprised you had to "make distclean" <apteryx>the 'guix' from my checkout was using /etc as sysconfdir following a configure && make, but the local guix-daemon was still using /usr/local until I ran make distclean. <apteryx>probably all that was required was rebuilding the daemon cleanly, so I guess the 'git clean -dfx' suggested by Efraim would have been sufficient. <civodul>apteryx: i think ./configure regenerates config.h, and thus "make" rebuilds the daemon <roptat>I'm trying to get a new project approved at savannah that will contain our translations, so we don't need to give weblate access to our repositories directly, and it appears that the copyright in our po and pot files are not very consistent <roptat>they're either copyrighted to you, the FSF or the authors of Guix <bandali>i'm around btw, if y'all need to chat about that <roptat>bandali suggested to use only "the authors of guix" and I agree, but I guess I need more opinions on that :) <bandali>:-) yeah, i didn't look around for other non-FSF-copyrighted GNU packages on the translation project to see what the common practice is <civodul>roptat: i'll reply by mail later, but i'm definitely not a copyright holder on the translations <civodul>so perhaps it's a misconfiguration in our gettext machinery? <civodul>i believe individual translators are the copyright holders <bandali>for the original texts, i'd assume the copyright holders would be those who wrote that particular string originally in the guix.git repo <rupicapra[m4>Does the configuration of emacs-EXWM happen inside emacs or a separate file? <bandali>either in ~/.exwm or in your regular emacs init file <rupicapra[m4>Works fine in emacs init, I was having some issues. Weird. ¯\_(ツ)_/¯ <apteryx>I'm trying to get untruncated backtraces using a locally started daemon, but this doesn't seem to work: export COLUMNS=200; sudo -E COLUMNS=200 ./pre-inst-env guix-daemon --build [...]. What am I doing wrong? <andreas-e>civodul: Nice idea to add a "getting started" chapter to the documentation. <jeko>Hey! Emacs seems broken because of an error in EMACSLOADPATH <chaosmonk>hi, i am trying to get into guix packaging and need some help. if i define a single package in a file i can build it with "guix build -f /path/to/file.scm", but i can't figure out how to test an actual change to guix's source tree <chaosmonk>i would expect "guix build -L /path/to/guix $PACKAGE" to work, but i get an error: <chaosmonk>guix build: error: /gnu/store/jzhv2rjgppspvg9kgap7l0zn5p9xbdk4-tar-1.32 (system: i586-gnu) has no substitute <chaosmonk>i would expect adding "--fallback" or "-s x86_64-linux" to avoid the need for that substitute, but i get the same error with either <vits-test>chaosmonk: You need to `git clone` the guix repo, make changes to one of gnu/packages/NAME.scm, and test it. <chaosmonk>is "guix build -L" the wrong command to test it? <vits-test>chaosmonk: cd git/guix; guix environment --pure guix <vits-test>./bootstrap && ./configure --localstatedir=/var && make -jCORES <rekado_>chaosmonk: yes, use ./pre-inst-env guix build instead <rekado_>but only after building Guix as vits-test wrote <chaosmonk>vits-test, rekado: thank you, that seems to be working <vits-test>chaosmonk: try same as rekado said, but with `guix lint`. It catches and reports things (if any) that are wrong. <joshuaBPMan>hey #guixoids! We should have a guide about how to run guix system on a linode server in the cookbook soon! I've just sent an updated patch! <nckx>vits-test: `nproc` for a placeholder that placeholds itself. <vits-test>nckx: Once i get "command not found". Can't reproduce it now. <nckx>vits-test: It's part of coreutils, so it will be available in any realistic scenario. *vits-test looks strangely <chaosmonk>vits-test: the only output of "guix lint" is "source not archived on Software Heritage". does that require action on my part before submitting a patch? <vits-test>chaosmonk: Do You know how to make and send the patches? <chaosmonk>vits-test: i've done it before with git send-email <chaosmonk>vits-test: thanks for the help, have a good day <jeko>$ emacs src/fr/SUMMARY.md src/en/SUMMARY.md <jeko>Warning: Lisp directory '/home/jeko/.guix-extra-profiles/jeko/jeko/share/emacs/26.3/lisp': Aucun fichier ou dossier de ce type <jeko>Warning: Could not find simple.el or simple.elc <jeko>The EMACSLOADPATH environment variable is set, please check its value <jeko>Cannot open load file: Aucun fichier ou dossier de ce type, package <jeko>I manually edited EMACSLOADPATH and it worked <apteryx>jeko: so you are using a custom profile. Did you source its etc/profile to activate it? <jeko>it should point to '/home/jeko/.guix-extra-profiles/jeko/jeko/share/emacs/27.1/lisp' <jeko>hmmmmm i should, have to check my .profile <apteryx>hm, perhaps related to the recent upgrade from Emacs 26 to 27. There's a hardcoded version in the search-path specification that probably was forgotten. <jeko>should I open a bug to check out ? <apteryx>if it was indeed forgotten, it'd be broken for everybody using emacs, so I'm skeptical <jeko>agree, I should double check my setup <jeko>don't waste too much time on it haha <apteryx>the emacs package definition is correct <apteryx>jeko: perhaps you simply landed on a broken commit? <apteryx>That would be 0ec6b8afd7e7a6c288fbf48c5779f2e0bdaffb55. What does your 'guix describe' says? <apteryx>in doubt, run 'guix pull' and update your profile <nckx>My emacs refused to start after the update to 27, the error was the same or very similar. I got rid of it by rebooting... <nckx>...don't judge me, I *needed* e-mail 😉 ***caleb_ is now known as KE0VVT
<pancak3>Formbi: How's the packaging of gccemacs coming? I can't get past the "ld: cannot find..." problem :/ <lispmacs[work]>hi, I tried to update libreoffice yesterday but the build fails with an assembler error "operands mismatch for movq". Was wondering if somebody else was already reporting this. <lfam>lispmacs[work]: How much RAM did you have? *vits-test giggles "enough!" <lispmacs[work]>lfam: I can't remember checking at that time, but I currently I am using 3GB out of 8GBs available <nckx>lispmacs[work]: Updating to Guix's latest version (6.something) or upstream's (7)? <nckx>I assume you mean 7; the latest Guix version builds fine here. <apteryx>lfam: IIRC, bug #41132 was fixed, correct? <lispmacs[work]>nckx: I run git pull which took me to 46eb357973f711b59bb1312025c9248010dc1040 <simendsjo>I'm tryng to run `./pre-inst-env guix edit font-iosevka`, but I get the error `guix: edit: command not found`. Running `guix --help` shows that edit is an option. Why doesn't it work? <simendsjo>.. maybe the build is incorrect. Running `make check` says `Error 2` although I don't see any failing tests. I guess I'll try from a clean start again. <str1ngs>nckx mu was not built with mu4e, though it's resolved now. regards to Emacs 27.1 <str1ngs>simendsjo: are you in a guix environment? i think you are using foreign distro? <lfam>apteryx: I don't think so. I had to work around it <lfam>It's possible the bug report is misguided <simendsjo>str1ngs: Yes, foreign distro. `guix environment --pure guix`, then `./bootstrap`, `./configure --localstatedir=/var`, `make check` <lfam>simendsjo: It's possible that "edit" is not the command that cannot be found <lfam>For example, it could be trying to start an editor and failing <simendsjo>So `%shell` is #f rather than a string. Why is that? <apteryx>lfam: OK. I thought it had to do with pango not supporting the ghostcripts fonts used as fallback, and that deja vu was selected as a replacement for ghostscript in our fontconfig default configuration. <unckx>lispmacs[work]: Did you deliberately disable substitutes? It looks like the latest LO is available on ci.guix.gnu.org, although I'm not on Guix to test. It's definitely on guix.tobias.gr. <lfam>apteryx: I did supect that #41132 was an unintended consequence of the pango / ghostcript workaround <str1ngs>simendsjo: does make exit with status 0? <civodul>hey roptat! so we can have guix-website.pot at the TP :-/ <unckx>lispmacs[work]: Looks like it's not built after all. I wonder why (will look into it later). You're welcome to use mine. <apteryx>lfam: I've done a successful experiment of validating the linux-libre tarballs after cleaning them up with the deblob-check script. If you'd like to review it, it's in #43160. *str1ngs does the thriller dance ***caleb_ is now known as KE0VVT
***amiloradovsky1 is now known as amiloradovsky
***caleb_ is now known as KE0VVT