IRC channel logs


back to list of logs

<bauermann>mbakke, ah, darn. do you know if TeX Live 2020 still leads to the same error message from glibc about `realloc(): invalid next size`?
<ixmpp>can i use (setenv) in places i use (invoke) with it actually setting env in the script, and not during build?
<ixmpp>or is there something else i should be using to set env in a service script
<dstolfa>ixmpp: you can do setenv followed by an invoke and it will do what you expect it to do
<dstolfa>you might want to use with-environment-variables if you need it to be restored
<ixmpp>i do not 😀
<dstolfa>in that case, setenv + invoke should do it
<ixmpp>i also want it to prepend/append to pythonpath
<ixmpp>is there a cleaner way to do that
<ixmpp>or just getenv/setenv
<dstolfa>hmm, i think just getenv/setenv/string-append really
<ixmpp>ok 🙂
<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
<bauermann>ah, nice! I'll just use core-updates itself
<daviwil>Anyone run into an issue with the Guix graphical installer where there's an error with stack trace right after manual partition creation is finished?
<daviwil>Seems related to this issue:
<dstolfa>can't say that i have... daviwil it might make sense to share the configuration that was generated?
<daviwil>dstolfa: Haven't gotten that far yet, it crashed before the installer generated the config
<dstolfa>oh, hm
<daviwil>I can definitely do everything via the shell but I'm working on an installation guide that uses the graphical installer, so it'd be nice if it worked
<dstolfa>yeah, the installer should definitely work. i used it like a week ago and had no issues, i wonder if it's an issue dependent on the system? i installed on an nvme drive and a comet-lake cpu
<daviwil>I am also installing on an NVMe drive. One wrinkle here is that I'm installing on a system that already had a Guix installation and also has a Windows partition, so it's a bit of a mess
<dstolfa>hmm, i could try this tomorrow in KVM to see if i can trigger it
<dstolfa>daviwil: is it a consistent failure, or does it work sometimes?
<daviwil>I keep trying over and over, it's very consistent
<dstolfa>that's good at least
<daviwil>Even when I delete and recreate the partition myself in parted
<daviwil>Actually, I used cfdisk for that
<dstolfa>hm, reading through that issue it does seem very plausible that it's caused by that
<dstolfa>it would be very helpful to reproduce this in a qcow2 image that can be shared around
<dstolfa>some people in the issue seem to think it's because a GPT partition already exists there
<dstolfa>does it work if you delete the GPT partition table first and then try to run the installer?
<daviwil>Wouldn't that wipe the whole drive?
<dstolfa>ah yes, i was in the world of VMs... sorry :D
*dstolfa is a bit tired
<daviwil>That's OK! My goal is to avoid having people wipe their whole system to get this installed
<dstolfa>yeah, having to wipe everything from the system in order to install something isn't a very strong selling point :)
<dstolfa>maybe lfam will have input on this
*dstolfa looks at sneek
<drakonis>that's a good plan.
<daviwil>I sent an e-mail on the bug thread to offer my help to diagnose and fix the issue with my current partition config, we'll see how it goes!
<apteryx>weird, visiting ~/.authinfo.gpg in Emacs doesn't decrypt the file transparently anymore
<drakonis>i'm mildly stumped now, how do i set up a mail server with guix lol
<drakonis>i have dovecot but i'm not keen on the rest of the details
<drakonis>is there any example code for a mail server with guix?
<apteryx>restarting emacs fixed that oddity.
<apteryx>drakonis: I'm not sure something ready made exists yet; for one thing there's a long standing configurability problem w.r.t. setgid configuration for postfix, IIRC.
<ixmpp>my system reconfigure is hanging
<ixmpp>after "bootloader successfuly installed"
<ixmpp>it doesn't seem like this is one of my changes, cause i've commented out the bulk of them
<ixmpp>anyone have a clue what might do that
<dstolfa>that's... ungreat
<ixmpp>i literally don't know what to do here
<dstolfa>ixmpp: uh... neither. the only option i can think of is ^C but it doesn't sound like the greatest idea
<dstolfa>it's probably worth sharing the config that caused this and reporting a bug
<dstolfa>chances are you aren't the only one that will hit it
<dstolfa>like regardless of how messed up your config is, it shouldn't just deadlock right?
<dstolfa>(i'm assuming it's waiting for something?)
<dstolfa>or did it just like straight up die
<ixmpp>dstolfa: it just stops, deadlock by the looks of it
<ixmpp>i figure i might have some mem corruption cause i also have a load of zombies
<ixmpp>i'm gonna reboot
<ixmpp>at least it did install the bootloader :p
<ixmpp>ah, can't even reboot 😀
<dstolfa>uh oh
<ixmpp>reboot -f it is
<ixmpp>see you soon, hopefully
<ixmpp>ok back
<ixmpp>IO issues, i'm guessing
<ixmpp>sorry for the inconvenience
<ixmpp>i've done it again
<ixmpp>it's not IO issues
<ixmpp>i think i'm making shepherd hang
<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 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? :)
<drakonis> this is pretty cool.
***modula is now known as defaultxr
***jpoiret4 is now known as jpoiret
***link2xt is now known as Guest7644
<apteryx>mbakke: thanks for your work on TeX Live 2020. I had looked at the patches summarily, didn't have something to say :-).
<clacke>> clacke, projectmoon: that bridge has one massive bug: you can never leave a room
<clacke>ixmpp: oh yeah, so I've been told
<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
<drgibbon>ok no problem
<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 in my profile?
<jonsger>solene: gcc-toolchain
<solene>jonsger: if I install gcc-toolchain, should I expect that lib in ~/.guix-profile/lib/ ?
<jonsger>nope, gcc-toolchain doesnt have it only the gcc package. But that one is hidden. What is your goal?
<solene>jonsger: years ago I was doing this to run linux binaries LD_LIBRARY_PATH=~/.guix-profile/lib/ ~/.guix-profile/lib/ ~/somebinary
***lastebil_ is now known as lastebil
<solene>but when I try it now, i'm missing
<jonsger>solene: gcc-objc++ is what you want
<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
<jonsger>solene: you need the library output so `guix install gcc-objc++:lib`
<minikN>Let me take a look (still new to Guix)
<solene>jonsger: yeah \o/
<solene>it works, thank you
<yoctocell>minikN: something like this: (untested)
<yoctocell>oh, s/emacs-xyz/emacs-exwm
<minikN>I'll try it
<minikN>It doesn't need a (name "...") ?
<yoctocell>i don't if it actually needs, it might conflict with the original emacs-exwm if you install both...
<yoctocell>it's probably a good idea to change the name though
<minikN>yoctocell: Unfortunately I'm getting: bad use of '_' keyword. line 75
<yoctocell>minikN: hmm, i think you need to import (guix utils)
<solene>how is named ~/.guix-profile/lib/ on arm64? ld-linux-aarch64 or ld-linux-arm64?
<mbakke>solene: /lib/ according to (gnu packages bootstrap) :)
<minikN>yoctocell: It finally went through. No errors, but if I log into slim now it's still 27.2 :/
<yoctocell>minikN: umm, that's weird, i don't use exwm so i'm afraid i can't help you with that
<minikN>Well it sort of makes sense. If I do `which exwm` the output is `/run/current-system/profile/bin/exwm`, which contains this:
<minikN>And there it's set to 27.2, but I don't know where thats coming from
<solene>does packages and libs installed globally system wide appear in your ~/.guix-profile/ profile?
<solene>I made a git repo for this and I want to turn it into a package for guix
<solene>this is a wrapper to launch binaries
<solene>but this requires a few packages installed to have libs in your profile
<minikN>solene: ~/.guix-profile/bin does only contain packages installed with guix install I believe
<minikN>Oh you probably werent talking to me :D
<yoctocell>minikN: looking at the package definition for `emacs-exwm', it references the `emacs' input, which seems to point to emacs-27 and not emacs-pgtk-native-comp
<joshua>Hey #guix! does guix have a decent method of storing user passwords in the guix config file...I'm thinking about how I would save my current isync set up...
<minikN>yoctocell Yeah well didn't I change that with overriding the package?
<yoctocell>maybe you could look at the build script for `emacs-exwm', it ends with .drv
<minikN>yoctocell: I have mutiple *-emacs-exwm-0.24.drv's in /gnu/store
<raghavgururajan>Hello Guix!
<yoctocell>minikN: hmm i don't have a good way to figure out which one corresponds to which package
***Guest7644 is now known as link2xt
<yoctocell>ah, I think guix gc --derivers should do the trick
<yoctocell>then look for the builder script in the .drv file, it should contain `builder' in the file name
<yoctocell>you might also want to enable `guix-scheme-mode' if you use emacs-guix
<yoctocell>joshua: I don't think guix offers anything like that, but you can workaround your problem by setting the `PassCmd' option in your mbsyncrc
<yoctocell>and then use pass or gpg to retrieve the password
<irfus>minikN: iirc, emacs-pgtk is, by design, incompatible with exwm
<minikN>Hm... I thought emacs-pgtk enables wayland support which in turn is incompatible with exwm. But I'm using X.
<irfus>I was able to make a variant of emacs-exwm that used pgtk but it didn't work. Ultimately, only using emacs-native-comp without pgtk
<irfus>minikN: see ^ for how the variants were defined
<minikN>And emacs-exwm-pgtk doesn't work?
<nckx>Morning Guix.
<irfus>I never got it to work with pgtk. Got a blank screen, no modeline, broken.
<irfus>ymmv, see for yourself.
<minikN>Hm okay... but at least you were able to start it.. I'm strugging to do that.
<solene>how can I define a dependency on gcc-objc++:lib in a package definition? Would it work as an input?
<nckx>joshua: Here's mine, for example, it's… acceptable:
<pkill9>is there a way to create a gcroot for a specific store item?
<pkill9>so just taking the path to the storeitem and protecting it from garbage collection, without relying on `guix build`
<efraim>hmm, build guix from sources, now 'guix download' works but 'guix build' with downloading doesn't work
<efraim>'failed to run download program' sound familiar to anyone?
<nckx>pkill9: Simply so: sudo ln -s /gnu/store/keepme-plz /var/guix/gcroots/my-cool-root
<mbakke>does 'nss' build on core-updates currently? it does not work on my GCC 10 branch, nor any newer version.
<mbakke> #10: Dbtest r/w succeeded in a readonly directory 0 - FAILED
<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/ 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>I have an issue making a new package coexist with other packages, any clue?
<solene>guix install: error: profile contains conflicting entries for glib
<raghavgururajan>solene: What you need is copy-build-system.
<solene>raghavgururajan: I'm already using copy-build-system
<raghavgururajan>solene: Ah Okay, I was reading your older messages.
<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
<nckx>Aha. Thanks Bandali.
<nckx>I wondered if I was missing out on something but use mu4e, which (whilst not as fast as I'd like) is fast enough that it probably wouldn't make the same difference.
<dstolfa>does anyone start emacs as a daemon in guix? i can write a service for it in my configuration but i wonder if there's something there already?
<tissevert>hey guix
<nckx>dstolfa: I run it as a user service, which means you manually invoke ‘shepherd’ as you somehow™ when you log in.
<nckx>Here, through .config/sway/config.
<dstolfa>nckx: thanks
<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.
<nckx>Link that won't expire for the benefit of time-travellers in the boring direction:
<apteryx_>yeah, the only 'rpws' thing I do is this line in my ~/.ratpoisonrc: exec rpws init 4 -k
<minikN>I'm trying to make emacs-exwm run emacs-native-comp instead the default 27.2. I have in my config. I install it alongside emacs-native-comp. Still when running exwm through slim, it starts up 27.2. What am I missing? Full config:
<ft>Hm. When I'm linting a package, I get a "no updater for..." complaint. I think this is due to upstream is at, 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`
<nckx>ixmpp: It was just removed.
<nckx>So no, not at all, provided someone maintains it again :)
<nckx>ft: That's probably it. See guix refresh --list-updaters for supported upstreams.
<ft>nckx: Yeah, I've looked at that and there is none for gitlab. Thanks for confirming!
<nckx> is in html-updatable-package?, but that's a bit of a desparate last attempt updater TBH.
<nckx>I guess it no (longer?) worky.
<nckx>Which package?
<ft>nckx: Well, one I started to see if I can get it into guix. :)
<ft>nckx: But guile-git seems to have the same issue.
<ft>gnu/packages/guile.scm:793:12: guile-git@0.5.1: no updater for guile-git
<ft>And guile-git is at gitlab too.
<vldn>how to activate a guix profile manually? like instancing the shepard service, exporting all paths etc.
<vldn>and how to install guix and the store in other directorys then /gnu/store and /var/guix, like /home/user/gnu/store and /home/user/var/guix?
<nckx>ft: Oh, it's because it only supports url-fetch, not git-fetch.
<ixmpp>vldn: That'd break all substitutes btw
<ixmpp>You'd build everything from source, a-la gentoo
<vldn>then i try to symlink on my android xD
<nckx>vldn: You can do so by building Guix from source (power user tiem) with --with-store-dir=/home/you/gnu/store (*super* power user tiem), with the caveat that ixmpp notes and probably others.
<nckx>It can be made to work but it's honestly not recommended. That said, go nuts.
<vldn>and this: how to activate a guix profile manually? like instancing the shepard service, exporting all paths etc. ?
<nckx>Don't forget --localstatedir=/home/you/var/guix to explore even more untested parts of the matrix.
<nckx>Dunno vldn.
<vldn> GUIX_PROFILE=/the/profile; . "$GUIX_PROFILE"/etc/profile" doesn't start shepard
<nckx>Sorry, just …/var, no /guix.
<ft>nckx: "It" being html-updatable-package?
<nckx>Yeah, it's made explicit in (guix upstream)'s url-predicate.
<nckx>I've never actually read the updater code before.
<nckx>It's, er, complex.
<nckx>For good reason I'm sure.
<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 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
*dstolfa -> walk
<solene>dstolfa: I don't know
<solene>I'm not fully understanding what I'm doing :-)
<jab>Hey #guix people!
<solene>hello jab
<jab>solene: nice bit of code you've got there!
<raghavgururajan>Folks, does Guix uses groups nobody and/or nogroup?
<nckx>Yes raghavgururajan. ‘And.’
<nckx>Hi jab.
<raghavgururajan>nckx: Hmm. Are they hidden from output of `groups` command?
<jab>hey nckx! Good to see you! It's me joshuaBPMan (I've changed my name...rms was already taken).
<jab>raghavgururajan: I was just about to ask that.
<nckx>Hah, I just asked someone else whether they were you! I… guess not.
<nckx>raghavgururajan: ‘groups nobody’ works here.
<nckx>Note that ‘groups’ alone prints *your* group memberships, and you shouldn't be in nogroup.
<nckx>Nice to see you here too.
<mbakke>apteryx_: do you remember why you made the changes to nss-3.56-pkgconfig.patch in ced3d5cbf99eac429a45e33191335ec0662f1df3?
<sharlatan>hi, does development of guix have some roadmap or short/long task list>
<nckx>sharlatan: There are and . I didn't read them in detail to see if they're still up to date/realistic.
<nckx>Some seem… iffy.
<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> 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" I need to try logging in as "jbranso"?
<jab>to view my emails?
<muradm>hi, elogind seems to be outdated. when trying to use sway it fails with missing dbus service method SetType, is there any pending elogind updates?
<jab>muradm: I am using sway right now. works just fine.
<muradm>on the other hand, i updated elogind locally to latest, but faced another issue with sway, wlrooots gets permission denied
<jab>Are you using "%desktop-services" instead of "%base-services"?
<jab>%desktop-services sets up various stuff for you that enables sway to work.
<muradm>jab: I use %base-services + some additions to go minimal
<muradm>jab: how do you start sway?
<jab>muradm: that's fine. I personally could never get sway to start via %base-services. As soon as I switched to %desktop-services, my problems went away.
<jab>as to how I start sway...
<muradm>jab: do you run elogind?
<jab>just a sec
<jab>muradm: yup. %desktop-services sets up elogind for me. :)
<jab> exec dbus-run-session sway
<jab>in .bashrc
<muradm>jab: i don't run desktop services from guix os configuration, on login I start user specific shepherd and run everything from it
<muradm>i see..
<jab>muradm: best of luck!
<ixmpp>raghavgururajan: hey, i can't get omemo working right
<ixmpp>what's the story with gajim-omemo and gajim
<nckx>Oh, it was you all along.
<nckx>jab: You can configure Dovecot any which way you want, you just have to keep the mapping straight. See (at least) auth_username_format, auth_default_realm.
<jab>nckx: thanks!
<ixmpp>bdju; did you get gajim-omemo working?
<bdju>ixmpp: not the package. ended up cloning the gajim plugins repo and manually placing files in a certain spot
*pkill9 has discovered the wonder of guile-ncurses
<ixmpp>good lord what
<jab>Hey nckx, apparently my dovecot config has an issue too... "doveadm log find" gives me this error:
<jab>doveconf: Fatal: Error in configuration file /etc/dovecot/dovecot.conf line 141: ssl_key: Can't open file /etc/dovecot/private/default.pem: Permission denied
<jab>su; cat /etc/dovecot/private/default.pem does show me what looks like a proper ssl key.
<jab>sudo herd status dovecot shows me that dovecot is running
<jab>also "doveadm log find" is supposted to tell me where the dovecot log file is.
*nckx returns from what sounds like a distressed cat in the woods without result.
<jab>jab: I suppose maybe I should disable the ssl_key...maybe...? it's not like dovecot needs TLS since it's running locally and I'm connecting on port 143, which is unencrypted.
<nckx>jab: I can only say that ‘sudo doveadm log find’ returns /var/log/{stuff} here.
<nckx>jab in deep conversation with self.
<nckx>Without sudo, I get doveconf: Fatal: Error in configuration file /etc/guix/mail/dovecot.conf line 50: ssl_cert: Can't open file /etc/tls/ Permission denied
<nckx>but that's expected.
<jab>nckx: ahh. that's what I was doing wrong...I was not running the command as root.
<jab>I think I'm going to disable dovecot's tls and ssl support. I am connecting locally via plaintext auth...
<nckx>I'm guessing 98% of Dovecot features are going to be overkill for that, yes.
<jab>nckx: thanks! I'll let you got back to chatting with yourself. Thanks again for being super helpful pal!
<nckx>solene: Competition is fierce:
<nckx>I did push your VLC patch so we cool.
<sundbry>Good day Guix friends
<nckx>Greetings, sundbry.
<solene>nckx: :D
<solene>nckx: I forgot to add the copyright for vlc
<dstolfa>oh... i forgot to add copyright for the strongswan stuff as well in the packages (:
<sundbry>I have a large collection of patches + new packages (72 comits) many of which I plan on submitting today xD
<dstolfa>i usually work under the assumption that putting my copyright on every little change isn't great, but i realize that this may be a bit uh... annoying from some perspective
<solene>if it's the law it has to be done
<nckx>It's not mandatory at all.
<nckx>Honestly, updates probably aren't significant enough to be copyrightable.
<thorwil>hi! how are patches handled in personal package directories?
<lfam>I agree with nckx. We can add copyright lines for updates, if people like it, but it's kind of a gray area
<nckx>(‘Then why do you add them yourself, nckx?’ Because if there's a .1% chance that it makes stealing/relicencing Guix just 5 minutes harder to anyone in some dystope fute, I'm cool with that.)
<dstolfa>copyright for build files has always been kind of weird for me because you're really just putting in options
<lfam>thorwhil: There's an example here:
<lfam>dstolfa: Ultimately it doesn't matter very much. The authorship of Guix is already so dispersed that it will never be possible to change the license or coordinate any action
<jab>lfam: does that worry you a little? I suppose I'm assuming it would be difficult to update to a newer license...
<lfam>Well, Guix is GPL 3 "or later"
<jab>but I guess most people have agreed to a GPL or later...yup. :)
<lfam>So, we won't be changing the license
<ixmpp>bdju; solved it
<ixmpp>well, solved it enough that it works
<lfam>I don't see anything to worry about jab
<jab>I suppose it might be a good to idea for some people to assign copyright to FSF before they die...but that's 30+ years away.
<nckx>jab: Should be ‘all people’ in Guix's case, since that's the original licence they agreed with when submitting their patch.
<nckx>I'm sure there are people in Guix headers today who are de facto unreachable now.
<lfam>It won't be possible to re-assign copyright to FSF. That's the kind of coordinated action I said was impractical
<lfam>It's true nckx
<nckx>Pseudonym + dead addy.
<solene>nckx: nice, I thought it was required ^^
<lfam>Anyways, free software licensing is more of a "pretty please" than some kind of ironclad legal protection
<lfam>A lot of computer programmers think of licensing in the same way they think of code: automatic and absolute. It's not like that at all
<thorwil>lfam: ty, though i don’t see a difference to what i got, which fails to look in /some-local-dir/packages/patches
<jab>lfam: suppose I started violated guix's license. (I won't. I'm running a librebooted T400)...who would legally stop me?
<lfam>thorwil: Maybe you refered to the patches incorrectly
<lfam>jab: Nobody
<lfam>That's what I mean
<lfam>I mean, how would you violate it?
<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. :)
<bdju>ixmpp: nice
<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: I did not know that.
<lfam>There's no viable way to push back
<jab>lfam: doesn't what's his 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
<jab>lfam: interesting. I guess I'd never thought of it that way. :)
<thorwil>lfam: i tripple checked the names. adding to GUIX_PACKAGE_PATH made it so the package itself is found ... it doesn’t look like there is a GUIX_PATCH_PATH, right?
<nckx>solene: Anyway: I would've pushed a fix if this were a new package, but not for a bump. Just add a line for yourself the next time you add something to that file.
<lfam>thorwil: Not that I know of
*nckx isn't at all relieved that the cat-calls have stopped…
<lfam>My repo is for GUIX_PACKAGE_PATH, sorry if that was misleading
<lfam>jab: Here is a message from Torvalds on the value of legal action:
<lfam>It's a very complicated subject, to be sure. But as the son of a lawyer, I think that Torvalds isn't wrong
<lfam>Legal action is the absolute last ditch action, and even then, you have to consider the equivalent of war
<lfam>Consider it, I mean
<lfam>There may not be a project or community left afterwards
<lfam>It's much better to try to be persuasive in private
<lfam>Or even to shame in public
<lfam>The conversation ends when the first letter is sent with legal letterhead
<lfam>We also have to remember that the Linux team has a different understanding of the GPL than we do. They are happy to include binary driver blobs in their source tree
<lfam>But it doesn't mean that they are stupid or crazy. They just have a different perspective and different goals
<dstolfa>i mean, before we can even discuss licenses and the GPL, surely it makes sense to point out that the only people who can actually enforce a license is the copyright owners?
<lfam>Yeah, and that seems to be rarely understood
<jab>lfam: I think I did know that the copyright owners are the only ones that can do legal action...
<jab>I guess I watched software freedom conservancy guys talk about how he enforces the GPL. I guess my current views are based on his talk.
<jab>but thanks for pointing out the other side of the argument. I'll read what Linus has to say!
<dstolfa>unfortunately i think law and software in general are a bit in odds with each other, namely because courts still don't understand how to handle software
<lfam>That's often claimed, but I think the courts understand software about as well as they understand any other area of specialty
<lfam>Which is to say, the courts have power over us
<lfam>Whether or not we think they understand
<lfam>So, it's risky to enter the courtroom
<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.
<nckx>It's not that special.
<lfam>Yeah, software is relatively new. 80-ish years of industrial use?
<lfam>It's newer than many disciplines
<jab>lfam: I've never heard that laywers will actively encourage you to settle an issue out of court...
<lfam>jab: It's true
<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.
<lfam>The outcome is seriously unpredictable
<lfam>A jury trial is like... really bad news
<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
<lfam>Think of them as mercurial wizards
<sundbry>On a less stressful topic, if I am submitting a set of unrelated patches, is it better to send them all in one large email, or should I send multiple emails?
<nckx>sundbry: It depends!
<sundbry>To me it makes sense to send them separately (except when they are inter-dependent)
<sundbry>But I dont want to spam the list, either
<nckx>If they're unrelatedly unrelated, please send them separately. If they touch unrelated bits but are somehow related, 1 bug number is probably still better.
<leoprikler>if they share a common theme, e.g. a bunch of emacs-related packages, then you might also drop them in one go
<nckx>Like that.
<sundbry>they are really all over the place, ok. Do I need a bug report for each patch? or can I just send patches (ie. new packages) without a corresponding bug?
<nckx>Or ‘improve integration with GNOME on various fronts’ or whatever.
<dstolfa>lfam: in any case, i think we can all agree that courtrooms are extremely risky and hostile in general so it's best to avoid if at all possible
<lfam>jab, dstolfa: Everything I said on the topic of legal work is specific to the USA, btw.
<sundbry>I'm pretty sure Jesus said something about going to court along those same lines, lol.
<lfam>I have no knowledge about other countries
<lfam>Heh, I'd be interested in that verse sundbry :)
<nckx>sundbry: It sounds like you should just send each one to guix-patches@. Don't worry about bug numbers, we buy them in bulk and they're really cheap.
<nckx>And closing more feels good.
<dstolfa>i don't think it's any different in the UK FWIW
<lfam>Our system grew out of the UK system, IIUC
<dstolfa>the UK wanted to ban algorithms in the past, so there's that
<lfam>Right. It's like, to us, that's crazy. But the law is the law
<lfam>They banned a plant, too
<jab>lfam: that was an awesome email!
<lfam>And millions of people lost decades of their lives after the plant was banned
<lfam>The fact that it was stupid didn't matter
<lfam>That's amazing sundbry
<jab>sundbry: that's true!
<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
<lfam>Right, that happened for PGP
<lfam>It wouldn't really work in the US if the government wanted to push the matter
<sundbry>ok nckx I will be happy to let you sort out the dead bugs, starship troopers style.
<nckx>Another very good reason not to group them.
<nckx>That documentary was horrifying.
<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!
<raghavgururajan>nckx: Ah, so nobody is a user and nogroup is a group. Gotcha!
<raghavgururajan>ixmpp,bdju: Works fine on my end.
<nckx>Oh yes.
<nckx>They are not some deep Zen koan.
<raghavgururajan>ixmpp,bdju: How are you using Guix?
<bdju>I'm on guix system
<ixmpp>raghavgururajan: Uhh, system
<ecbrown>bdju: buckle up, enjoy the ride :-)
<ixmpp>Are you not?
<raghavgururajan>imxpp: After installing `gajim-omemo` and restarting gajim, do you see the plugin the list?
<ixmpp>raghavgururajan: No.
<ixmpp>I figure its cause the python deps werent around
<ixmpp>But it wouldnt even let me install it from online either
<raghavgururajan>the python deps are propagated with plugin package
<ixmpp>Works now, now that i messed with the gajim package and also installed it externally
<raghavgururajan>Whats your gajim version?
<ixmpp>raghavgururajan: Yeah, i had to add it that way...
<ixmpp>raghavgururajan: 1.3.2
<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?
<ixmpp>raghavgururajan: Just installed it full
<raghavgururajan>I see.
<bone-baboon>ecbrown: Yes
<ixmpp>raghavgururajan: Most important is the propagation of the python deps
<ixmpp>(of the plugins, to gajim)
<bdju>raghavgururajan: I think I had also just recently installed it when I had the problem. I was using dino previously
<ecbrown>bone-baboon: i'm not aware of a "dry run" feature, but it may exist
<ixmpp>Cause separately did not work
<raghavgururajan>ixmpp: Would you be able to try: `guix environment --pure --ad-hoc gajim gajim-omemo -- gajim`?
<ixmpp>Hm. Not right now, since im actively using it now :p
<ixmpp>(cant open two, right?)
<raghavgururajan>Ah cool!
<raghavgururajan>Think so.
<raghavgururajan>ixmpp: Oh you can. Just a sec.
<bone-baboon>ecbrown: Thanks. There is a `--dry-run` for guix pull I will try that.
<raghavgururajan>ixmpp: [1] `guix environment --pure --ad-hoc gajim gajim-omemo` [2] `gajim --profile=temp --config-path=/tmp`
<ixmpp>Ah, okay
<ixmpp>raghavgururajan; ah, that works!
<ixmpp>so i don't get why it didn't work when i added them to my home packages
<ixmpp>ah well
<ixmpp>not bothered, problem solved, realistically
<raghavgururajan>So the package(s) work correctly. You may have to clear dot-files and try again.
<raghavgururajan>Ah cool!
<ixmpp>why should dotfiles affect it?
<ixmpp>that seems ..not quite robust
<raghavgururajan>They sometimes cache the PATH for plugins.
<raghavgururajan>A phenomenon I noticed sometimes.
<maximed>Can someone confirm that "guix build --target=aarch64-linux-gnu hello" fails on core-updates? <>
<mbakke>maximed: it worked on my GCC 10 branch last I checked, which will be merged shortly
<maximed>mbakke: I'll try again, and if it fails again, I'll rebase on the GCC 10 branch for now
<mbakke>can someone confirm that '--no-grafts' is ineffective on 'core-updates'?
<maximed>mbakke: do you have an example package to test with / without grafts?
<lfam>mbakke: Do you mean, that there are no grafts on core-updates?
<maximed>mbakke: is that GCC 10 branch available somewhere public?
<mbakke>lfam: after merging master, './pre-inst-env guix build --no-grafts libx11' returns /gnu/store/22qnrxwwqm7270hi41805fs8dvlnasbc-libx11-1.7.A
<lfam>mbakke: Weird
<lfam>I would make sure the development environment is set up correctly, or use `guix pull --url=/home/mbakke/core-updates`
<lfam>It sounds to me like the kind of problem that occurs when you GC the development dependencies and don't reconfigure and rebuild the Git tree
<lfam>It will take me a while to build the checkout on my laptop so I'll wait to reproduce until you confirm those things :)
<mbakke>maximed: try cherry-picking 6d71f6a73cd27d61d3302b9658893428af6314d2 and build 'expat'
<mbakke>you'll need to solve a trivial merge conflict
<mbakke>I don't think there are any replacements currently to test with
<mbakke>maximed: I will push it to 'core-updates' in a short while :-)
<efraim>I was having trouble with --system on core-updates previously, hven't tested in a bit though
<ss2>hm, I just installed a Debian, and put a Guix on top of it. Passing --discover=yes to guix-daemon.service fails.
<efraim>I think I used xz to test, the inline assembly fails hard when building with --system=i686-linux on x86_64-linux
<lfam>Fails how, ss2?
*lfam pushes a refreshed wip-ungrafting branch. Hopefully CI is ready this time :)
<lfam>It's basically a mini-core-updates at this point...
<lfam>Not sure it's wise
<ss2>lfam: guix-daemon[970]: /usr/bin/guix-daemon: unrecognized option '--discover=yes'
<mbakke>lfam: yay! :)
<lfam>ss2: /usr/bin/guix-daemon looks weird...
<ss2>but loading the daemon manually is fine with that option.
<mbakke>lfam: I have been wondering about that too ... I think we can perhaps merge the ungrafting and staging cycles
<lfam>ss2: Loading the daemon manually? Can you try to be more specific in your messages?
<lfam>How did you install Guix? What version of Guix is it?
<ss2>sorry, I meant, that I started the daemon manually from the shell with all the parameters from the .service file.
<ss2>I installed it from the Debian repos.
<lfam>Basically, it sounds like you are using an old version of Guix, from before we added --discover
<ss2>and upgraded it, which is at the current version now.
<lfam>vagrantc: Are you around? Somehow has a question about the Debian package ^
<lfam>I mean, someone
<lfam>mbakke: Yeah... something like that
<mbakke>maximed: derp, the issue was only that 'libx11/fixed' was public...
<lfam>We should talk about this stuff on guix-devel. Once the final kinks are worked out on CI, it should be possible to move a lot more quickly than in the past
<efraim>ss2: you can also see if /usr/bin/guix-daemon --help lists --discover as an option
<lfam>However, we still only have significant build capacity for x86
<maximed>mbakke: do I still need to test something?
<ss2>no, ah! so systemd is directly loading the daemon found in /usr/bin/
<mbakke>maximed: no, but thanks for being my rubber duck.
<efraim>does anyone know how to debug a failing builtin:download ?
<maximed>efraim: maybe put some (pk ...) in (guix build download) & friends?
<maximed>& restart the daemon from your guix checkout
<maximed>(a "guix build --ignore-builtin-daemon" option would be useful, doesn't exist, but should be implementable)
<efraim>good idea with the pk's
<efraim>not sure how the downloads would work for getting the bootstrap binaries without the builtin:download though
<ss2>efraim: okay, I disabled --discover, restarted the daemon, and --discover is available again -- since now guix-daemon is now pointing to the current version?
<ss2>*disabled --discover in the .service file.
<maximed>efraim: A simpler option: try to reproduce with "./pre-inst-env guix download http://stuff"
<efraim>./pre-inst-env guix download is working for me
<maximed>working, as in, it reproduces the bug?
<maximed>Or as in, the bug doesn't manifest?
<efraim>working as it I can download files using that
<lfam>ss2: Is that a question?
<mbakke>efraim: guix download is implemented scheme, whereas builtin:download uses the daemon (which in turn invokes scheme helpers!) IIRC
<efraim>how mandatory is disarchive?
<ss2>lfam: not really. I think just realised how the daemon is loaded.
<lfam>Okay :)
<maximed>efraim: maybe try "guix perform-download"
<lfam>ss2: I don't think many of us are familiar with the Debian package
<maximed>(That's what the build daemon uses)
<ss2>yeah, no worries. Just set up a machine and thought I could have all the bells and whistles from Guix in Debian as well.
<efraim>maximed: good find! I hadn't seen that one before. Looks like I found the actual problem somewhere
<lfam>I use Guix on Debian almost exclusively, but I install Guix with the binary installer
<efraim>Starting download of /gnu/store/9fdnfgk9bgmvcfi7ka3hi9famdzivc9w-bash
<efraim>In procedure open-file: Permission denied: "/gnu/store/9fdnfgk9bgmvcfi7ka3hi9famdzivc9w-bash"
<lfam>I started doing that years ago and I'm really comfortable with it
<lfam>There are tradeoffs to either method
<ss2>sure. It is still good that the package is in the repos though. But will fetch the binary instead.
<maximed>efraim: supply an output argument to "guix perform-download"
<lfam>Git commit signatures without PGP:
<efraim>maximed: I used GUILE_LOAD_PATH=/usr/local/share/guile/site/3.0:$GUILE_LOAD_PATH ./pre-inst-env guix perform-download /gnu/store/fgd0cncwwbfl85ihqsi97mxkd8bgssdc-bash.drv
<maximed>efraim: replace (? store-path? output) by (? string? output) in guix/scripts/perform-download.scm. Replace content-addressed-uris by '() in guix/build/download.scm. Retry.
<maximed>./pre-inst-env guix perform-download /gnu/store/l6sswigkh392d9wxa0lf4idn825vg1ps-hello-2.10.tar.gz.drv out
<maximed>Then output should be in "out" in current working directory
<efraim>I'm still getting permission denied: In procedure open-file: Permission denied: "/gnu/store/hbdalsf5lpf01x4dcknwx6xbn6n5km6k-hello-2.10.tar.gz"
<efraim>oh, only replaced the first one
<maximed>(Don't forget passing "out", otherwise "guix perform-download" will try to write to the store)
<efraim>definately forgot that part too
<civodul>efraim: riscv, woohoo!
<maximed>Can someone make sense of this error? ‘aarch64-linux-gnu-ld: skipping incompatible /gnu/store/[...]-glibc-cross-aarch64-linux-gnu-2.33/lib/ when searching for -lc’?
<maximed>FWIW, here's a dump of ‘objdump -x /gnu/store/ghmf95ig7n3kf9wz4m8kjrcmpyzf938p-glibc-cross-aarch64-linux-gnu-2.33/lib/’:
<efraim>maximed: I tweaked it a bit so it had a length of 44 and I was able to download files using perform-download to /home/efraim
<efraim>i'll look at it more in the morning, it's getting late here
<maximed>It has ‘NEEDED’, so the architecture should actually be ok?
<maximed>But it also has ‘architecture: UNKNOWN!’ ...
***pritambaral is now known as prite
<vagrantc>hello guix
<maximed>No idea what's going on, will try --target=i686-linux-gnu.
<civodul>maximed: "skipping incompatible" 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?
<iskarian>s/delete/not install/
<civodul>maximed: but yeah, "UNKNOWN" looks fishy
<maximed>I'd do #!/usr/bin/env perl instead
<maximed>civodul: I'll try running under qemu
<maximed>/bin/perl doesn't exist on Guix System
<iskarian>I figured it didn't matter since they aren't expected to be run again after building
<maximed>iskarian: what are these source files for?
<maximed>If they aren't expected to be run, but only an example, #!/bin/perl could be fine
<vldn> maybe useful for someone :) a script to install guix onto a busybox system (here within WSL2 on Windows)
<vldn>*guix system
<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/ 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>Ah, apologies, I was unclear
<iskarian>Though I suppose that will be next :)
<maximed>iskarian: why do these Go source files have a #!/gnu/store/.../bin/perl shebang?
<maximed>Could you paste an example:
<raghavgururajan>maximed: Because, if those src file gets used by another package and gets compiled, it needs absoolute references to programs. The build-env is pure.
<maximed>but ... as I understand it, these go source files have a #!/.../bin/perl shebang. How is perl supposed to run Go code? Doesn't make much sense to me
<maximed>So I am hoping for an example to clarify matters
<raghavgururajan>I thought you meant the path.
<iskarian>No, these are separate .pl files which generate the bodies of some .go files
<iskarian>Specifically for e.g. syscalls
<maximed>Separate .pl files make sense
<maximed>Maybe just delete them during installation. They shouldn't be required anymore. If the user wants the source code, they can just do "guix build --source go-stuff"
<lfam>What's the idea? To avoid Go referring to Perl?
<iskarian>That's what I was thinking. I just wanted to bounce it off of someone else in case there was a best practice :)
<iskarian>lfam, yes
<lfam>Check the hack used in gnu/packages/patches/openssl-1.1-c-rehash-in.patch
<lfam>It's the same story
<lfam>It allows us to package OpenSSL with perl as a native-input and to set disallowed-references=perl
<lfam>I can't say it's "best practice"
<lfam>I mean, if a package depends on something, we don't necessarily want to hide that
<lfam>Go already keeps some... weird references
<iskarian>Yeah, I've been mulling over how to fix the fact that it's tied to a specific GCC version for cgo support...
<lfam>It could definitely be overhauled
<lfam>Building the Go compiler was an iterative process
<lfam>And the go-build-system is ready to be overhauled as well
<lfam>It's been discussed on the mailing lists
<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
<civodul>so i don't know!
<civodul>prolly janneke does :-)
<mitzman>i think x86 one works well, with the exception of some weirdly-configured kernels (like mine), but a (hacky) patch (which imo is not commitable) is on its way
<mitzman>but at one point x86 will probably disappear
<civodul>does the exception relate to ?
<stikonas>mitzman: can you even remove x86 compatibility from x86_64...
<stikonas>in any case I don't expect that to happen any time soon
<mitzman>well my system doesn't have some 32bit syscalls
<stikonas>oh ok, if you compiled kernel without it...
<mitzman>since i can't compile some tools for x86_64 (or I didn't try/it will probably be too hard) i just decided to replace test -w and test -x bash builtins with the actual utility
<stikonas>anyway, I don't expect x86_64 bootstrap to be that much harder...
<iskarian>Oh, I'm silly... they aren't even required at build time. Well, that was easy
<lfam>Perfect :)
<vagrantc>lfam: any luck with your mcbin?
<lfam>I took a few days off vagrantc. The next thing I'm going to try is using Linux built with the Debian configuration
<civodul>mitzman: if you have more data about, such as the specific kernel config flag that causes it, please do contribute it
<lfam>vagrantc: I don't have any ideas beyond that
<vagrantc>lfam: that's reasonable :)
*vagrantc just scrawled a long email to guix-devel regarding multiple bootloader arm64 images
<lfam>Nice, I hope it's fruitful
<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[0] to not have a test builtin is a better solution?). it's basically a fork of grapheneOS kernel, named "linux-hardened" on arch