IRC channel logs


back to list of logs

<Gooberpatrol66>I'm getting a permission error trying to connect to libvirtd. Is it supposed to be run by an unprivileged user?
<mroh>Gooberpatrol66: the user has to be in the "libvirt" group ala: `(user-account (supplementary-groups '("libvirt")))` or you can set another group for the service: `(service libvirt-service-type (libvirt-configuration (unix-sock-group "yourgroup")))`
<mroh>or both, ofc ;)
<Gooberpatrol66>mroh: thanks!
<cbaines>mbakke, is it appropriate to delete the staging branch, now it's been merged?
<mbakke>cbaines: sure
<cbaines>mbakke, cool :) I think I've managed to delete it
<raghavgururajan>For stuff in #:configure-flags like `(string-append "--with-foo-libs=" (assoc-ref %build-inputs "foo") "/lib"))`, is it possible to refer more that one inputs?
<raghavgururajan>Like %build-inputs "foo1" "foo2" ???
***catonano_ is now known as catonano
<wleslie>raghavgururajan: sure. --with-foo-libs probably takes some comma separated list, so you could easily say:
<wleslie>(string-append "--with-foo-libs=" (assoc-ref %build-inputs "foo") "/lib," (assoc-ref %build-inputs "bar") "/lib")
<wleslie>raghavgururajan: but do check the configure script for the format required.
<raghavgururajan>wleslie: Thanks!
<apteryx>mbakke: oops, what did I break :-)
<apteryx>I tend to drop the python-2 variants when they give me grief and have no dependents.
<ryanprior>How do you get the current working directory during a build?
<ryanprior>Context: this build system assumes $HOME is a) set and b) writeable, so I want to make a cozy little home inside the build directory and set that so it can be happy.
<lle-bout>ryanprior: patch so it doesnt need a $HOME?
<lle-bout>and propose patch to that project
<ryanprior>If you know the answer, please provide it instead of redirecting. I can tell it to use somewhere other than $HOME, but in that case I still need to know what the build path is.
<lle-bout>ryanprior: I mean that it should not require any $HOME directory, not during a build - I am guessing there's some function to get the build directory but I don't know it. It seems like an easier and more maintainable route to me to fix that build system to not require $HOME
<ryanprior>I looked deeper in response to your suggestion and soon found that it does not require any $HOME, that's simply a default. So now I know how to provide an alternate directory without setting $HOME, and I'm trying to figure out what to provide.
<iyzsong-w>`getcwd` will return the current directory, usually add "(setenv "HOME" "/tmp")" should make it work
<ryanprior>How do I specify that a package should set a certain environment variable when installed in a profile? Like how installing a Python package will modify your PYTHONPATH
<iyzsong-w>ryanprior: Add the 'native-search-paths' field.
<ryanprior>Thank you iyzsong-w for those pointers and lle-bout for challenging my assumptions
<lle-bout>:-s not sure if that's good or bad
<iyzsong-w>sure :)
<ryanprior>It's good, I don't give sarcastic thank yous
<lle-bout>okay (:
<lle-bout>iyzsong-w, ryanprior: would you happen to know GCC developers that can deal with reproducibility problems?
<ryanprior>I don't but if you post somewhere about the problems you're having I can share it around in case somebody who knows more might see it.
<lle-bout>ryanprior: I'll post to guix-devel and link you
<mizukota[m]>is there a clear dockerfile with recipe of installing and running Guix on top of debian or another distribution?
<ryanprior>mizukota: Guix in Docker is an area of ongoing development, there are some experimental Dockerfiles but no official one yet.
<ryanprior>There is documentation for installing Guix on a foreign distribution:
<apteryx>mizukota[m]: note that if using Debian Sid (testing) and having enabling 'experimental', you can 'apt -t experimental install guix'
<apteryx>thanks to vagrantc's work
<ryanprior>Yes very exciting if you use experimental :)
<ryanprior>How do I create a file using guile, a la touch?
<apteryx>perhaps using 'open' with write access, and not actually writing anything to it?
<ryanprior>Does Guix perhaps set umask 222 during build?
<ryanprior>I'm getting errors from a test that tries to open a file in write mode repeatedly to overwrite it. After the first time, it's failing. When I look at the file, it's set as read-only for everyone.
<ryanprior>I thought "maybe if I create the file ahead of time it'll work" but it doesn't.
<philipper905>Is there to have both guile2 and guile3 installed and accessible a la python?
<philipper905>a way*
<ryanprior>Probably unrelated but interesting: I'm getting "return values other than #t are deprecated" messages during builds, shouldn't those be gone now?
<apteryx>you mean, in the same Guix profile (note that this is bound to fail even on Guix due to using the shared PYTHONPATH).
<apteryx>philipper905: ^
<philipper905>apteris: yeah I wanted to try the guix Artanis web framework but it requires guile 2.2, but installing guile 2.2 overrides guile 3.0 which wasn't what I was hoping for
<ryanprior>Digging into my issue above: the test was copying a source file to the target destination, which in the common case would be a regular degular file from your git checkout.
<ryanprior>But in Guix I think files from the checkout have umask 222.
<ryanprior>So the test file then inherited those file permissions, which doesn't work for the logic of the test.
<ryanprior>I used chmod to give write permissions to all the needed files in the checkout, and then the test passes.
<lispmacs>erm, I told sneek to tell himself hi, and he quit the channel
<nckx>Good morning Guix and sneek murderer.
<lispmacs>did I just kill him with a stack overflow?
<lispmacs>I really didn't think that would work
<nckx>Didn't you know? Sneek's stack is only 2 bytes. No room for null.
<nckx>(Which is 4 nibbles. Which is one botsnack.)
<lispmacs>sneek, resurrect
<lispmacs>i think you could do a forth system with a 2 byte stack, but not sure about lisp
<lispmacs>but you wouldn't be able to have more than two parameters to a function
*lispmacs has to go to bed
<nckx>Night! sneek will haunt your dreams.
*raghavgururajan enabled Gadu-Gadu support in Pidgin.
*raghavgururajan looks for polish folks ;-)
<txgvnn>Hello Guix!
<txgvnn>I have a problem when building a new package.
<txgvnn>Using gnu-build-system
<txgvnn>GOPATH=/tmp/guix-build-ibus-bamboo-0.6.7.drv-0/ibus-bamboo-0.6.7 go build -ldflags="-s -w" -o ibus-engine-bamboo ibus-bamboo
<txgvnn>failed to initialize build cache at /homeless-shelter/.cache/go-build: mkdir /homeless-shelter: permission denied
<txgvnn>full log here
<ryanprior>Something might be trying to create $HOME/.cache
<txgvnn>Hm, how to fix it?
<ryanprior>Not sure. Maybe set go flags to disable build cache.
***sorki is now known as srk
<txgvnn>Thank ryanprior. After (setenv "HOME" "/tmp"), it works
<txgvnn>But a next new bug. lol
<efraim>you'll have to decide if it's easier to add go magic to the gnu-build-system or start with the go-build-system and remove some bits
<efraim>I normally would go with the go-build-system to make sure I didn't forget stuff
<efraim>does the build run ./configure ?
<txgvnn>Upstream use go build in gnu-build style
<efraim>you can ignore the makefile and just use the go-build-system
<txgvnn>I think I had try it. It was failed so I switch to using Makefile
<txgvnn>let me see
<txgvnn>can't load package: package .: no Go files in /tmp/guix-build-ibus-bamboo-0.6.7.drv-0
<txgvnn>if I use go-build-system
<efraim>indeed. looking at the makefile I'm not sure how it actually manages to build anything
<efraim>i'll see what I can hack together
<mizukota[m]>it uses go build and you can't use network in package descriptions
<mizukota[m]>you need some kind of go vendor
<ryanprior>txgvnn: you likely have to set the import-path and unpack-path separately
<ryanprior>Observe how in `kylelemons/godebug` there's no go files in the repo root. They're in the "diff" directory. So you have to set that explicitly.
<ryanprior>So for your package you perhaps want an import path of "" and an unpack path of ""
<ryanprior>Sorry to lob that and duck out, but I'm headed out for the night.
<ryanprior>Happy to help again tomorrow, if you have questions feel free to send an email to guix-devel and I'll respond.
<txgvnn>Thank you everyone, I will try it.
<civodul>Hello Guix!
<nckx>Hullo civodul.
<civodul>hey nckx, what's up?
<civodul>disk space consumption on berlin has improved significantly
<efraim>Hello everyone!
<civodul>it's early in the morning yet GC's not running!
<nckx>Nothing much, calm day today, might even do some hacking (...but it won't be on Guix ☹).
<ZombieChicken>anyone have any clue why lspci wouldn't work on an arm64 system?
<nckx> It works here (Overdrive 1000). Define ‘not work’?
<efraim>the overdrive 1000 is more real-computery than most arm boards though
<ZombieChicken>produces no output
<nckx>ZombieChicken: Do you have a PCI bus?
<efraim>no output sounds about right for most of my boards
<hooway>i want to install guix on laptop, but it has no ethernet ports, is there a way to connect to wifi?
<ZombieChicken>nckx: Good point
<nckx>efraim: Right, that's my understanding too (glorious UEFI, no devicetree nonsens, ...).
<nckx>hooway: If your wi-fi card supports Linux-Libre (i.e. it requires no proprietary drivers or firmware).
*nckx AFK for tax purposes.
<hooway>nckx: i have no internet on the laptop, is there a way to connect to? im trying to install it, but have no internet
<hooway>guix only supports ethernet for installation?
<civodul>hooway: hi! it also supports WiFi, provided your WiFi chip is supported
<nckx>hooway: No, Guix will use whatever network is available and will offer to connect to available wireless networks if you use the interactive installer.
<nckx>But your chip needs to work for that to work.
***apteryx_ is now known as apteryx
<mizukota[m]>is grub-efi-bootloader broken?
<txgvnn>Yolo, I built and install successfully. Could you help me how to mofify this xml file to correct %out dir
<txgvnn>Seems I found this function substitute
<civodul>mizukota[m]: i don't think so; why?
<mizukota[m]>i've tried to boot official qcow2 image using qemu with uefi-only emulated system
<mizukota[m]>and bootloader told me it cant find partition with Guix_image label
<mizukota[m]>while same qcow2 image can be loaded with bios emulated system
<mizukota[m]>Also this autumn i've tried to build and install my guix image a lot and I experienced some problems.
<mizukota[m]>- grub-efi-bootlader can only be installed using `guix system init` from host system that was booted in uefi mode
<mizukota[m]>- i've managed to build image, i've managed to guix system init to external usb drive with bios setup, but when i tried to install system to laptop... It was success but when I boot I get booloader errors i think about not being able to find some partition too
<civodul>i think the qcow2 VM image expects a "BIOS" setup
<civodul>probably most Guix System users rely on grub-efi-bootlader so we should notice quickly when it breaks :-)
<mizukota[m]>maybe qcow image expects bios but it definitely has .EFI bootable file
<mizukota[m]>the thing is guix system users often do guix system reconfigure, but not 'guix system init'
<civodul>right, you only have to do "guix system init" once in your life
<civodul>or possibly never if you use the graphical installer
<civodul>for the QEMU image, did you follow the instructions at ?
<mizukota[m]>no, i did it in different way using virt-manager. Those instructions do not mention uefi emulated systems at all
<dannym>Hmm, node-build-system seems to refer to gulp, but which package contains it?
<civodul>no idea
<civodul>mbakke: congrats on merging 'staging'!
<kisaja[m]>guix install v4l2loopback-linux-module, build failed, union-build collision between files(openjdk /lib/modules) and dirs(v4l2... /lib/modules), help
<civodul>hi kisaja[m] :-)
<seeg123>hello, i'm trying to build my project in guix, with direnv and nix, however it seems NIX_PATH variable is not initialized
<seeg123>any idea on how to make this work?
<civodul>kisaja[m]: could you paste the tail of the build log that "guix install" mentioned?
<civodul>seeg123: hi! is this a question about Nix or about Guix?
<seeg123>it's about nix under guix :)
<civodul>oh :-)
<seeg123>i have a project which is written managed with nix and i want to migrate it to my laptop which has guix
<civodul>i see
<seeg123>one suggestion on reddit was that there is nix under guix so i'm testing it, however it seems that important NIX_PATH var is not set
<civodul>the "nix" package doesn't have a search-path specification for NIX_PATH
<civodul>which probably makes sense because i don't think there's a standard directory for .nix files, right?
<civodul>so that means you have to set NIX_PATH by yourself i suppose
<civodul>maybe iyzsong knows more
<civodul>or wigust
<kisaja[m]><civodul "kisaja: could you paste the tail">
<civodul>kisaja[m]: i was referring to the tail of /var/log/guix/drvs/i0/q9i0xaxqm2m4n1kdks5a7zi8r5ap7a-profile.drv.bz2, could you paste it?
<civodul>oh i see
<civodul>so you cannot have openjdk and v4l2loopback-linux-module in the same profile
<civodul>but that's ok: v4l2loopback-linux-module is not meant to be installed in a profile
<civodul>instead, it should to to your OS config
<kisaja[m]>oh thx
<civodul>specifically in 'kernel-loadable-modules':
<iyzsong>seeg123: you can source ~/.guix-profile/etc/profile.d/, which set NIX_PATH to ~/.nix-defexpr/channels (for use with nix-channel), i think doc is <>
<PotentialUser-76>I have this problem [] when running GParted, what is the solution?
<rekado_>PotentialUser-76: you need to run it as root.
<PotentialUser-76>Yes, but how?
<rekado_>PotentialUser-76: sudo, for example
<PotentialUser-76>Always open with terminal?
<roptat>hi guix! has anyone managed to make ibus-anthy work?
<roptat>if that helps, I get this kind of errors: org.freedesktop.IBus.Config.SetValue: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._dconf_5ferror.Code2: The operation attempted to modify one or more non-writable keys
<PotentialUser-75>I have this problem with the "guix package -u" command:
<PotentialUser-75>what's the solution?
<roptat>looks like geary is broken. You can prevent it from upgrading by using --do-not-upgrade=geary
<euandreh>PotentialUser-75: you can check the error logfile
<euandreh>at /var/log/guix/drvs/7y/b1ri...geary.3.34.1.drv.bz2
<euandreh>cp /var/log/guix/drvs/7y/b1ri...geary.3.34.1.drv.bz2 . && bunzip2 b1ri...geary.3.34.1.drv.bz2
<PotentialUser-75>The last four lines:
<soheil>FAILED: meson-test
<PotentialUser-75>FAILED: meson-test
<PotentialUser-75>... /gnu/store/9m03qg3zrcfr3sxmr5592vkaa4p33sci-meson-for-build-0.53.2/bin/meson
<PotentialUser-75>The last four lines:
<PotentialUser-75>FAILED: meson-test
<soheil>... /gnu/store/9m03qg3zrcfr3sxmr5592vkaa4p33sci-meson-for-build-0.53.2/bin/meson test --no-rebuild --print-errorlogs
<PotentialUser-75>ninja: build stopped: subcommand failed.
<PotentialUser-75>command "ninja" "test" failed with status 1
<PotentialUser-75>Sorry there was a problem, soheil sent it.
<euandreh>PotentialUser-75: try doing the upgrade as roptat suggested
<roptat>also we now have --without-tests
<PotentialUser-75>guix package -u packageName -u packageName -u ...
<PotentialUser-75>Does this do the same?
<roptat>I think you need to use -i packageName packageName ... instead, that will upgrade the packages you selected
<civodul>PotentialUser-75: yes, or just "guix upgrade PKG1 PKG2 ..."
<roptat>oh, you can specify a list of packaes to upgrade?
<civodul>i think so, no?
<roptat>looks like you can only specify one package that way
<roptat>guix upgrade sway pinentry -> pinentry: superfluous argument
<mroh>-u pkg1 pkg2 pkg3
<civodul>roptat: oh, that's not good
<civodul>we should fix that
<luis-felipe>Regarding guix upgrade not accepting more than one package, zimoun already has a patch
<luis-felipe>Oh, sneek is gone?
<janneke>sneek was assasinated
<luis-felipe>Another thing I noticed about the upgrade command is that when you run it with --dry-run it keeps showing packages that you already upgraded.
<luis-felipe>janneke: Oh, no :(
<janneke>twas cruel
<luis-felipe>roptat: for what it's worth, I upgraded ibus and anthy a couple of days ago, and it is working.
<civodul>apteryx: yay for closing 2017 bugs! :-)
<jas4711>i have a guix machine that was installed around 5 years ago, but /gnu/store contains lots of old stuff despite running guix gc daily. how can i find out why a particular file there exists, and how to clean it out safely? for someone who grew up on lisp it somehow feels comforting that nothing has changed and garbage collection still leaves garbage around :)
<pineapples>Whoops. I just accidentally sent a HTML e-mail. Will it hurt?
<civodul>jas4711: hi! "guix package --list-profiles" and "guix gc --list-roots" can give you a good idea
<pineapples>I hope it won't be a garbled mess, and will get auto-converted if possible
<civodul>roptat: congrats on :-)
<civodul>BTW, "supply chain" = "chaîne d'approvisionnement"
<civodul>re the usual Nix comparison in the comments, it's worth noting that Nix has none of the features listed in the release notes
<rekado_>after a few years of constant inappropriate and uncalled-for Nix comparisons this *does* feel a little grating.
<jas4711>civodul: thanks for pointers. now down to 4G root fs, a bit more reasonable... still a lot of dups in /gnu/store though
<civodul>you could always trim GC roots some more...
<civodul>rekado_: yeah, i wonder if there's something wrong with how we communicate
<civodul>OTOH, these "what about Nix" comments usually ignore the initial message
<civodul>in this case, people do not refer at all to what the announcement says
<civodul>but maybe they won't read announcements until they have a clearer idea of how Guix differs from Nix
<rekado_>it looks like a reflex at this point
<rekado_>I think that this “Guix started as a fork of Nix” meme really caused a lot of damage to the mental image people have
<civodul>perhaps we should write a post "How Guix differs form Nix", after all
<rekado_>“look what you’ve made us do!”
<jas4711>is it possible to find out from where a particular file under /gnu/store is referenced? for example, i have a bunch of 'bash44-???.drv' files that probably should have been cleared out when i upgraded to bash 5
<rekado_>civodul: there’s a chance a post like that would become the new anchor, never to be nudged by consecutive blog posts and release announcements, so it would have to be comprehensive and really good.
<civodul>rekado_: yes, that's the difficulty
<civodul>i think it has in part to focus on the difference of vision
<civodul>it can't be just EDSL vs. DSL, for sure
<mbakke>a good start could be to update the wikipedia page, to clarify the "based on Nix" bit...
<rekado_>oh, but we’re all biased, so we may not change it
<civodul>we could at least state our perspective
<rekado_>(isn’t that the reasoning behind the GNU/Linux vs Linux calamity?)
<civodul>oh right :-)
<civodul>yeah maybe better not meddle with WP
<rekado_>perhaps a fitting time for the definitive blog post would be when the Guile daemon is ready
<civodul>the Guile daemon is "a detail" IMO
<rekado_>that would be the marker of an era of misunderstandings
<civodul>it doesn't change the fact that the two projects have different goals
<civodul>i mean, this release announcements goes as far as using superlatives, which is not something i often do ;-)
<rekado_>the daemon is, frustratingly, *the* bit of knowledge that keeps the misunderstandings alive
<rekado_>it fuels the “fork” meme, it even fuels misguided hope for “reunification”
<civodul>not just: in this case, the person who commented first wrote: "declarative & transactional = like Nix?"
<rekado_>I prefer the good old days when people would post “first!” as a first comment
<civodul>i think it has to do with the fact that, seen from a "traditional" distro, these two things look very close to one another
<civodul>heh :-)
<argylelabcoat>Greetings, I'm a new user of Guix and I'm already trying to author some packages for libraries I use, could use some pointers though
<luis-felipe>argylelabcoat: Welcome :)
<argylelabcoat>When authoring a package that depends on another C library , cmake is not locating the library with find_package
<argylelabcoat>I feel like I must be doing something really dumb, but in the guix source tree, I don't see any other packages needing to hack around this issue
<mbakke>argylelabcoat: assuming the library already exists in 'inputs', try adding 'pkg-config' to native-inputs
<argylelabcoat>in Nix, I was able to hack around it by doing this: "-DPAHO_MQTT_C_LIBRARIES=${localpkgs.paho-mqtt-c}/lib/libpaho-mqtt3as.a"
<argylelabcoat>right, I saw the pkg-config listed in other cmake based packages and added it in, but I didn't get any further
<PotentialUser-14>Hi! new user here (obviously!). is there any documentation helping installing GuixSD using lvm+cryptsetup for FDE? I've been searching but I couldn't find anything so far
<mbakke>argylelabcoat: the equivalent Guix incantation would be '#:configure-flags (list (string-append "-DPAHO_MQTT_C_LIBRARIES=" (assoc-ref %build-inputs "paho-mqtt-c") "/lib/libpago-mqtt3as.a")'
<mbakke>PotentialUser-14: LVM is not currently supported for the root file system, and general support was added just after 1.2.0
<morgansmith>hello guix!
<argylelabcoat>@mbakke, thanks, though hacking this in feels very... ugly. Is patching the cmake file a more idiomatic approach for a Guix package?
<PotentialUser-14>mbakke: hmm... ok. i thought it wasn't supported by the installer, but it would be possible to use it with manual installation
<PotentialUser-14>mbakke: thanks for clearing that out
<mbakke>argylelabcoat: Passing libraries in #:configure-flags is a common way of doing things, and less hacky than patching IMO.
<argylelabcoat>mbakke: Thanks for the responses, I'll give this all a go
<morgansmith>I'm currently having issues with the mpd service. I've set it up to run as my user but the /var/run/mpd/my_user folder is owned by root so mpd can't create its pid file there.
<mbakke>PotentialUser-14: I expect LVM-on-root will be supported "soon", the main issue is that GRUB does not currently have the LVM module. You would also need a newer installer image (but you can grab that from the CI when it's available).
<PotentialUser-14>mbakke: awesome, thanks!
<mbakke>morgansmith: can you file a bug report about it?
<mbakke>morgansmith: in the mean time, you can probably chown it manually
<mbakke>hmm, the "devel" manual of Guix does not seem to be updating since a few days:
<civodul>mbakke: right, since Nov. 28
*civodul checks why
<morgansmith>mbakke: I'd rather submit a patch :P mpd-shepherd-service uses make-forkexec-constructor but doesn't use the #:user argument. Is it as simple as adding that?
<mbakke>morgansmith: probably the activation script should be updated to chown to the configured user account
<mbakke>but I'm not familiar with the mpd service
<morgansmith>so the activation script creates a .mpd folder in the /var/run/mpd/my_user dir. the .mpd folder has the correct permissions. but the pid file is trying to be made in the /var/run/mpd/my_user dir that has root permissions
<morgansmith>I guess I should go read the manual. I was avoiding it but it'd likely help
<morgansmith>does anyone here use arm-none-eabi? It's really broken. I submitted a patch, but now I don't think that patch is correct :/
<mizukota[m]>what is broken there?
<morgansmith>the c++ libraries override the c libraries. but the c++ libraries want to include the original c library files so it breaks itself
<morgansmith>you can compile stuff that doesn't use those headers, but a lot of basic imports are broken
<mizukota[m]>basic imports like what?
<morgansmith>one sec, I forgot. I did this yesterday
<morgansmith>stdlib.h was the one giving me greif. it has an include next stdlib.h line that fails since we put it ontop of the stdlib.h it wants to include next
<morgansmith>in bug # 44750 i made it install into a c++ folder which allows my c code to compile but c++ code wont compile since it can't see the c includes anymore
<mizukota[m]>but none-eabi which is embedded application binary interface with no operating system installed means there is no stdlib, you cant use malloc untill you define it
<morgansmith>libstdc++-arm-none-eabi defines the c++ stdlib.h. maybe newlib defines the c stdlib.h? regardless we are installing those headers.
<tatsumaru>Hey guys, I just installed Guix SD. Then I proceeded to install icecat via guix install icecat and the installed pulled icecat 78.4.0, but then on the guix website I read that icecat 78 doesn't yet meet privacy requirements. does that mean that the guix installed can pull non privacy packages?
<morgansmith>tatsumaru: link?
<nckx>morgansmith: It's in Guix's IceCat package description. I agree it's a bit jarring.
<morgansmith>does icecat 77 meet the standards? should we offer both?
<nckx>Shipping an old Modern Browser is never an option since these things are unfixable portals to the CVE dimension.
<nckx>morgansmith: You'd might ask in #icecat. The Guix package is actually maintained by one of the GNU IceCat maintainers, presumably they made this choice for a reason.
<morgansmith>the official website has 60.7.0 as the latest download...
<guix-vits>grep reason README -| bwaaah!
<morgansmith>mizukota[m]: I do hope you belive me about the stdlib.h thing. If you do edit "~/.guix-profile/arm-none-eabi/include/stdlib.h" you should see that it's a c++ file. It always fails at line 30 since there are no other stdlib.h files to include
<mizukota[m]>so you need another stdlib for arm-none-eabi I guess.
<morgansmith>mbakke: I didn't want to just add a random chown in the activation service since the mpd user works just fine. I think it's because the mpd user is in the account-service-type. So I think I need to add the user to that
<morgansmith>mizukota[m]: When you tell libstdc++-arm-none-eabi to install in a different directory (like "/arm-none-eabi/include/c++") then you'll see that the original c stdlib.h is preserved.
<morgansmith>if you download the arm-none-eabi zip you'll see they put those c++ things in arm-none-eabi/include/c++/9.3.1
<mizukota[m]>so it is a bug in libstdc++-arm-none-eabi package...?
<nckx>morgansmith: I was just browsing old bugs and came across <>. Is it the same bug?
<mizukota[m]>this is all strange. Packages should exist in /gnu/store and all include paths should be set to /gnu/store/... things, not to something in profile
<morgansmith>well with gcc installed my environment variables look like this:
<morgansmith>so we do include from the profile
<morgansmith>nckx: I feel like that but was likely fixed already. I'm looking into it though
<mizukota[m]>/include in the root of profile looks strange
<morgansmith>this is for gcc-toolchain. arm-none-eabi-toolchain puts it under an arm-none-eabi folder
<morgansmith> CROSS_C_INCLUDE_PATH=/home/pancake/.guix-profile/arm-none-eabi/include
<guix-vits>morgansmith: do u remember some introductory material for C? or someone (i searching)?
<morgansmith>just get a job building a real time unix like operating system like me. Highly recommend it
<morgansmith>except I don't hate blackberry. never going back
<morgansmith>*except I don't. hate blackberry
<morgansmith>the period makes all the difference
<guix-vits>ok, C is practice, i get it.
<morgansmith>guix-vits: learning C is a very big thing to do. chances are you only want a small subset of c. why do you want c? to build embedded device firmware? to write fast programs? there are many different ways to do it
<morgansmith>nckx: I think the bug you found is really similar to mine but it might be harder. Also it has not been fixed yet. In my case the c++ headers where installed into include instead of the common include/c++. In this case glibc is installed in include (either ontop of gcc or below, I'm not sure) but I'm not sure where it is traditionally installed. But ya, it's basically the same issue
<morgansmith>don't we use gcc to build a ton of other programs? How has this issue not caused more problems?
<guix-vits>morgansmith: (wanna my very own server, to die from be too proud)
<mizukota[m]>well generally we dont install gcc and build tools into profile, we just write package definitions an they use gcc-toolchain and other things from various places of /gnu/store i think
<morgansmith>That makes a ton of sense. profiles honestly seem a little funky to me. Why don't we just not install this stuff to the profile and only access it via environment variables? It's not like it's currently in the standard include directory
<dannym>civodul: If you have the time and want to, can you show up in #heads (it's slack) ? That would be a communication channel to the Heads people. tlaurion in there is the lead.
<dannym>civodul: I think they are very serious in using Guix for their Heads builds in the future, but right now we are planning to use some weird heads-on-guix-on-docker contraption to do it. They are also doing a lot of manual source checksumming and whatever, which would not really be necessary when they use Guix
<dannym>civodul: I've been trying to explain to them that a lot of stuff they have been doing is superseded by normal guix tools, but they (obviously) mostly care of solving the immediate problem of Heads' builds not being reproducible
<morgansmith>also for arm-none-eabi I'm trying to build a thing that is complaining that it doesn't have bits/c++config.h. I think this bug report might be important for us to look at as well? I don't quite understand this stuff.
<morgansmith>also I'd like to throw out there that currently openocd doesn't build but it we add "LIBS=-lutil" to the configure flags than magically it works. I'd submit it as a patch, but I don't understand why that would be needed
<morgansmith>guix for embedded development currently sucks :P but it should only be a few commits to make it rock I think
<mizukota[m]>well you try to put compiler and other development packages into profile and build your project manually. Guix way is to write a package definition and build it using `guix build`
<morgansmith>ya well probably. You're not wrong. but when a buddy throws a repo at me I just want to run make :P
<morgansmith>I don't see any reason why we couldn't fix it up to make that possible
<mizukota[m]>you can do your make if you truly manage to get proper set of development packages in profile, also they should not have overlapping files so those that do have overlapping files are not compatible for installing into profile
<morgansmith>ok but in this case arm-none-eabi-toolchain was overlaping with itself
<mizukota[m]>but when writing a package recipe in guile.... there is target, there are package transformation options like --with-c-toolchain, --target, --with-source
<mizukota[m]>i think toolchain packages are for guix recipes, and you need bunch of other packages to get same thing in profile
<morgansmith>I'm not sure what your point is here? That we don't need to fix arm-none-eabi cuz people should only use them in guix package?
<mizukota[m]>do fix it if you can, my point is using the whole power of guix if you were so powerful that you managed to install it
<mizukota[m]>those "just run configure/make/make install" things work everywhere else, on debian or fedora, which is much easier to have installed on hardware on in docker or somewhere else
<mizukota[m]>again the point of guix is to prevent such overlapping when you use things in /gnu/store instead of merging them into profile
<morgansmith>ok I've sent an updated patch which fixes some arm-none-eabi problems. I still need to look into the c++config.h issue. I guess I should also send in to openocd patch. Even if I don't understand it, it building is better than it not building
<rekado_>morgansmith: thank you!
<rekado_>morgansmith: I’m using the arm-none-eabi toolchain for axoloti-patcher. Would be good to check that the change won’t break it.
<morgansmith>I'll admit, I've only tested it installed in my profile. Now I'm nervous about if it'll work in guix packages o.O
<morgansmith>I'm compiling the three axoloti packages now and it seems to be going alright. Fingers crossed
<civodul>does anyone have a Vim config that indents Scheme like we do, including #:use-module, 'modify-phases', etc.?
<civodul>maybe efraim, roptat?
<lfam>I'm using version 0.9.13 of the paredit Vim plugin: <>
<lfam>It doesn't do exactly the "right thing"
<lfam>But, it's close enough
<lfam>My impression is that it does certain things more "correctly", whereas we tend to "un-indent" some lines to prevent the code from running off into the distance
<lfam>I'm not sure if that is the right way to describe it
<lfam>It also tends to "lose track" of things, though. I think it's no substitute for a real sexp-aware editor
<nckx>lfam: So it doesn't apply the exceptions in .dir-local.el. That's not surprising.
<nckx>Imagine parsing that with a regex or whatever vim uses.
<lfam>Vim paredit is rough enough that I don't recommend it to anyone that's not already stuck on vi
<Gooberpatrol66>I'm kind of curious about Android in Guix. So Anbox runs Android apps in a container. A lot of the need for this, I guess, is that Android apps try to search for files at certain paths that conflict with the GNU/Linux directory structure. But that's not really a problem if you package Android components for Guix. So it makes me wonder if you could run Android apps "natively" on Guix without using a
<civodul>lfam: thanks! but does vim-paredit take care of indentation, or is it mostly taking care of closing parens and such?
<guix-vits>Gooberpatrol66: err.. idk what u asking, but adb works :P
<Gooberpatrol66>just a..."theoretical" question
<janneke>dannym: some further slowing of progress, i have resurrected non-ONE_SOURCE build mode succeeden in "bootstrapping" tcc using the gcc-built arm-unknown-linux-gnueabihf-tcc
<morgansmith>welp my fix might fix arm-none-eabi in peoples profiles, but it causes guix packages to fail. fml
<janneke>dannym: using that, i "learned" that tccelf.o and arm-gen.o are miscompiled when using mes-tcc
<janneke>dannym: i looked at the objdump of both but i'm not inspired, so i'll start to bisect tccelf.c
<dannym>janneke: I see! Should I take a look at the tccelf.o and arm-gen.o ?
<janneke>dannym: yes, maybe you can notice something: arm-unknown-linux-gnueabihf-tcc-boot/tccelf.o vs mes-tcc-boot/tccelf.o
<janneke>dannym: so, these are *-tcc-compiled versions; we need to find the wrongly compiled code tcc that creates this change
*vagrantc 's ears perk up at hearing talk of bootstrapping arm
<lfam>civodul: It does indent things, but not exactly in the Guix style
<lfam>I find it "good enough" as a guide. It helped me get started with Guix, which was my first foray into sexps
<civodul>lfam: cool, thanks!
<mbakke>lfam: have you considered evil-mode? I'm pretty happy with it :-)
<guix-vits>mbakke: too fat.
<guix-vits>lfam: don't feed a troll.
<mbakke>guix-vits: fair enough! It's been a portal into Magit, org-mode and notmuch for me as well, but I suppose it's overkill just to work on Guix :-)
<mbakke>actually notmuch is the whole reason I started using Emacs to begin with...
<GNUtoo>Is it possible to enable more locales in locale -a in a manifest?
<gnutec>Yes! o/ Guix 1.2.0
<GNUtoo>so when I do 'guix environment --pure -m manifest.scm' I've also UTF-8 in 'locale -a'
<vagrantc>don't you just need to install the appropriate glibc*-locales packages?
<GNUtoo>I've installed glibc-locales but I'll try with glibc-<something>-locales
<morgansmith>is raspi-arm-chainloader currently building? It's the only thing that uses arm-none-eabi that I can't get to compile
<vagrantc>GNUtoo: maybe you need to check GUIX_LOCPATH environment variable is set correctly?
<GNUtoo>on the host it seems to be fine but I'm unsure how to test
<GNUtoo>and they seem accessible in the --pure environment too
<GNUtoo>I did that in the home, so .guix-profile/lib/locale/2.31 is accessible and seem to have many many locales
<GNUtoo>ah there is 0 .mo there
<GNUtoo>only directories with stuff like LC_NAME in there
<mbakke>GNUtoo: probably you need to include 'glibc' in the manifest so that GUIX_LOCPATH gets configured
<GNUtoo>and files like that seem to have some sort of regex inside
<GNUtoo>oh ok thanks a lot
<janneke>dannym: bisect1, it's in tccelf1.o; moving to bisect2
<morgansmith>ok, I've submitted yet another patch for arm-none-eabi and this one solves all my issues and axoloti and all the other dependencies build just great.
<morgansmith>that took way too long :P
<bonz060>Hi guix. Inside a package definition, when modifying a phase, how would you access the package data, like say propagated-inputs?
<morgansmith>bonz060: check out gnu/packages/axoloti.scm:99
<GNUtoo>hmm for some reasons it didn't work
<GNUtoo>morgansmith: hi, that package supports only arm 32bit right?
<bonz060>morgansmith: thanks for the pointer. Let me have a look...
<GNUtoo>like you can't use it to cross compile an arm64 bit kernel?
<morgansmith>dunno. I just did: grep -r --exclude-dir=doc --exclude-dir=po --exclude-dir=tests --exclude-dir=.git "arm-none-eabi" .
<morgansmith>and then made sure everything that showed up still worked
<morgansmith>it supports armv6-m armv7-m armv7e-m according to the configure flags
<morgansmith>anyways, if I'm going to get any work done today I probably need to leave the IRC :P take care guys
<bonz060>morgansmith: I've had a look at the file you shared. That doesn't exactly help. What I'd like to do is to get /all/ the propagated inputs from the package, and then write to a file static file somewhere. Sth like this: <-- that doesn't work though :(
<GNUtoo>morgansmith: thanks
*GNUtoo probably needs to add armv7a at some point
<bonz060>morgansmith: see you around... I'm sure with time I'll hopefullyl figure something out...
<GNUtoo>but I've to finish my 2 other patches before
<vagrantc>ouch, reproducibility stats look way worse than last time i looked:
<cbaines>vagrantc, well, the stats are worse in terms of data availability
<cbaines>the Guix Data Service isn't great at keeping up with substitute availability
<vagrantc>ah, i see
<cbaines>I've run the script to fetch substitutes for the latest master revision, which should fill in the data
<cbaines>It'll take a few minutes
<vagrantc>had some questions about guix challenge and so on in #reproducible-builds
<civodul>vagrantc: oh that was R-B meeting today
<civodul>you had good answers re "guix challenge"? :-)
<vagrantc>civodul: it was the ask-me-anything session :)
<janneke>interesting :)
<vagrantc>civodul: is that a question? :)
<mbakke>bonz060: package->specification may return a different package than what was actually given as an input name, you should unquote the entire (map (lambda (input) ...) ...) block, and refer to (package-propagated-inputs this-package) instead
<efraim>My vim config doesn't do the indentation actually correctly, more of close enough
<efraim>I intend at some point to get the indentation into vim-guix-vim, just have to actually learn more vimscript first
<mbakke>bonz060: here is a gexp that does the same thing for IceCat's inputs (apologies for the ugly formatting in the result):
<civodul>vagrantc: that's a semi-question i guess, in that i'm confident you had good answers :-)
<civodul>efraim: ah nice; make sure to update the "Formatting Code" section when you have more to share!
<civodul>roptat: ← good news or bad news?
*civodul has an idea what the answer is
<mbakke>civodul: this-record and this-package is super useful, pure genius :-)
<civodul>mbakke: heh, glad you like it!
<civodul>i think this-package could be helpful if we move towards label-less package inputs
<civodul>as discussed during the Guix Day
<jonsger>efraim: vim@guix question: I can not use backspace in insert mode for deleting chars. It only works for chars which where added since the last save (:w or open a file)
<mbakke>I'm really looking forward to being able to use gexps for packages
<nckx>That sounds interesting. Damn I wish the unrecorded discussions had been recorded.
*civodul looks at
<civodul>mbakke: yeah, i hope we can get there soon!
<civodul>for now my productivity seems to have dropped a bit
<civodul>post-release effect maybe, go figure
<nckx>civodul: So ‘label-less inputs’ is part of the mythical gexp-based build system, right?
<jonsger>civodul: maybe we don't have so much critical bugs after the release to keep us busy ^^
<civodul>nckx: more accurately, it's a mythical followup to the mythical gexp-based build system
<civodul>myths guide us
<civodul>jonsger: actually i feel busy "doing things", it's just that nothing comes out of it
<joshuaBPMan>Hey Guix people!
<nckx>civodul: I'd like to close <>. You've added download size reporting when available, and after writing a similar ‘nar-size’ (decompressed) size I've decided it's not something I want. People care about the total additional space use, which we can't estimate due to local builds, not about some random substitutable subset. Make sense?
<civodul>nckx: oh you can definitely close that one :-)
<civodul>it displays the download size, and it prints a warning if the unpacked size exceeds available disk space
<civodul>twas good ol'time
<jonsger>lfam: are you actually using radicale, the DAV thing? You added it back in 2016 :)
<ngz>Is it okay to commit to core-updates at the moment?
<cbaines>ngz, I believe so, although I'd be interested in trying to get it merged at some point
<nckx>Goggles is still demented:
<nckx>Does something need kicking?
*nckx always up for kicking somethings.
<nixin72>Hi, I'm looking to try out GNU Guix since the idea of having an entirely reproducible OS sounds amazing to me cause I like playing around with configs. However, there are a number of pieces of non-free software I want, like drivers for my hardware Discord, Spotify and some other stuff. I could use NixOS, but I also love the idea of my entire system being configured in Lisp. I love Emacs for this
<nixin72>reason, and I'd rather configure in Scheme over Nix any day. That being said, is getting non-free software going to be an issue in Guix? Of course I can be compiling from source and installing from zips, but who wants to do that for everything?
<lle-bout>civodul: FYI current core-updates introduces other problems with powerpc64le-linux-gnu but I'm still investigating
<joshuaBPMan>nixin72 It will be a bit tedious getting non-free software in guix. It is not officially supported. Nor is it considered proper to talk about it in the guix channel. I'm not bullying you, or saying you should not have asked that question. I am just saying, that if there exists ways to use non-free software in guix, then I cannot tell you how
<joshuaBPMan>to use it in the #guix channel.
<ngz>cbaines: ok, thank you.
<lle-bout>civodul: It can't compile Glibc 2.32 due to: configure: error: *** The compiler must support -mabi=ieeelongdouble and -mlongdouble simultaneously.
<nixin72>Okay, so sorry about that. I know GNU doesn't support or endorse it, but wasn't sure if it was okay to ask about here. I'll ask elsewhere. Thank you
<joshuaBPMan>nixin72 No worries. Best of luck! I personally use a thinkpad T400. It's a bit old, but works for most tasks that I have. THought I am not a gamer.
<nckx>nixin72: It's one of the trade-offs of using GNU Guix, if you assign non-free software a value greater than 0 (most of us don't, so it's not even an issue). That said Guix will not artificially limit what you do with it. You can write package definitions for whatever you like. We simply won't provide updates or any kind of support.
<nixin72>Honestly, 95% of what I use is free software already - I pratically use Emacs as my OS atm. Unfortunately having less tech-savvy friends makes it tougher to get them to communicate using open-source alternatives hahah
<lle-bout>nixin72: Signal and Matrix with Element have been pretty good with my non tech-savvy friends and they are Free Software, also GNU Guix packages Flatpak and there's some flatpaks somewhere for those. GNU Guix hasnt yet handled the npm eco-system with Electron onto which those two are based.
<joshuaBPMan>lle-bout My understanding is that npm software is really really hard to build from source. Lots of circular dependencies.
<cbaines>Flatpak indeed, the free software non-free software distribution platform (if that makes sense)
<bavier[m]>we definitely need more emojis in our output, e.g.
<jonsger>bavier[m]: please not!
<nixin72>I've been looking into Matrix with Element actually, it looks promising. I'd like to setup a server for it
<bavier[m]>who doesn't want sparkles and stars when something succeeds?
<joshuaBPMan>slightly off topic, does anyone here use scuttlebutt? What are you thought about it?
<bavier[m]>jonsger: ;)
<lle-bout>joshuaBPMan: I would rather say the packaging practices of the eco-system really work against reproducible builds and happily download binaries from remote places without attaching any origin source code
<joshuaBPMan>lle-bout If you aren't already, then you should consider a job as a technical writer. I think you'd be good at it. :)
<civodul>bavier[m]: the UI looks quite nice though
<cbaines>bavier[m], maybe Guix can include the necessary hooks so you could install the guix-emoji package, and get output like that
<lle-bout>cbaines: It is unfortunate that some flatpak repos are distributing non-free software and I already argued against it to them but nothing to do I guess, nonetheless Element and Signal are Free Software and available as flatpaks :-)
<lle-bout>joshuaBPMan: ooh why is that?
<bavier[m]>cbaines: ooo, yes, that'd also open the doors for `guix-nyan` :)
<joshuaBPMan>lle-bout You did a good job explaining the annoyances of packaging javascript stuff for guix.
<cbaines>lle-bout, well, for free software distribution, I'm not sure Flatpak has a great featureset, like I'm not sure how you build from source for example
<lle-bout>cbaines: There's many ways, Flatpak also supports OCI images so GNU Guix can be used for it too.
<cbaines>bavier[m], I was thinking one could maybe (ab)use translations to have an emoji locale or something, but I'm not sure how well that would work
<lle-bout>cbaines: Fedora builds OCI images for their Free Software only Flatpak repo
<cbaines>lle-bout, I quite like Guix's one way of building things, I'm not sure Flatpak makes building something from source as easy
<cbaines>(also, Guix doesn't yet produce OCI images, just Docker V1 images)
<lle-bout>cbaines: Flatpak's focus is not on a packaging/build tool, so that's normal I think :-)
<cbaines>lle-bout, I agree, but what I'm getting at is that lack of focus on providing users a way to effect change in the software they're using, is relevant when you consider distributing free software through it
<lle-bout>cbaines: I thought GNU Guix supported OCI, good to know it's only Docker V1 images.
<nckx>civodul: Same question (and expected answer) about . I think the first user is no longer snubbed?
<lle-bout>cbaines: I agree it comes off a little limited in thinking, they certainly consider with the distribution mechanism commonly used that users don't need to change the software - but what I am interested in with Flatpak is the sandboxing capabilities and those can be used without using the distribution mechanism as there can be "local" remotes from which you can install packages. GNU Guix could manage that local remote and allow us to
<lle-bout> launch sandboxed desktop apps with Flatpak (on a Wayland-only environment with the app using only xdg-portals and all for proper sandboxing)
<civodul>nckx: ah yes, mostly fixed by --cache-bypass-threshold \o/
<cbaines>lle-bout, yes, it would be really good to use the runtime isolation stuff.
<lle-bout>cbaines: I think that Flatpak when the eco-system has evolved towards it (Wayland, Portals, Pipewire, etc..) is the future for Linux secure desktop
<cbaines>lle-bout, you might be interested to know that thumbnail generation for nautilus (Gnome Files) happens in an ioslated manor, through bubblewrap
<lle-bout>cbaines: ah ok, didnt know
<nckx>civodul: ‘Mostly’? (I don't use the --cache... functionality myself.)
<mbakke>lle-bout: there is a mythical 'guix run' command (and patch) floating about which gives flatpak-like isolation for GUI applications
<mbakke>lately I've been considering the possibility of baking a container runtime into a guix profile
<lle-bout>joshuaBPMan: about Secure Scuttlebutt, I do use it from time to time, it's still maturing, I like the protocol underneath it, it feels quite minimal but it also has some shortcomings, though they are actively looking to solve them. I dislike that the software eco-system is based mostly on JavaScript and the protocol itself in the wild depends on the JavaScript implementation details some times but some have been trying to grow alter
<lle-bout>native eco-systems in Rust and Go, what pleased me is that the Rust eco-system was growing under the AGPL license but I think it isnt for the good reasons.
<lle-bout>mbakke: that sounds great
<joshuaBPMan>lle-bout Yeah I just saw that...It's weird having it built in javascript. That may make it hard to package in guix.
<lle-bout>joshuaBPMan: They've rewritten a largely underperforming database in JavaScript called Flume and it causes UX problems because being quite data-heavy some times Secure Scuttlebutt clients are slow to start especially when you are new to the network (sync)
<mbakke>nckx: thanks for the libreoffice reproducibility patch
<lle-bout>joshuaBPMan: Nonetheless the async paradigms of JavaScript really suit the protocol well. I don't think it's weird it's just that when they made it it doesnt seem like they considered it could exist in another language at some point.
<civodul>oh the mythical "guix run"
<civodul>mbakke: "container runtime" into a profile?
<nckx>More myths and legends.
<civodul>nckx: yeah you can just close it and say --cache-bypass-threshold fixes it ("mostly" because there's a threshold, but it can be arbitrarily high hey!)
<lle-bout>joshuaBPMan: I think JavaScript helped them create something that works quickly, especially when it comes to UI/UX. The limitations are starting to show though.
<nckx>mbakke: It's very ad hoc, I'm going to try which promises to fix this general issue much betterly.
<lle-bout>joshuaBPMan: It helped contributors come to contribute, even not so skillful ones. JavaScript is widely known. Secure Scuttlebutt mimics a web-like revolution sort of.
<mbakke>civodul: yes, as in all executables from that profile have a wrapper script that adds "--container --share=/foo=/bar" etc ... packages->containerized-manifest or something :-)
<mbakke>so that I can define "access rules" for each of my manifests
<mbakke>right now I have a variety of profiles that are sourced at login ... the "emacs" profile generally does not need network access for example, and I could use a separate instance for TRAMP.
<mbakke>and my mail syncing programs does not need access to all my personal files
<civodul>mbakke: ah yes, but you know what, i also had a mythical plan to have a package transformation option for that
<civodul>and since they're recorded, it'll just be wonderful
<mbakke>of course you do :-)
<civodul>so in a nutshell, we have "guix run" or a library like you describe
<civodul>and we can get the transformation option
<civodul>+ "guix run"
<civodul>let's make that happen for 1.3!
<mbakke>these transformation options really opens a whole lot of possibilities
<mbakke>sounds like a plan!
<lle-bout>civodul: what do you mean they are recorded?
<lle-bout>It looks exciting to me :-)
<mbakke>lle-bout: transformation options given on the command line are stored in the "profile manifest"
<rekado_>nckx: on bayfront I’m still running the goggles indexer in a loop
<mbakke>so they are played back on "guix upgrade", etc
<rekado_>nckx: so search should work
<nckx>rekado_: I think it's stuck, or not updating/searching the right database.
<nckx>Oh, Goggles is down.
<lle-bout>mbakke: okay! transformation options are like Scheme code transformations?
<rekado_>nckx: sorry, just restarted it to see if that fixes it
<nckx>rekado_: Anyway, try searching for ‘guix’ (or anything) and you'll see it stops at 11 Oct.
<rekado_>I see that
<rekado_>I’ll try to fix this tomorrow
<mbakke>lle-bout: as in command-line transformations such as "--with-input" or "--with-debug-info", see
<rekado_>(I think I did fix this before…)
<nckx>rekado_: Can anyone else touch it without su'ing to you or otherwise breaking your duct tape cathedral?
<rekado_>we aren’t using the service right now
<lle-bout>mbakke: so for sandboxing, this means one would install a package along with it's runtime options? And everything be wrapped in guix run?
<rekado_>nckx: so currently it’s served via duct tape + chewing gum
<rekado_>bit of pop corn kernels for structural integrity
<mbakke>lle-bout: yes, AIUI :-)
<civodul>duct tape scaffolding
<nckx>OK, I'll stay way back and watch ze blinkenlights.
<rekado_>if it’s not fixed by tomorrow afternoon please remind me
*rekado_ has to sleep
***nckx is now known as ncksneekx
***ncksneekx is now known as nckx
<nckx>(What did happen to sneek?)
<lle-bout>mbakke: that's cool! I am not sure what this will give, I have a feeling that this might have limitations but maybe not.
<lle-bout>mbakke: What I am interested in also is the ability to run two instances of the same applications with different runtime parameters, so I could install a "work-icecat" and a "personal-icecat" where both don't have access to the same data but still connect to the same Wayland server (when Icecat supports Wayland if not already).
<lfam>jonsger: No, I'm not using radicale. It was a test-suite dependency of vdirsyncer, which I am using. IIRC the vdirsyncer author was not very happy with the correctness of radicale, or of dav implementations in general
<mbakke>lle-bout: I also want that, and currently use a wrapper script for IceCat to achive a similar effect (without the isolation, of course)
<lfam>sneek: later tell jonsger: No, I'm not using radicale. It was a test-suite dependency of vdirsyncer, which I am using. IIRC the vdirsyncer author was not very happy with the correctness of radicale, or of dav implementations in general
<lfam>sneek is missing
<mbakke>ncksneekx: botsnack?
<nckx>I just ordered pizza a.k.a. nckxsnack.
<lle-bout>mbakke: combined with - this might be an interesting Qubes OS rebirth
<mbakke>lle-bout: indeed :-)
<mbakke>there is a Nix-based effort along those lines already whose name eludes me
<lle-bout>civodul: * powerpc64le supports IEEE128 long double libm/libc redirects when using the -mabi=ieeelongdouble to compile C code on supported GCC toolchains. It is recommended to use GCC 8 or newer when testing this option.
<lle-bout>From Glibc 2.32 changelog
<lle-bout>We are currently using gcc-7
<mbakke>lle-bout: we'll switch to GCC 10 on core-updates
<lle-bout>mbakke: didnt know about it, awesome!
<lle-bout>mbakke: GCC 10 by default?
<lle-bout>mbakke: cool! finally!
<lle-bout>mbakke: and what about bootstrapping?
<mbakke>lle-bout: I think our bootstrap GCC is able to build GCC 10 (at least it could GCC 9), if not we'll just add an extra step :P
<vagrantc>joshuaBPMan: i tried secure scuttlebutt for a while using manyverse, but my poor old device wasn't up to the task ... it was really fun while it worked, though
<lle-bout>mbakke: I would appreciate help on making the powerpc64le-linux-gnu steps so that it works, in short, it can't bootstrap using latest glibc like it does now
<lle-bout>mbakke: I think we should hardcode versions for all the tools used in bootstrap
<lle-bout>Right now it's "hardcoded" because we build bootstrap binaries once and never again but when you port new platforms it still uses latest versions which is not always good
<mbakke>lle-bout: will creating ppc64le bootstrap tarballs with GCC 10 do the job?
<lle-bout>mbakke: It will work better if these use Glibc 2.32 but that's only part of the problem - when we grow GNU Guix using gcc 5.5 (like current master), on powerpc64le-linux-gnu it can't build Glibc 2.32 using gcc 5.5
<lle-bout>Minimum version for powerpc64le-linux-gnu is gcc 6.2+ and even then, glibc 2.32 might require gcc 8, though they only recommend it so have to find correct build options.
<mbakke>lle-bout: but that is "just" a concern for an eventual Mes-based PPC bootstrap, right?
<lle-bout>With Glibc 2.31 and a single patch (--with-long-double-128 on bootstrap GCC and also during commencement) it worked OK, but I am afraid it will break again with Glibc 2.32 on core-updates
<lle-bout>mbakke: no, it's not using Mes at all now
<lle-bout>It works without GNU Mes, bootstrap binaries are just bigger
<mbakke>lle-bout: I mean that if we create new bootstrap tarballs on core-updates after the GCC 10 switch, then ppc64le-linux-gnu will "start" at glibc 2.32 and GCC 10, and not have to worry about other versions in the graph?
<mbakke>but admittedly you probably know better how the bootstrap works than me :P
<lle-bout>mbakke: currently make-bootstrap.scm creates gcc 5.5 tarballs, not gcc 10, it always starts at gcc 5.5
<mbakke>aah, I see
<lle-bout>mbakke: I am not sure I know it better, it's just so messy and confusing
<lle-bout>I'm not even 100% certain of what I just told you
<lle-bout>It's been two years now that I witnessed these issues on and off
<lle-bout>mbakke: look:
<lle-bout>glibc-for-bootstrap is always latest glibc however:
<mbakke>lle-bout: I suppose we "just" need to special case ppc64le in that file, not sure whether that will pose any technical difficulties
<lle-bout>It can't always work, Glibc will keep requiring newer versions of GCC for certain platforms (maybe not for the mature x86_64 probably)
<lle-bout>mbakke: I am not sure, probably that special case will need to be in more places and it will only get more messy there heh..
<lle-bout>mbakke: It uses gcc 5.5 because it's the last version that can be compiled with only a C compiler, and commencement.scm rebuilds gcc 5.5 with gcc 5.5
<lle-bout>That can be compiled with only a C compiler and supports compiling C++ code, which later GCC versions are made of
<mbakke>lle-bout: we don't have that limitation outside of the Mes bootstrap though, i.e. bootstrap tarballs for new architectures are cross-compiled with a modern GCC toolchain
<lle-bout>mbakke: I am not talking about this part, rather commencement.scm, building bootstrap-tarballs is always mostly fine