<mbakke>bauermann: I have not seen that message before, but then I haven't paid a lot of attention to the failing builds either... typically it seems like they fail to find some other TeX library, but it may well be due to the mentioned heap corruption earlier in the process
<bauermann>mbakke, ok, thanks. I'll try it out and see what I find
<mbakke>bauermann: I've pushed the patches to 'core-updates' now as 683eb7c5b1..f72a1253a1, so you can cherry-pick from there
<bandali>ixmpp, hey, can you please not use the Return key as a replacement for punctuation? :-)
<DynastyMic>Why is the command notify-send not working on my shell?
<bauermann>mbakke, civodul, I've just updated https://issues.guix.gnu.org/48064 with my build result. in a nutshell, there's still heap corruption, but the glibc error message is slightly different now (“corrupted size vs. prev_size”)
***iskarian is now known as Guest5806
<apteryx>should we switch to gnutls 3.7.2 on core-updates? Seems most distro are already using 3.7.
<vagrantc>shouldn't core-updates pretty much always be the latest and greatest everything? :)
<clacke>it's good to know, but in my case I've joined just one channel and it's one I have been in for years when it was on IRC
<drgibbon>Would an AppImage work on Guix, or are they incompatible?
<drgibbon>On another note, what do Guix users generally do about web browsers? I normally use Firefox, and have looked at Icecat, but the last official release looks to be from 2019, must be a raft of security holes. What is the "Guix way"?
<robin>drgibbon, getting appimages to work on guix is hellishly difficult, unfortunately. flatpak works well though
<robin>drgibbon, as for icecat, iirc it's based on LTS releases of firefox, so should get security fixes that way -- which depends on the icecat maintainers keeping up with LTS updates, of course (i don't know offhand how up-to-date icecat actually is; if 2019 is the firefox LTS release date that sounds about right, but it's a bit worrying if that's the last time icecat was updated...)
<minikN>Hello. I am using slim desktop manager together with emacs-exwm. But I would like to start a different emacs version (emacs-pgtk-native-comp from flatwhatson). Does anyone know how to do that? I think I need to add another .desktop file for slim, but I can't figiure out where/how to add one.
***Kimapr5 is now known as Kimapr
<mitzman>is it possible to refresh "hidden" packages before the first pull (or at all)?
<mitzman>or to install a package before the first pull without installing mesboot? (because I would like to install a slightly modified binutils-mesboot0, and in my local guix channel/mirror I've modified commencement.scm to have that as a replacement
<mitzman>it builds with no problem but can't seem to be able to install it without initializing everything
<solene>any idea what package I should install to have libstdc++.so.6 in my profile?
<minikN>Any idea how to change the emacs package that is used by emacs-exwm? I have emacs-pgtk-native-comp installed but when I launch emacs-exwm it launches 27.2. In my sys config the only emacs related packages I install are emacs-pgtk-native-comp and emacs-exwm. I don't know where the 27.2 version is coming from and how to change it
<solene>jonsger: still no libstdc++ in ~/.guix-profile/lib/ after installing the package, is "guix install gcc-objc++" the wrong command for that?
<yoctocell>minikN: you can override the `emacs-exwm' package and specify the `#:emacs' keyword in the `arguments' field.
<yoctocell>see the emacs-exwm package definition on line 13439 in emacs-xyz.scm
<yoctocell>the `substitute-keyword-arguments' procedure will be useful I think
<efraim>I think I'm not linking to gnutls/guile-gnutls correctly
<jonsger>nice, found a way to restrain icedoves hunger for cores :)
<joshua>hmmm, trying to set up a local dovecot to connect via gnus is weird...I've got mbsync set up...I've got a maildir in .mail/dismail.de...dovecot is running...I can telnet into the local dovecot...but I can't seem to seem to find my emails.
<joshua>and doveadm log errors shows that error in config file ssl_key: Can't open file /etc/dovecot/private/default.pem: Permission denied
<joshua>telnet localhost 143 seems to work. dovecot says it's ready.
<solene>my package works now but I had to remove "glibc" package that I installed manually
<mbakke>nss fails on current core-updates too, so it's not a GCC 10 regression
<nckx>joshua: What's the advantage of running a local Dovecot?
<bandali>gnus's maildir backend is particularly inefficient, especially for large volumes of mail. its imap backend however is super fast. so it's a common practice for gnus users to put a local dovecot in front of their maildirs and point gnus to that
<apteryx_>hi! Is someone else using ratpoison? I use the rpws script provided to enable multiple virtual workspaces; somehow there's a binding C-M-left/right that gets set to move across them (I don't think I did that); that's neat but it seems to catch any C-M-* key chords, making those unavailable to Emacs for example.
<ft>Hm. When I'm linting a package, I get a "no updater for..." complaint. I think this is due to upstream is at gitlab.com, and unlike github, there is no updater for that one, yet. A I gettings this right?
<ixmpp>Would it be abhorrent to have a `guix import nix`
<ft>Hehe. I've poked into it a little, but couldn't really penetrate it. :)
<ft>But then, I'm a novice to the guix code base. So no surprises there.
<solene>I made some progress on https://tildegit.org/solene/guix-linux-run but I'm not really satisfied :( I got a few programs working easily though and the script itself is only 3 lines, it's still easier to distribute it as an executable script though. If someone has ideas in regards to this idea improvements I'd be happy to hear
<dstolfa>solene: i wonder if integrating this in guile rather than a shell script would make a couple of these things easier as you could plug into guix itself asking it about locations of things?
<dstolfa>obviously this is just thinking out loud, i haven't actually messed with this outside of just exposing ld-linux as a special file
<mbakke>apteryx_: I reverted the commit for convenience to squash with an upgrade, and the changes to that file do not seem like an improvement to me. So I'm leaning towards keeping the revert to keep "our" history instead of a random patch. WDYT?
<mbakke>also, I'm not a fan of the "git-style" patch header, but that's a different issue :)
<jab>hey....so I'm running a local dovecot server...I've got it pointed to my local maildir at ~/.mail/dismail/ Dovecot is running, and I can connect and login as my user "joshua"...but my email address is "jbranso"...do I need to try logging in as "jbranso"?
<nckx>Guix accepting pseudonyms is itself at least a legal grey area, so we mustn't take all this too seriously. If someone steals Guix to build deathbots, the person with the deathbots will probably win.
<jab>I would not. BUT some greedy person or company might. :)
<lfam>It's not even clear what a violation would mean
<jab>lfam: selling guix system computers with additional code...and not releasing said code.
<lfam>Think about any enforcement action of civil law (and this assumes USA jurisdiction). You need standing, money, energy
<lfam>jab: Honestly, there will be some angry blog posts, some thoughtful blog posts, and that's probably all that will happen
<lfam>Just like every time this happens with other free operating systems
<nckx>lfam: <A lot of computer programmers think of licensing in the same way they think of code> I wish this were much, much more common knowledge. Programmers really excel at underestimating other fields.
<lfam>Most Linux-based appliances are already violating the licenses, and the companies are hugely successful
<jab>lfam: Hmmm. I guess I had hoped there would be some sort of push back if MS or apply started violated guix.
<jab>lfam: doesn't what's his face...software freedom conservancy occasionally do lawsuits?
<lfam>Yes, occasionally... it's not clear that it's a good strategy. Notably, the Linux leadership thinks that it is not. And they have the most successful free software project ever, so I'm inclined to listen to their advice
<lfam>This is why lawyers will always recommend you settle a dispute out of court
<nckx>jab: The SFC works on behalf of the copyright owner(s).
<dstolfa>lfam: i think i agree with the overall assertion, but other areas of speciality also have a longer history of court cases that current cases can call upon, whereas with software it's still kind of new in that sense
<nckx>dstolfa: I do think software developers have internalised a culture of ‘software is magic and not bound by your earthly laws and omg, mother, you just don't understand’ which is harmful.
<lfam>They will try to talk to the opposing lawyers directly, then they will try a formal mediation process, and only finally will they enter the courtroom. Like I said, going before the judge (or a jury, god forbid) is extremely risky
<nckx>jab: Mine's never urged me to do anything else than settle. Probably depends on where you live.
<dstolfa>nckx: i think the struggle i have with software is that it's kind of both: mathematics and engineering. it's entirely unclear to me how software should be treated in court, and in which case an engineering artefact is not the same as a mathematical description of an idea, especially when it comes to FP
<lfam>dstolfa: The problem for you and I is that, to judges, it's quite clear :)
<lfam>The complexities that we see are not relevant
<lfam>And, to each judge, it will be clear in a different way :)
<lfam>They are just people and they are all different
<dstolfa>lfam: yeah, luckily they have a contradictory law that says you can't ban books. every time Ross Anderson tells this story it's quite amusing. essentially the UK wanted to ban a few cryptographic algorithms, but they couldn't because they were all quickly published in a book, and you can't ban books
<robin>the local uni library has a copy of the PGP source-code book. that was a fun find
<bone-baboon>I have been told that `guix pull --no-substitutes` builds Guix. If I wanted to do `./pre-inst-env guix build --no-substitutes <something>` what should <something> be to build guix like that guix pull command does?
<ecbrown>bone-baboon: an example would be .... guix build .... hello
<thorwil>lfam: a description in /gnu/package/packages.scm made me aware that patches need to be directly in the dir referenced in GUIX_PACKAGE_PATH, NOT in patches right below it!
<bone-baboon>ecbrown: Thanks. I know I can do `./pre-inst-env guix build --no-substitutes hello` for example. How can I find out what packages get built when I do `guix pull --no-substitutes`? These are the packages I want to build with guix build instead of guix pull.
<ecbrown>bone-baboon: with no-subsitutes every dependent not already in the store with be build
<raghavgururajan>Interesting, the strategy of gajim-full is same as installing gajim and gajim-omemo separately. Both methods make them available in profile.
<raghavgururajan>ixmpp: Btw, have you been using 1.3.2 for a while or you just upgraded from pre-1.3.0?
<maximed>No idea what's going on, will try --target=i686-linux-gnu.
<civodul>maximed: "skipping incompatible libc.so" usually suggests this .so targets a different architecture
<iskarian>To avoid a dependency on perl from some installed source files (perl is used to generate some of those source files), would it be better to patch the shebangs back to #!/bin/perl or just delete the files?
<maximed>(Though I'd make it #!/usr/bin/env perl if feasible, as that makes more sense on Guix System)
<iskarian>Ah, this is for the Go compiler, which installs source files by default because they are necessary for Go to compile programs. The perl scripts generate some of those source files at build time, so I wouldn't expect it to make sense for them to be run again
<maximed>qemu-aarch64 /gnu/store/ghmf95ig7n3kf9wz4m8kjrcmpyzf938p-glibc-cross-aarch64-linux-gnu-2.33/lib/libc-2.33.so say ‘GNU C Library [...]’, so qemu says it is ok
<lfam>iskarian: To clarify, the Go compiler doesn't install source files by default. The Guix go-build-system does that
<maximed>fwiw, qemu-aarch64_be bails out with Invalid ELF image for this architecture
<iskarian>the Go compiler isn't supposed to include the standard library source files...?
<lfam>Oh, I don't know about that. I thought you were talking about "building Go packages with Guix"
<iskarian>it currently is unless I'm reading this very wrong.
<iskarian>So far the best direction seems to be enabling external linking for all dynamic/cgo executables, but there are some bugs with that in Go currently
<mitzman>hmm, I was reading a bit about the bootstrapping process, and came up across this: "The Guix bootstrap for x86_64 uses x86 mes and that is not expected to change.". i also saw that x86_64 mes is on its way. would that mean guix will have the possibility to be bootstrapped with the x86_64 mes?
<civodul>mitzman: first time i hear about an x86_64 mes; currently Guix uses i386 mes on x86_64, and that's good
<vagrantc>maybe it'll actually break the barrier to producing arm64 installer image (er, aarch64, oops!)
<vagrantc>i've had some luck making live images for debian, maybe i'll make one with guix preinstalled :)
<maximed>on core-updates, guix build --target=i686-linux-gnu succeeds with building a cross toolchain, but fails during configuration of 'hello'. Will investigate later.
<maximed>‘configure: error: C compiler cannot create executables
<mitzman>civodul: i will, i'll investigate a bit more about the cause, and solution. (maybe patching bash-mesboot to not have a test builtin is a better solution?). it's basically a fork of grapheneOS kernel, named "linux-hardened" on arch