IRC channel logs


back to list of logs

<raghavgururajan>Hello Guix!
<dongcarl>Any way to do `guix environment` but for a derivation?
<leoprikler>dongcarl: not directly, but if it's the derivation of a profile and you have it built, you should be able to get the same profile back by extracting its manifest
<dongcarl>leoprikler: :-( Nah, trying to debug a derivation that isn't building properly...
<leoprikler>In that case, `guix build -K` might do what you want?
<jonsger> finally there are fast ARM server chips at the block :)
<dongcarl>leoprikler: Oh, I thought that just kept the files, but not the actual environment/container, right?
<leoprikler>There is a file called "environment-variables", that you can source to get back the build environment.
<leoprikler>beware though, you might be missing important stuff like ls in that
<dongcarl>leoprikler: Let's see if it's good enough to at least reproduce the failure :-)
<dissoc>why use (define-configuration ...) vs using a config record?
<dissoc>for services
<guixy>because scheme!
<guixy>That's just a guess...
<dissoc>i noticed some services will use either. and im not sure why. i guess i need to learn a bit more from the (gnu services configuration) module
<guix-vits>guixy: is the offloading ssh keys allow non-interactive login? offloading cannot enter a passphrase.
<guixy>guix-vits, yes, I'm loggin in with ssh keys, and other non-interactive commands work.
<guixy_>I checked that the account in question doesn't require a password to use sudo.
<guix-vits>guixy: maybe check the hash of keys, as stored by guix-authorize?
<guix-vits>if it exposes them
<guix-vits>guixy: also i remember, if ip changes, then ssh asks if it should add the fingerprint to known hosts. may it be the reason for guix vs manual sessions?
<ride>Hello! I am trying to adapt the following article for Guix System.
<ride>Since lvm2 support is new I am having trouble figuring out how to use it in the config.scm file. I found how to do mapped-device so I assume it is something similar.
<ride>There are also no mentions of crypttab in the manual, so I assume it is determined by the config file.
<rekado_>dissoc: specifying record types for configurations gets old really fast when you have lots of fields
<rekado_>the define-configuration macro takes care of a whole lot more: it also lets you weave in documentation and provide generic serialization procedures that turn any concrete configuration value into a file
<rekado_>define-configuration provides a unified method to, well, define configurations, something that is otherwise done in an ad-hoc fashion with alists and custom record types.
<rekado_>so “because scheme” is actually a pretty good answer
<dissoc>rekado_: thank you. that completely answers my question
<dissoc>only problem with that is im not that good at scheme yet
<rekado_>define-configuration lacks documentation, but there are a number of services that use it
<dissoc>getting there. and definitely loving guix thus far
<rekado_>sometimes you don’t need to be good at Scheme, you just need to know where to copy from.
<dissoc>i can do a reasonable job reading scheme. i only lack the experience to write good scheme when there's not an existing example of something similar as to what i need to do
<rekado_>(gnu services ldap) shows that you don’t need much to use define-configuration
<rekado_>that’s because in that configuration all fields accept primitive values
<rekado_>(like string, boolean, number)
<rekado_>for those we already have obvious ways of serializing them
<dissoc>i tried using define-configuration where the previous services i wrote just used records. but i got some errors about some serializing function not being found. i dont remember the specifics
<dissoc>error: serialize-string: unbound variable
<dissoc>that was the one
<rekado_>in (gnu services cups) you see a definition for serialize-string
<dissoc>yeah. i saw those other places too
<rekado_>the macro assumes that for every field type you also have a serialization function defined
<dissoc>i got it. i just dont see how i would ever know to need to include that by just using the macro
<rekado_>that’s not your fault. The documentation for this is completely absent.
<dissoc>it all makes sense now. at first im looking at these error messages trying to hunt down my serialize-string that doesnt exist
<dissoc>i appreciate your help. i feel like i understand it a lot more now
<kozo[m]>Hey, I am attempting to guix pull and reconfigure and am getting the following error:
<kozo[m]>My config has not changed so I think it's something else that has changed.
<lfam>kozo[m]: Are you using a revision of Guix before or after this commit? <>
<lfam>It's from today, and it's supposed to fix a bug like that, if I understand correctly
<lfam>I guess, if you are between 6a060ff27ff68384d7c90076baa36c349fff689d and d88ff09ea3138fc85c1463b0 you will get that bug
<kozo[m]>I know how to find my commit using guix describe, I do not know where to go to see where it fits in
<lfam>What commit do you have?
<lfam>You could compare it to the Git log, but if you aren't familiar with Git, we can help you. <>
<kozo[m]>commit: ec2eccbf3d1a6378c5ebf1e3d17ec72b4b2a4cd0
<kozo[m]>Do I need to do a guix pull --commit=? to get around this bug?
<lfam>I don't believe you are hitting that, because you're using a commit that pre-dates when the problem was ostensibly introduced
<lfam>I do recommend pulling to commit d88ff09ea3138fc85c1463b0b345bd6ba71ca568, which contains the fix
<kozo[m]>Thank you lfam
<kagevf>I'm trying to get started with guix, but when I install a package it fails ... I tried to install the "hello" package and glibc ... I get errors that look like this:
<kagevf>building /gnu/store/3lv7bg1vxkpi3igx5zhr80glr4zwywa4-bzip2-mesboot-1.0.8.drv...
<kagevf>\ 'build' phasebuilder for `/gnu/store/3lv7bg1vxkpi3igx5zhr80glr4zwywa4-bzip2-mesboot-1.0.8.drv' failed with exit code 1
<kagevf>build of /gnu/store/3lv7bg1vxkpi3igx5zhr80glr4zwywa4-bzip2-mesboot-1.0.8.drv failed
<kagevf>if I look in the log, toward the bottom, it has this:
<kagevf>starting phase `build'
<kagevf>make: stat:Makefile: sterror: unknown error
<kagevf>make: *** No rule to make target `bzip2'. Stop.
<kagevf>command "make" "CC=tcc -I ." "AR=tcc -ar" "bzip2" "PREFIX=/gnu/store/s94hyrv1vgllxir5niiyzfc9g80l5kcd-bzip2-mesboot-1.0.8" failed with status 2
<guix-vits>hello. did u ran a `guix pull`?
<kagevf>yes, I think that also failed ... let me try again
<guix-vits>how did u installed guix?
<guix-vits>mesboot is strange to see. did u enabled substitutes (binary downloads)?
<kagevf>I followed the guide here:
<kagevf>btw, I'm trying to install guix as a package manager on top of Ubuntu 18, not stand-alone guix
<kagevf>ok ... I clearly didn't enable substitutes .... did that step and am re-doing guix pull ... seems to have done the trick ... thank you for the idea, guix-vits
<clone11>Under what conditions can the repos contain two versions of a package? I was trying to use rails with only guix packages, and the version of ruby-sqlite3 doesn't work with ruby-rails. You don't *need* sqlite3 for rails, so I don't know if the older ruby-sqlite3 could be added
<ryanprior>clone11: you can add another version of ruby-sqlite3 for compatibility. Is that the only reasonable solution? Would an updated version of Rails be compatible with the new package?
<ryanprior>Or if it's a trivial incompatibility, would a small patch to the new ruby-sqlite3 be sufficient to add legacy support?
***sneek_ is now known as sneek
<Gooberpatrol66>aaaaaaaagh why does guix gc need free disk space to function
<lfam>Gooberpatrol66: Could you send a bug report about it? I agree it would be nice to be able to free space when there is none
<Gooberpatrol66>lfam: sure
<ATuin>I'm getting this "guix system: error: symlink: File exists: "/etc/nix"" when running system reconfigure, dunno why is that happening, any idea?
<cbaines>ATuin, I'm guessing you have the nix service in your system configuration?
<cbaines>It generates a configuration file to go in /etc/nix
<iyzsong-w>ATuin: you can delete '/etc/nginx' then run again..
<iyzsong-w>um, '/etc/nix' i mean
<cbaines>iyzsong-w, that's probably an unrelated directory?
<cbaines>Anyway, I'd maybe check what it is and what's there before deleting anything
<ATuin>yes i have it
<ATuin>i can try sure, actually that file is not a symlink
<iyzsong-w>commit 8e73bf754f9 changed the way '/etc/nix' was created. if you have it before, then it will error like this i guess.
<ATuin>iyzsong-w: probably related since i never had this problem, so it makes sense
<iyzsong-w>yes, before it's not a symlink, but now it is.
<ATuin>yeah, that sounds like my problem, i will backup the file and delete it
<ATuin>yeah it worked
<ATuin>and now it's a symlink with the configuration for the new version!
<ATuin>thansk iyzsong-w and cbaines :D
***apteryx is now known as Guest53337
***apteryx_ is now known as apteryx
<efraim>guix package -I | cut -f1,2 --output-delimiter=@ | sort -u | guix refresh --list-transitive | tr ' ' '\n' | sort -u | guix lint
<mbakke>uff, texlive fails to build with GCC 10
<mbakke>any takers for TeX Live 2020? :)
<mbakke>efraim: that's a clever way to lint your installed packages and their dependencies :-)
<mbakke>maybe throw a 'uniq' in there?
<mbakke>oh, sort -u, nvm
<guix-vits>efraim: don't post pipelines, or BlackMug will come for us.
<efraim>I could probably drop the first sort-u
<aecepoglu[m]>Is a golang importer going to be added at some point?
<aecepoglu[m]>I saw someone's merge request but that's been there for over a year now
<dftxbs3e>nckx has disappeared, weird! hope they are fine!
<janneke>sneek: seen nckx?
<sneek>nckx was in #guix 5 days ago, saying: jackhill: ppc64 == ppc64be(-only)?.
<dftxbs3e>janneke, hello! yep 5 days.. may just be life catching up to them
<janneke>dftxbs3e: hi; yes let's assume that or something season-related
<janneke>sneek: seen dannym?
<sneek>dannym?, pretty sure was seen in #guix 4 days ago, saying: Anyway, just wanted to know what it is for in the first place (personally, my channels always worked without that file--maybe Heads' engineers are doing something unexpected...).
<dftxbs3e>janneke, they wanted to handle installation of GNU Guix on the OSUOSL ppc64le CI machine we were donated and since they're the only ones with access AFAICT them being absent means we are stuck not being able to add powerpc64le-linux-gnu to official GNU Guix CI
<jgart[m]>Would someone be able to help me track down unpackbootimg in guix?
<jgart[m]>It is an android tool
<dftxbs3e>jgart[m], track down? what do you mean?
<jgart[m]>It is used by the replicant project:
<jgart[m]>I don't see that it is in android.scm
<janneke>dftxbs3e: right, that would be nice
<jgart[m]>is it bundled with some other package?
<jgart[m]>or does it need to be packaged?
<dftxbs3e>jgart[m], it might be bundled yes
<dftxbs3e>not "bundled" exactly, but some packages in the GNU Guix sense have multiple binaries as output
<jgart[m]>do you happen to know what it is bundled with?
<jgart[m]>right, multiple outputs
<jgart[m]>any help is greatly appreciated
<jgart[m]>I will keep looking, nonetheless
<dftxbs3e>jgart[m], looking at it
<dftxbs3e>it isnt in the mkbootimg package
<abcdw>Hi guix! Writing you from freshly installed Guix System)
<dftxbs3e>abcdw, hello :-)
<dftxbs3e>jgart[m], seems it might be unpackaged
<dftxbs3e>jgart[m], it doesnt seem packaged in debian either so
<jgart[m]>parabola has it
<jgart[m]>it's part of android-tools
<dftxbs3e>jgart[m], debian sid seems to contain it:
<dftxbs3e>may be a version thing
<dftxbs3e>it's named unpack_bootimg and not unpackbootimg in parabola
<dftxbs3e>and debian too
<dftxbs3e>jgart[m], seems to come from:
<dftxbs3e>jgart[m], mkbootimg package might need modification here
<dftxbs3e>jgart[m], if you look: (install-file "mkbootimg" bin)
<dftxbs3e> (install-file "bootimg.h" include)
<dftxbs3e>it only installs those two
<dftxbs3e>so even if it built more binaries (like unpack_bootimg) it wont install them
<jgart[m]>dftxbs3e: would it be a matter of just creating a new package that inherits from mkbootimg?
<jgart[m]>or should unpack_bootimg be bundled with mkbootimg?
<jgart[m]>or am I confused? haha
<dftxbs3e>jgart[m], I think putting them both inside is fine given you update the description but you can also create another package
<dftxbs3e>I just tried what I told you it doesnt work (with unpack_bootimg)
<dftxbs3e>neither with unpackbootimg, so it's not there
<jgart[m]>you tried (install-file "unpack_bootimg" bin) ?
<dftxbs3e>jgart[m], yes
<dftxbs3e>jgart[m], I think it's a version thing, in debian sid it only exists since recently
<dftxbs3e>jgart[m], look :
<dftxbs3e>history is all new
<jgart[m]>thanks for sending, I'll take a look now
<jgart[m]>Here's the wiki from the replicant project where they use unpack_bootimg in case you are interested:
<abcdw>Getting strange error: bob@antelope ~/work/rde$ guix system -L . build rde/system/desktop.scm
<abcdw>ice-9/eval.scm:223:20: In procedure proc:
<abcdw>error: %rde-emacs-packages: unbound variable
<abcdw>hint: Did you forget `(use-modules (rde emacs packages))'?
<abcdw> The source code explicitly requires mentioned namespace:
<dftxbs3e>jgart[m], I see well they must've only tried on Parabola
<dftxbs3e>jgart[m], It seems unpack_bootimg may only be part of android-platform-system-core 10.x
<dftxbs3e>or there's two different ones
<jgart[m]>could be
<dftxbs3e>jgart[m], in that last case I couldnt find link to source code Replicant is referring to
<jgart[m]>they might be using trisquel to build the kernel, atleast that's what it looks like from the wiki I linked above
<abcdw>The required namespace provides a variable: Do anyone know what am I doing wrong?
<jgart[m]>replicant also packages their own tools as an archive
<dftxbs3e>abcdw, I think you're using the wrong use-modules directive not sure
<dftxbs3e>Try actually using (use-modules (rde emacs packages))
<dftxbs3e>but I'm no expert
<dftxbs3e>abcdw, the variable export is commented, maybe uncomment that?
<dftxbs3e>abcdw, uncomment: ;; #:export (%rde-emacs-packages
<dftxbs3e> ;; emacs-rde-core)
<abcdw>dftxbs3e, The both use-modules declaration should do the same, but I tried both.
<jgart[m]>dftxbs3e: replicant releases their own signed unpackbootimg here
<jgart[m]>abcdw: I've been digging your video posts. I was watching a few the other day
<abcdw>dftxbs3e, define-public should do export as I found in documentation, but I tried to use #:export too. Doesn't help(
<dftxbs3e>jgart[m], yes but where did they compile it from?
<jgart[m]>not sure yet. Looking into that
<abcdw>jgart[m], hope you enjoyed)
<dftxbs3e>abcdw, I'm sorry I can't be of much help here, wish I was better at GNU Guile and Scheme :-)
<dftxbs3e>also your videos come off as great ones, will take a look some day :-)
<abcdw>dftxbs3e, Thank you anyway (: Hope I'll figure out, how to fix it.
<dftxbs3e>janneke, I could setup the machine myself but they insisted on doing it themselves to learn, I'm all for that but they went away aaah
<dftxbs3e>hopefully they come back soon so we can have official powerpc64le-linux-gnu CI :-)
<xelxebar>Found a quirk/bug in `guix system rollback`. When running with --dry-run, it "rolls back" from the system pointed to by /run/current-system; however, without --dry-run, it rolls back from /var/guix/profiles/system. This means that if you `rollback` while booted into an older generation, --dry-run gives misleading information.
<guix-vits>xelxebar: are u sure?
<jgart[m]>abcdw: brettgilio had a nice emacs guix deployed config but last time I checked it is not up anymore
<janneke>dftxbs3e: oh
<jgart[m]>abcdw: brett might be someone to ask
<guix-vits>when booted in older sys, aren't rollback expected to go Back from There?
<guix-vits>xelxebar: try numeric arguments to rollback --dry-run.
<guix-vits>(i may be right)
<abcdw>dftxbs3e, cool, let me know what do you think, when you will watch.
<abcdw>jgart[m], thank you for pointing, trying to find his configuration, but not successed yet)
<jgart[m]>I don't think that config is up anymore
<jgart[m]>I might have cloned it somewhere but I can't find it now :(
<jgart[m]>maybe someone else in the guix community has something similar? i.e. a way to deploy your emacs user configs with guix
<jgart[m]>abcdw: do you know of this project?
<jgart[m]>I proposed two new config ideas but I haven't had time to work on them yet :(
<jgart[m]>one for nnn file manager and one for redshift
<jgart[m]>I imagine these won't be too difficult to implement
<abcdw>jgart[m], Yep, I plan to take few ideas from it, but my current problem is more guile related. I just don't understand what I did wrong)
<jgart[m]>what builld errors are you getting?
<abcdw>jgart[m], Posted them two screens above. and links to related source code.
<jgart[m]>ok, I'll take a look. thanks
<abcdw>jgart[m], thank you) I countinue playing with this code, but still doesn't work.
<brettgilio>jgart[m] abcdw I have it hidden on sourcehut. Ill drop a link when I get to work
<abcdw>brettgilio, Thank a lot, would be glad to take a look at your config structure.
<PurpleSym>`guix system build` started failing somewhere between 7a2897149d60816c33c63b7b7254ad283f8c3602..7530e491b517497b7b8166b5ccecdc3d4cdb468d:
<dftxbs3e>abcdw, I will! :-)
<dftxbs3e>cbaines, hello! what about that GNU Guix Build Coordinator thing? How much disk space do you recommend? I got a VM on that powerful dedicated server ready.
<jeko>I can't find the info manual for Guile in Emacs 🤔️
<dftxbs3e>jeko, 'Guile Reference'
<jeko>dftxbs3e: I don't see it in the info list…
<jeko>is it installed with "guix install guile" ?
<jeko>or do I have to specify outputs ?
<roptat>it's installed with guile
<jeko>that's weird, I can see the Guix manual, and others like Guile Hall, Guile Config, but not Guile !
<vldn>Does somebody has any idea where i could find resources on writing an importer?
<leoprikler>Looking at existing importers and seeing how they do stuff might be a start.
<leoprikler>Basically your importer has to do two things:
<leoprikler>First, convert a name into an URI
<leoprikler>Second, download a package (description) from that URI and write a `(package (...))` expression
<vldn> seems not the right path for the importer scripts in "guix import .." am i right?
<jonsger>does guix pull + guix system reconfigure work for you? I get for /gnu/store/kh19r1pwqmzh2cr8mx5cphii5rq91nxv-module-import-compiled.drv
<jonsger>my "educated" guess would be
<vldn>i'm not on a guix system right now to run the code but ty :)
<vldn>ah not meant for me :D
<PurpleSym>jonsger: I’ve had the same issue before. See ↑
<leoprikler>Is there a way to convert all source files in a package to UTF-8?
***samis is now known as CompanionCube
<jcf>Hello everyone! I'm on the cusp of a failed drive and will have to rebuild my OS as a result. I've been thinking about moving to Guix for a while now and this could be the time to do it, but I have a couple of concerns/questions. Firstly, I'd like to move away from btrfs and over to ZFS (inspite of the disappointing license) and I need to encrypt data as I deal with personal data at work.
<jcf>I see a ZFS package is available but wonder if I can use a "zfs" type of file system with Guix…?
<jcf>I also have two Nvidia GPUs that I use for work that'll need some support (from proprietary blobs no doubt). I'm lead to believe I can download binaries for Nvidia if necessary to get that stuff working too. :fingers-crossed:
<dftxbs3e>jcf, hello!
*dftxbs3e reads
<jcf>hi, dftxbs3e! :wave:
<dftxbs3e>jcf, ZFS is not supported at all currently as a root file system on GNU Guix, but you can try programming that on your own, I am not sure it will be accepted upstream though, but it doesnt need to. About NVIDIA, same story, no support at all from GNU Guix upstream but you can hack your GNU Guix System configuration for that. You'll have to learn some GNU Guile's Scheme.
<dftxbs3e>jcf, for encryption, LUKS works well and is supported by GNU Guix
<jcf>I'm using LUKS and btrfs now, and I'm pretty happy with it. I have a FreeBSD box with ZFS that I'd love to be able to `zfs send` to though. :)
<dftxbs3e>jcf, Have a look at the commit log for what it took to add btrfs support in GNU Guix:
<jcf>The only thing I'm missing is something like Arch's pacstrap and their chroot. I was hoping I could build my Guix OS without having to boot into an installer.
<dftxbs3e>jcf, You can totally do that, you can use the installer and the shell-based method where you can do anything you want really
<jcf>Oh, cool! If I can have Emacs and a full-blown Linux machine running alongside it'll make this so much easier!
<dftxbs3e>jcf, GNU Guix allows you to install anything during the install (even shell-based method)
<jcf>It looks like the btrfs support uses GRUB. I can make that work with ZFS I think.
<dftxbs3e>jcf, what the installer does is: Create user accounts, partition, encrypt and/or format disks, and then generate configuration based on user input
<dftxbs3e>It is not possible to repartition using GNU Guix System configuration
<dftxbs3e>You must do it before-hand, and then tell a UUID to GNU Guix System in the configuration
<jcf>Oh, that's interesting. I should look into other limitations of the system configuration.
<dftxbs3e>I wouldnt say it's a limitation, it's intended that way!
<jcf>To prevent accidental data loss?
<dftxbs3e>jcf, not sure exactly but it feels right to me that way
<dftxbs3e>Disk repartition cannot be rolled back
<jcf>That makes sense.
<vagrantc>almost everything is installed to /gnu/store ... so it's not really possible to do a whole lot with partitioning other than the home dir
<vagrantc>metadata about /gnu/store is in /var/guix ... and one without the other isn't very useful
<dftxbs3e>jcf, look at for manual installation (still within the installer with a shell)
<jcf>dftxbs3e: I have that page open in a tab in my browser. :)
<cbaines>dftxbs3e, hey, I've read your message about the Guix Build Coordinator now. 40GB is probably fine for disk space, more just means you can garbage collect less frequently
<dftxbs3e>cbaines, OK! I'm ready to install that service for you, besides UUID and password don't I need a remote host?
<dftxbs3e>If you can give me an example service configuration bit I'll just paste it
<cbaines>dftxbs3e, wonderful, I'd perhaps have a look at the configuration here for the fosshost machines
<cbaines>In particular, maybe the ntp service isn't relevant for a VM, I don't know. The mcron GC config is probably useful.
<cbaines>dftxbs3e, I'll message you on IRC in a moment with the UUID and password to use
<cbaines>other than that, you'll need to tune the authorized keys similar to the fosshost machine
<dftxbs3e>cbaines, Thanks!
<dftxbs3e>cbaines, could it also be used with powerpc64le-linux-gnu by any chance?
<dftxbs3e>What's the difference with cuirass?
<dftxbs3e>Can it use configured offload systems as well?
<apteryx>Anyone mastering the Guix state monads? :-) I'd like to further my current (fairly limited) understanding of it. Regarding the example in 'info "(guix) The Store Monad"', that defines a 'square' (monadic?) procedure; when ran with 'run-with-state', it needs to be wrapped in something like 'sequence' (from the same example) from (guix monads), else it fails. Why can't I simply (run-with-state
<apteryx>%state-monad (square 2) 0) ?
<cbaines>dftxbs3e, yeah, I'd love to get things building on more architectures. You'll either need hardware or the qemu-binfmt service configured with the relevant architectures plus guix support
<cbaines>Then there'll need to be some stuff on the Guix Data Service side to generate the derivations. I can see the branch here but I probably need to do something to get the right derivations out
<mbakke>dftxbs3e: I have a working GCC 10 for 'core-updates', cross-compiler and all. Do you think it would make sense to use that to generate the ppc64 bootstrap tarballs?
*mbakke attempts TeX Live upgrade for 'core-updates' for GCC 10 compatibility
<leoprikler>Quick opinion poll: esoteric programming languages in Guix, yay or nay?
<cbaines>dftxbs3e, as for the differences between the Guix Build Coordinator and Cuirass, it's hard to put succinctly. With the Guix Build Coordinator, you give it derivations and it'll handle building them, potentially across many machines. With Cuirass, you give it a specification, and it'll evaluate it, producing derivations, which it'll then build (and with offloading that can happen on other machines)
<dftxbs3e>cbaines, I have hardware and non-upstream GNU Guix support
<cbaines>dftxbs3e, awesome :)
<dftxbs3e>cbaines, it works with branch wip-lle-bout-le1
<dftxbs3e>mbakke, awesome! yes we can definitely try!
<dftxbs3e>mbakke, I read your message earlier about missing leading / - glad it's just that
<dftxbs3e>cbaines, so Guix Build Coordinator does not support using offloading?
<mbakke>dftxbs3e: sounds great :-) I'm still working my way up to the native 'guix' package, but hope to push it in a few days
<cbaines>dftxbs3e, as for offloading. there's no reason I can see why that wouldn't work. But you'd probably be better off just running the Guix Build Coordinator agent on each machine you want to perform builds
<dftxbs3e>mbakke, if you can give me dirty patches I can apply them on top of existing core-updates and try
<dftxbs3e>cbaines, GNU Guix System isnt supported yet on powerpc64le-linux-gnu, just on top of another distro for now
<mbakke>dftxbs3e: awesome, will send in a few minutes
<dftxbs3e>mbakke, I could also give access to a powerpc64le-linux-gnu VM directly if you wanted
<mbakke>dftxbs3e: interesting, might take you up on that if there are problems at least ;-)
<cbaines>dftxbs3e, you can run the agent on a foreign distro, that should work fine (and I want to do this for testing builds on foreign distros)
<dftxbs3e>cbaines, let me try installing it there then
<dftxbs3e>cbaines, what would the command line be like?
<guix-vits>leoprikler: > esoteric languages saruman_so_u_have_chose_death.jpg
<cbaines>dftxbs3e, something like this but with the options more like the fosshost config I shared earlier, I'll make a more relevant example in a moment
<cbaines>dftxbs3e, if you're going to run it from systemd or something similar, I'd perhaps use the Guix package, but if you're going to run it something like a regular user through screen, then I'd clone the Git repository and run it from there
<cbaines>dftxbs3e, here's a relevant command line example
<dftxbs3e>cbaines, Thanks, looking at it now
<dftxbs3e>cbaines, I'll be using screen first
<ride>Hello. Is anyone familiar with using lvm on Guix System? I am trying to figure out how to set up full disk encryption. There is not much documentation with it being so new.
<cbaines>dftxbs3e, great, the Git repository and screen is the setup I use on a few machines, which means it's sort of tested at least
<mbakke>ride: LVM is not yet supported for the root file system
<ride>mbakke: Thank you for letting me know, that is unfortunate. Do you know what is keeping it from being supported?
<mbakke>ride: I think just no one worked on it yet. It should not be too difficult if you are looking to get your feet wet with Guix. ;-)
<ride>I'm still reading the manual. Maybe I will try once I understand the system better!
<lfam>Hi mbakke
<mbakke>sup lfam
<lfam>Have you checked on the build of the staging branch? I'm not sure from here if it's actually building or not
<lfam>Maybe it's expected, but there are still dozens of Rusts to build
<leoprikler>guix-vits: Have I? I could maintain my own channel, if there's no interest whatsoever.
<leoprikler>We do package stuff like sl and lolcat, so…
<mbakke>lfam: I have not! I suppose the Rusts are mostly taken care of by the "ungrafting" branch, if that is still going.
<cbaines>lfam, maybe someone can expidite that by just asking the guix-daemon on berlin to build the rust at the end of the chain. I have access so I can do that
<lfam>cbaines: Yes, that would be helpful, assuming berlin can handle it
<cbaines>leoprikler, I think the serious answer is yes, esoteric programming languages are fine. The normal packaging standards apply, like building from source (which is sometimes hard with languages)
<lfam>Speaking of esoteric programming languages, yesterday I added an esolang module on behalf of someone
<leoprikler>Welp, gotta handle some merge conflicts once I pull then
<lfam>`git pull --rebase` is how I handle it :)
<guix-vits>leoprikler: aren't they have the independent compilers an such? isn't much work?
<leoprikler>In this case the compiler only needs flex, bison and the GCC toolchain.
<cbaines>lfam, something's happening (or not)
<lfam>Thanks cbaines
<guix-vits>leoprikler: ah, i thought you compiling the Rust lang. :|
<leoprikler>Well, Rust is esoteric to some, but I'm talking about a different kind of esoteric.
<lfam>cbaines: I've been using the "broken" comparison tool that you showed me. I'm curious about the base and target datetimes. Are they the dates of when a Cuirass evaluation was started? Or when a particular build was started? Or completed?
<guix-vits>leoprikler: C+- from Gnu humor?
<lfam>Ideally, I could compare the results of particular Git pushes, but I know that Cuirass doesn't build every push
<cbaines>lfam, that page compares branches, and you specify the commit on the branch through the date and time. If you omit those parameters, it just defaults to now.
<leoprikler>guix-vits: is that an actual language with a compiler?
<leoprikler>or interpreter whatever
<cbaines>lfam, if you know the two commits you want to compare, you can use
<cbaines>otherwise is nice because you can specify branches
<lfam>Ohhh, that's why the first page is called "compare-by-datetime"
<cbaines>lfam, yeah, I was going to make a compare branches page, but then I realised I could just use the datetime comparision (which I'd originally written for comparing master with master 1 week ago, for the automated weekly news thing)
<lfam>The compare-by-datetime interface has some other nice selectors, like System and "Build change"
<cbaines>when you click through to the package derivations page, they should be pretty equivalent in functionality
<guix-vits>leoprikler: it is joke from old maillist
<leoprikler>Yeah, just saw it.
<dftxbs3e>mbakke, thanks a lot for patches!
<lfam>Ah, thanks cbaines. That's what I'm looking for
<cbaines>lfam, and it looks like there are actually some packages showing as broken on staging but working on master... whether they're false positives or not remains to be seen I guess
<lfam>Those ecl packages, cbaines?
<lfam>I'm looking at this:
<dftxbs3e>cbaines, setup is done for a VM on the AMD Epyc machine, btw it has 64GB SSD (RAID1 on 3 SATA SSDs with ZFS and the disk image is a block device from ZFS), 32 cores and 32GB of RAM (with memory ballooning, min 2GB, max 32GB)
<lfam>It's the HEAD of staging and a master commit from last night
<cbaines>lfam, I see, I'm looking at which shows a few more things (but not ecl for some reason)
<cbaines>dftxbs3e, awesome, I can see it's started building things, which is exciting
<cbaines>(I've got a Grafana dashboard here )
<lfam>cbaines: I see ecl-numcl in the broken results from your link. Do you see it there, too (I just want to know if it's consistent)
<lfam>That, psyclpc, and a handful of python packages
<cbaines>lfam, yeah, I think I'm seeing what you're seeing
<lfam>I'm unfortunately used to inconsistent results from Cuirass :/
<cbaines>lfam, the only oddity I'm aware of with this page is there's an issue with "Limit results". Sometimes nothing will show with the default value of 40...
<lfam>I see
<lfam>I'll always want to see them all, anyways
<mbakke>np! let me know if I can help with anything wrt bootstrapping, I assume we need some adjustments in make-bootstrap.scm to actually make use of it
<mbakke>dftxbs3e: ^
<cbaines>dftxbs3e, are you planning to run two agents then, with one being on the powerpc machine?
<dftxbs3e>cbaines, yes!
<dftxbs3e>mbakke, I will, but probably I can take care of that part, I've done it already.
<cbaines>dftxbs3e, cool, I'll send you a second UUID+password to use for the second agent then
<leoprikler>guix-vits, lfam: In case you're interested, it's 45274.
<dftxbs3e>cbaines, Is this part of the "more automated patch merging" thing mentioned in the manual?
<dftxbs3e>If so then I'm more than enthusiastic, feeling a bit of a human bottleneck some times
<lfam>leoprikler: Sounds amusing :)
<dftxbs3e>I feel like we would gain from electing package-specific maintainers etc.
<dftxbs3e>And provide expected maintenance status for packages, so users don't install stuff they can't rely on for security updates etc.
<dftxbs3e>E.g. the syncthing package is very out of date, latest is 1.12.0 and GNU Guix has 1.5.0
<leoprikler>I feel as though that just decreases the bus factor and increases stress for everyone.
<dftxbs3e>I tried updating it but it's not so trivial with the lack of go importer
<dftxbs3e>leoprikler, what do you mean the bus factor?
<dftxbs3e>Maybe rolling release is just that, but it isnt clear to me exactly that's what to expect
<leoprikler>How many people can simultaneously go on vacation without shit hitting the fan, otherwise known as truck factor.
<dftxbs3e>I see
<leoprikler>I personally feel quite empowered by "Everyone can update packages, provided they have the knowledge to do so."
<lfam>dftxbs3e: I've been thinking of removing the Syncthing package actually (I'm the person who did almost all the work for it)
<leoprikler>It recently helped me fixing wine, for example.
<lfam>Perhaps, removing all the Go packages
<lfam>It's not so easy to make a decision here
<cbaines>dftxbs3e, I hadn't actually seen that bit in the manual, but yes, if by some means reviewing patches can be more rigerous, less time consuming, and people without commit access can be empowered and supported, then I think quite a few things will improve.
<dftxbs3e>leoprikler, oh I mean everyone would still be able to, just that there would be identified people who are doing the work there more often than not
<lfam>In practice, I was the package-specific maintainer. But ultimately, I stopped doing the work
<lfam>I don't really see the difference from if I was designated officially
<dftxbs3e>lfam, still good to know you are the original person, I could've checked git honestly for it.
<dftxbs3e>I use syncthing so it's very useful for me
<lfam>I simply ran out of energy to do that work for free
<leoprikler>I think people gather enough clout on IRC without being designated maintainers :)
<lfam>Yes, I use it extensively
<cbaines>One of the less important one is maybe having commit access becomes less relevant, and that's good because it would be good to scale up the number of engaged voluenteers without having more attack surface by having more committers.
<leoprikler>cbaines: on the flip side, you add an attack vector in the CI that does automatic builds and pushes
<dftxbs3e>lfam, I understand, I run out too. It would be nice somehow warning users a package is unmaintained or lagging behind
<leoprikler>It's a tradeoff :)
<lfam>I understand that, it's why I've considered removing it
<leoprikler>dftxbs3e: `guix refresh`
<lfam>I think my expectations are a little different. In traditional distros, Syncthing would not be considered out of date
<dftxbs3e>I would think of a middle ground, not removing but warning
<lfam>The expectation of continuous updates is not really universal yet
<cbaines>leoprikler, indeed. Even though the manual says that, I don't believe there's an actual plan anywhere for having some automated way of pushing to master. There's plenty of good stuff that can happen before that at least.
<lfam>I've warned about issues with Go support several times
<dftxbs3e>leoprikler, guix refresh doesnt cover Go things yet, heh
<lfam>Go (and Rust) doesn't fit the paradigm of a "distro" as we understand it
<dftxbs3e>lfam, Ah well.. sorry, my email provider flagged GNU mailing list subscriptions as spam so I don't read as attentively anymore..
<lfam>Simply put, we merely get in the way from the point of view of Go programmers and users
<lfam>Those languages handle distribution and deployment on their own
<dftxbs3e>lfam, also npm? Isnt GNU Guix intended to help tackle those?
<lfam>Now, there's nothing wrong with Syncthing 1.5.0, afaict. The software has been rock solid for years
<leoprikler>lfam: I'd disagree and say, that languages with a built-in package manager get in the way of actual package management in any distro ;)
<lfam>Sure, leoprikler :) Same difference
<cbaines>even people writing Go seem to have come around to the realisation that commiting the source code for your dependencies to your projects Git repository has some downsides...
<lfam>My point is that Go programmers are not interested in helping
<dftxbs3e>lfam, 1.5.0 may be fine, I'm not sure there has been any security updates since then that's why
<lfam>They don't see the value we provide
<lfam>There have been security fixes in Go itself, which is where basically all security research happens for Go
<dftxbs3e>lfam, For users there's clear value to still have distro handle these things I think
<guix-vits>leoprikler: `guix system` -> el. ogind: network manager, u as awful as unpatched apache!
<lfam>Nobody really pays attention to security in Go because nobody can understand what is actually deployed, because it exists outside of traditional tooling
<dftxbs3e>I feel better getting all my packages from an entity sharing some ideals/political ideas
<lfam>Well, that's why I did the work for a few years
<lfam>I'm definitely interested in picking it up again... if there was some support
<leoprikler>dftxbs3e: Guix usually patches CVEs, so as long as it *can* do that, you should be safe.
<dftxbs3e>Some support from where? People you mean? Like me? :-)
<guix-vits>action I, scene IV...
<lfam>Just, any kind of support dftxbs3e. From people helping improve the go-build-system, working on upgrades, `guix refresh` support, financial...
<leoprikler>[Enter Guix and Javascript]
<lfam>Sadly I didn't make it easy for people to help in the past :(
<leoprikler>Guix: You are as hideous as Rust without any of the benefits of static typing.
<lfam>I hoped that by stepping away, it would make some space for others to step in
<leoprikler>Javascript: You are as outdated as Debian. Speak your mind!
<dftxbs3e>lfam, I see well as my GNU Guile skills improve I want to help. Financially probably a bit too.
<lfam>And, there are some pending contributions on the mailing lists. Namely, a Go importer
<dftxbs3e>I though you meant support from Go communities
<dftxbs3e>thought *
<lfam>Any support!
<dftxbs3e>(go tooling modifications)
<lfam>At least, the Syncthing team has always been polite and courteous :)
<lfam>That goes a long way on its own
<dftxbs3e>lfam, I saw in Nix they use the build.go script from Syncthing upstream, any reason why we don't use that?
<lfam>We do use it
<lfam>That's how the package builds
<lfam>(There isn't another way to do it, really)
<dftxbs3e>Ah ok, sorry. I am confused how Nix fetches the dependencies, and if it packages them individually or not.
<lfam>It represents another issue with Go, which is that there isn't a good standard way to build complex applications
<lfam>But, it's really the most minor issue
<lfam>Maybe Nix uses the bundled dependencies?
<cbaines>dftxbs3e, what's the guix build --system=SOMETHING for the powerpc stuff you're working on?
<lfam>I've actually been thinking we should just do that. Several Guix packages of big Go programs already do so
<dftxbs3e>leoprikler, CVEs yes. Do we have the bandwidth to catch up on all CVEs? As a security guy I know that a lot of times CVEs are not published.
<lfam>Hm, another thing I used to do
<dftxbs3e>cbaines, powerpc64le-linux-gnu
<cbaines>One of the big differences between Nixpkgs and Guix is that Nixpkgs tries to wrap language specific build systems much more, which has it's downsides
<cbaines>dftxbs3e, great, thanks
<dftxbs3e>lfam, until we have a go importer and refresh support I think using the bundled deps might not be too bad..
<lfam>It's quite easy to adjust the Syncthing package to use the bundled deps, and it would probably also be easy to make the latest version work in that case
<dftxbs3e>lfam, I'll try then!
<cbaines>dftxbs3e, I tried to compute the derivation for hello using your branch, and got: dynamic linker name not known for this system "powerpc64le-linux-gnu"
<lfam>At least in 1.5.0, they are all free software. The Syncthing project is committed to free software so I expect that to still be true
<dissoc>i get this backtrace when trying to reconfigure: . any ideas what may be causing it?
<cbaines>is it possible to compute derivations for packages?
<dftxbs3e>cbaines, sorry, use powerpc64le-linux - powerpc64le-linux-gnu is for --target=
<lfam>dissoc: What is `guix describe`? I think that was fixed in d88ff09ea3138fc85c1463b0b345bd6ba71ca568
<lfam>dftxbs3e: There has also been a lot of discussion over the years about how to handle the huge number of "versions" that a full Go package set would require
<lfam>There's a lot of ideas and room for improvement
<lfam>With Guix being based on a Guile and having a concept of "packages", the sky is the limit. But the work must be done :)
<dftxbs3e>lfam, with improved importer/refresh support I think this can be it.. it's very elegant
<lfam>What do you mean, "this can be it"?
<dftxbs3e>but perfect importer support, like it also generates GNU Guix compliant synopsis and descriptions
<lfam>See, I think we could have prototype packages of commonly-used Go libraries that would include that stuff
<dftxbs3e>lfam, like this can be the solution
<lfam>And maybe packages that depend on it would do something like (inputs `(("go-golang-org-x-net" (go-module (,go-golang-org-x-net) (commit "foo") (hash "foo"))))))
<dftxbs3e>cbaines, is it complicated for you to add HTTPS on your monitoring page?
<lfam>We don't really want to have full package objects for the dozens of versions we'd require of libraries like that one
<lfam>We could instantiate them when required, instead
<dftxbs3e>lfam, Ah this! Yes that would be interesting!
<lfam>Dozens, even hundreds eventually
<dissoc>lfam: im on 47c8a9d (from describe). i just did a pull
<lfam>The problem is what to do when the libraries have their own dependencies :/
<dftxbs3e>For Rust too, PyPi or NPM, I guess!
<lfam>Rust is another case that will need a total overhaul, IMO
<lfam>Currently, our Rust support lacks many of the advantages of Guix
<lfam>I think that Python is okay. The concept of versioning is more traditional there
<dftxbs3e>lfam, also multiple versions of deps being required at different places
<lfam>It just doesn't fit the traditional distro model, which Guix has implemented
<dftxbs3e>Yes lots to think about..
<dftxbs3e>I think it can adapt
<lfam>But, we have the capability to meet the challenge. It will take some work, however
<dftxbs3e>I'll look at Nix more closely how they handle this if they do
<lfam>Unfortunately, I think the older distros will be left behind as a result of these languages
<dftxbs3e>I have the feeling they may be more lax on requirements
<lfam>I don't think they have the technological or social ability to serve the use cases
<lfam>Maybe it's a case where they are commoditized completely, as with "Docker on Amazon Linux"
<cbaines>dftxbs3e, just some NGinx config, I just haven't got around to it yet
<lfam>Eventually it will just be "Docker on AWS"
<lfam>Or something like that
<dftxbs3e>cbaines, okay :-)
<dftxbs3e>My HTTPS Everywhere is yelling heh
<dftxbs3e>lfam, There's a real need and demand for reproducible-everything - so there's hope I think
<lfam>Hm, I actually don't think it's demanded very widely. I think most people want flexible and reliable deployments
<lfam>Reproducibility is tucked in there, but not really the thing that people want
<lfam>It's like saying that vitamins are demanded widely, when really people just want to eat ;)
<dftxbs3e>lfam, You're probably right, but reproducibility can help go even further and be more reliable in the end
<dftxbs3e>GNU Guix feels like a pretty little garden to take care of, recreational programming that is :-)
<dftxbs3e>That's what I like about it. A real hacker-minded tool.
<dftxbs3e>lfam, it is linked to empowerment and software freedom I think
<dftxbs3e>That's what I like about them, ultimately.
<lfam>It is empowering. I could never figure out how to make my own Debian packages, or really control my Debian system in a meaningful way. Systemd made it possible to control and create services, but packages were still totally opaque
<lfam>With Guix I can do so much more
<lfam>Guix + Debian / Systemd is great
<lfam>Now I can finally add software and run it how I want
<apteryx>which package provides the GNU getopt executable?
<apteryx>I know about the one in util-linux. It seems glibc mention getopt it in its manual, but I can't see it provides it.
<dftxbs3e>lfam, yes, Debian is very horrible at that. Archaic system.
<lfam>And yet... the best one!
<dftxbs3e>lfam, I need to get better at GNU Guile so I can understand GNU Guix's core aha, the packages are easy enough but the rest..
<lfam>A clear example of the trap of "local maxima"
<terpri>apteryx, i'm not sure there's a GNU getopt executable. glibc has getopt and related functions, bash has "getopts" to use them in shell scripts, and as you mention util-linux has its own getopt program
<terpri>i don't think a getopt program is specified in posix (just getopts) but not 100% sure about that
<apteryx>terpri: ah, right. The initial version of getopt had many problems apparently and was from Unix System Laboratories (USL), according to
<apteryx>Nowadays the 'getopt' command is from util-linux.
<cbaines>dftxbs3e, I've pushed wip-lle-bout-le1 plus one extra commit to the Git repository I use for patch branches
<cbaines>and the Guix Data Service is trying to process it here
<terpri>the util-linux program is clearly for use with GNU (uses glibc getopt, respects POSIXLY_CORRECT, etc.) but happens to not be GNU-maintained i guess
<cbaines>hopefully it'll generate powerpc64le-linux derivations for packages
<dftxbs3e>cbaines, super cool, does it wait for a client with that arch now?
<dftxbs3e>I'm still working out that part
<cbaines>dftxbs3e, it's not at that stage quite yet, I need the Guix Data Service to store the derivations first
<dftxbs3e>cbaines, OK!
<dftxbs3e>cbaines, I don't see much building on x86, is that normal?
<cbaines>dftxbs3e, do you mean the agent you're running isn't doing much?
<dftxbs3e>cbaines, error: #<procedure 7f9a9f3f7940 at guix-build-coordinator/agent.scm:355:19 ()>:
<dftxbs3e> #<&compound-exception components: (#<&error> #<&origin origin: #f> #<&message message: "~A"> #<&irritants irritants: ("could not substitute /gnu/store/igycnxkipfw4mpbp6dvnmwx5p9ian9g0-ruby-timecop-0.9.1.drv\n")> #<&exception-with-kind-and-args kind: misc-error args: (#f "~A" ("could not substitute /gnu/store/igycnxkipfw4mpbp6dvnmwx5p9ian9g0-ruby-timecop-0.9.1.drv\n") #f)>)>,
<dftxbs3e> attempt 15 of 20, retrying in 16
<dftxbs3e>cbaines, yes
<cbaines>hmm, that suggests the substitutes from the Guix Data Service aren't working
<cbaines>I'd check the authorized keys
<cbaines>this is on the Guix System with it running as the service, right?
<dftxbs3e>cbaines, oh.. I didnt do the authorized_keys part
<dftxbs3e>cbaines, working now it seems
<cbaines>ok, that's good :)
<xerz>I have a shiny new 5900X/RX6800 box I think I'm going to put Guix as my main system on
<xerz>Before I proceed to install let me ask: how would I set configure/build flags for all packages?
<xerz>Basically like setting global CFLAGS in Gentoo, for things like `-march native` and such
<xerz>Thanks in advance!
<dftxbs3e>xerz, hello! I don't think it's possible the same way as Gentoo but you can use maybe use package transformations, guix build --help-transform - but I doubt it will cover that.
<xerz>Alright, let me check
<dftxbs3e>cbaines, increased parallel-builds to 16
<cbaines>dftxbs3e, cool :)
<xerz>Doesn't seem to have any transformation for build settings, and it's package-specific
<xerz>At most C toolchain
<dftxbs3e>xerz, you could modify GNU Guix's gnu-build-system,cmake-build-system etc. and add some by default but I think GNU Guix doesnt work the way Gentoo does in that matter.
<dftxbs3e>For sure a package transformation could exist for this
<dftxbs3e>I am not sure how to write it, we need some expert guilers here
<dftxbs3e>cbaines, when I add the agent on powerpc64le-linux-gnu will it just work or you have more code changes to make?
<cbaines>dftxbs3e, there aren't any builds for that system yet, but that's something I'm working on, using your branch
<dftxbs3e>cbaines, alright! well I suggest we can also start with core-updates/master to have failed logs
<dftxbs3e>but my branch is fine, I have some dirty patches there, and it would be interesting to have a world build
<cbaines>dftxbs3e, is powerpc stuff working on core-updates?
<dftxbs3e>cbaines, not really but it would get failed logs at least
<xerz>dftxbs3e hmm I easy, I'll have to think about that
<xerz>*I see
<xerz>my bad, phone keyboard
<cbaines>dftxbs3e, as powerpc64le-linux isn't in the supported-systems list on core-updates, so the Guix Data Service isn't computing package derivaitons
<dftxbs3e>cbaines, oh yes.. --with-courage I was using
<pinoaffe>xerz: (just out of curiosity): why do you want to change such CFLAGS?
<dftxbs3e>cbaines, That's one busy build machine! :-D
<dftxbs3e>pinoaffe, performance
<pinoaffe>dftxbs3e: I don't think you'll get significant increased performance tbh
<dftxbs3e>pinoaffe, you do
<dftxbs3e>little wins everywhere but sums up to big wim
<cbaines>dftxbs3e, depending on what you're building 16 parallel builds may be too many builds for 32GB of memory
<dftxbs3e>win *
<dftxbs3e>pinoaffe, Look at Clear Linux, they've pushed it to the max
<xerz><pinoaffe "xerz: (just out of curiosity): w"> pinoaffe: Curious about performance optimizations, pretty much
<xerz>Just wanted to see how much `-march native -O2` improves
<xerz>* Just wanted to see how much `-march=native -O2` improves
<dftxbs3e>cbaines, I guess, we'll see
<dftxbs3e>cbaines, unlikely that lots of big builds happen together in practice, I've run CI for whole distros before
<cbaines>dftxbs3e, the machines I'm using seem to end up building ungoogled-chromium multiple times
<dustyweb>hi hi
<dustyweb>rekado_: you still running sbcl by any chance? is your .stumpwm config up somewhere I could look at?
<dustyweb>er, stumpwm
<dustyweb>not just sbcl ;)
<dustyweb>or anyone who's running guix as distro :)
<dustyweb>actually I think I got it :)
<rekado_>I’m using Gnome these days.
<rekado_>I’m feeling the urge to get back to EXWM, but I fear starting over
<mbakke>I'm hitting all the new core-updates bugs with the TeX Live upgrade :P
<dftxbs3e>mbakke, are your machines just 24/7 100% CPU?
<dftxbs3e>sorry meant cbaines
<cbaines>dftxbs3e, I've been trying to get to that point
<mbakke>mine are just 100% CPU when I'm working on stuff...which is like 24/7 anyway.
<cbaines>dftxbs3e, I think there's still room for improvement, I want to maybe have the agent adjust the number of builds it's running based on the system load
<slimjim>hello guix! I have a question about the time-travel command and guix inferiors
<mbakke>hello fellow time traveler
<dftxbs3e>cbaines, like --load-average of GNU Make (or Gentoo's emerge)
<slimjim>I was trying to set up an a channel pinned to guix commit 603a64920f13a28a5b62cb8aedf1f460f08e15f0, which was the last commit in which the python-3.5 package was defined
<slimjim>I'm trying to test compatibility of some python code with older versions of python, and e.g. Debian 9 only has python 3.5 available
<dftxbs3e>cbaines, do you know about netdata?
<slimjim>but "git time-machine --commit=603a64920f13a28a5b62cb8aedf1f460f08e15f0 describe" does not work, not does "guix pull --commit=X"
<cbaines>dftxbs3e, I don't think I've heard of netdata
<slimjim>after some googling, I found this IRC comment from civodul in 2018:
<slimjim>which claims time travel won't work for commits before ~March 2018
<dftxbs3e>cbaines, it looks like this: - that's the monitoring for the machine ppc64le I'll run the agent on (it's already a bit busy with some other CI already)
<dftxbs3e>it's very easy to setup and gives great info out of the box
<slimjim>so I was wondering if that's actually a known or "won't fix" limitation
<dftxbs3e>on Debian it's just a single package to install and everything's monitored
<slimjim>and if it's a "won't fix", what the best course of action would be for trying to get a python-3.5 package working (would also need python-pip from 3.5)
<dftxbs3e>GNU Guix would very much profit from a netdata package, it's really simple to run
<mbakke>slimjim: unfortunately the time machine can't go back to before it was invented, at least yet ...
<cbaines>dftxbs3e, that link doesn't seem to work for me
<mbakke>slimjim: what you can do is define a new python-3.5 package, and write a procedure like 'package-with-python3.5'
<mbakke>slimjim: or even use 'guix build --with-input=python=python3.5 python-pip'
<mbakke>if you have a 'python3.5' package in some channel
<dftxbs3e>cbaines, hmm well it works from one of my servers so not sure
<dftxbs3e>cbaines, you got IPv6 networking? That's an IPv6-only link
<cbaines>dftxbs3e, ah, I haven't got IPv6... :(
<dftxbs3e>cbaines, you can run miredo to get it instantly, it's packaged in GNU Guix :-)
<slimjim>mbakke: so I tried that, duplicating the python-3.5 recipe from the old guix commit. I also had to resurrect the python-3.5 patches that that old package worked, so it looked like I had everything the same as the python-3.5 package definition as used in the old guix commit
<dftxbs3e>run it as root and it will get you a teredo 4to6 address for free from a public pool
<slimjim>but then I still couldn't get the build working bc/ a bunch of tests in the check phase were hanging indefinitely
<dftxbs3e>cbaines, no arguments required
<mbakke>slimjim: you can disable the tests if you don't care too much about the package
<mbakke>IIRC one of pythons socket tests has problems with newer kernels
<mbakke>that would also be a problem with the time machine :/
<slimjim>mbakke so I guess my question is more of a long-term strategy thing. That is, is it feasible that guix time-travel could be made to work on that commits that old
<mbakke>slimjim: it's a hard problem
<mbakke>so don't expect too much :-)
<slimjim>or do I need to manually create packages for python-3.5, 3.6, and whatever other old versions I want to test on, including other dependeinces like python-pip etc for each version
<mbakke>slimjim: for now that's the best approach, if transformation options like 'with-source' and 'with-input' does not cut it. You can submit your packages to the 'guix-past' project so they won't vanish: :-)
<slimjim>oo I didn't know about that project, thanks!
<slimjim>according to past civodul at, "the issue is that back then things were not "bootstrapped", they relied on whatever Guile and packages provided by the surrounding Guix"
<slimjim>would it be possible for me to check out a separate copy of the guix repo from that old commit, and compile it locally (outside of the guix build system), and somehow use that guix to try to build the old python-3.5 pacakge?
<mbakke>slimjim: yes, you can check out any revision of guix using git, and build packages with './pre-inst-env guix build foo'.
<mbakke>slimjim: see
<mbakke>and the preceding "building from git" section
<slimjim>ooo ok, that might be even easier. Because all the packages I want are already in that old ~2017-era guix
<slimjim>so if time-machine from newer guix can't travel back that far, maybe I can manually build the old guix
<mbakke>slimjim: should work, but you may still run into problems with the Python (and other) test suites due to your new kernel, or "time bombs" like expired test certificates
<slimjim>mbakke: one thing that might be nice is if (guix build-system python) could export package-with-explicit-python ; it's a utility function which is used to define the exported package-with-python2 function. I think if i had my own python-3.5 package definition, I could use that function to transform some of the other packages
<mbakke>slimjim: sounds reasonable, can you submit a patch? :-)
<slimjim>I'm a guile newbie, is there any way to call functions defined in a module that are not exported by it?
<mbakke>slimjim: you can access it with (@@ (guix build-system python) python-with-explicit-python)
<mbakke>eh, package-with-explicit-python
<slimjim>great, thank you! I'll have to play around with that to see if it actually does what I want it to
<slimjim>if it proves useful I can submit a patch for publicly exporting it
<mbakke>cool, good luck! :-)
<slimjim>and thanks again for the links to the guix-past project and 'running guix before it's installed;, you've given me plenty to poke around with
<mbakke>there is no shortage of ways to hack on guix :-)
<slimjim>haha yeah so I'm learning. Eventually last night I gave up and downloaded a debian 9 docker image to get access to an old python and its packages.. but I want to get it working in guix
<dftxbs3e>cbaines, I'm still figuring out a way to run GNU Guix in that VM, dep management in Debian for GNU Guix is so annoying, I'm trying GNU Guix's pack
<cbaines>Ah, yeah, I guess there's a bootstrappiing issue
<dftxbs3e>cbaines, well just deps..
<dftxbs3e>guile-git, .. etc..
<dftxbs3e>Debian doesnt have them packaged
<mbakke>dftxbs3e: i think they are in debian experimental, if "upgrading" to that is an option :)
<cbaines>I have tried to keep the dependencies of the agent quite minimal, I don't think guile-git will be used for example
<cbaines>maybe there's something I can do to make running the agent on systems without Guix easier...
<dftxbs3e>cbaines, but the agent requires guix and guix-daemon right?
<dftxbs3e>mbakke, aaaaa this is going to break everything
<cbaines>dftxbs3e, yeah, the daemon is required
<dftxbs3e>cbaines, not guix itself? how?
<cbaines>dftxbs3e, it does require Guix, but maybe the bits of the code that it requires can be used without most of the dependencies
<dftxbs3e>cbaines, I see, don't bother really
<mbakke>the Tex Live upgrade was going so well, until "texlive-latex-amscls" failed :P
<dftxbs3e>I'm waiting for GNU Guix to compile (within pack)
<dftxbs3e>cbaines, the alternative is that I run with offload from x86 so it's easier
<dftxbs3e>offload works already
<cbaines>dftxbs3e, yeah, offloading should work, I just haven't tested it
<mbakke>oh wait, it looks like LuaTeX now treats empty generated PDFs as errors, whereas with TeX Live 2019 it just keeps on going
<dftxbs3e>mbakke, wow kind of forgot your patches :-)
<dftxbs3e>running a build now
<mbakke>dftxbs3e: crossing fingers!
<dftxbs3e>mbakke, it really gets my eyes wide open how much that latex eco system has grown