<ryanprior>Is there a tool to look for unused imports in Guile files? <marusich>ryanprior, if you find out let me know :) <raghavgururajan>cbaines or nckx: Shoot! Just came back online. Are you available to right now to help me invesitage access to bayfront? <marusich>I'm trying to use GNU Global (and gtags) with the guix-daemon source in Guix. I have tried to get global to tell me about "system libraries" from the C++ dependencies provided via "guix environment guix", but I cannot figure out how to do it right. <marusich>First, in my directory, /home/marusich/guix/repos/guix-worktrees/master, I put the dependencies in a profile via: guix environment --pure guix -r .guix-profile <marusich>Then I told Global to store its tags here (I need to tell it to write somewhere other than the current directory, or it will write to the store in the next step, which fails): export GTAGSOBJDIRPREFIX="$HOME/.cache/gtags" <marusich>First, I generated the tags for the dependencies: cd .guix-profile/include/ && gtags -v -O <marusich>This creates the tags at e.g. /home/marusich/.cache/gtags/gnu/store/9jpb6shw9a9adl8x9s36gayr0v1z9fmw-profile/include/GRTAGS <marusich>Then I create tags for the nix subdirectory of the guix project: cd nix/ && gtags -v -O <marusich>This creates the tags at e.g. /home/marusich/.cache/gtags/home/marusich/guix/repos/guix-worktrees/master/nix/GTAGS <marusich>Then I go into the nix directory and attempt to find some tags. <marusich>"global -a open" tells me correctly that there is an "open" function defined in /home/marusich/guix/repos/guix-worktrees/master/nix/libutil/util.cc. That's great. <marusich>However, when I try to find info about a symbol defined in the "dependencies" (the profile), I can't get it to work. <marusich>For example, it looks like /gnu/store/9jpb6shw9a9adl8x9s36gayr0v1z9fmw-profile/include/errno.h declares "extern char *program_invocation_name". So I try to find it with "global -a program_invocation_name" (run while in the /home/marusich/guix/repos/guix-worktrees/master/nix directory). It returns nothing, and adding -v indicates that it doesn't even seem to be looking at the /home/marusich/.cache/gtags/gnu/store/9jpb6shw9a9adl8x9s36gayr0v1z9fmw- <marusich>Even if I try explicilty setting GTAGSLIBPATH via "export GTAGSLIBPATH=/home/marusich/.cache/gtags/gnu/store/9jpb6shw9a9adl8x9s36gayr0v1z9fmw-profile/include", the command "global -va program_invocation_name" still returns nothing and indicates it isn't even looking at the right database. <marusich>I'm open to changing the way I'm doing things. I just want global to tell me where the dependencies are coming from. <marusich>Hm, maybe it's working and i just asked for the wrong thing <marusich>If I try "global -va errno" from the nix directory, global does actually spit out /gnu/store/9jpb6shw9a9adl8x9s36gayr0v1z9fmw-profile/include/errno.h <marusich>However, I did have to set GTAGSLIBPATH=/gnu/store/9jpb6shw9a9adl8x9s36gayr0v1z9fmw-profile/include which I guess makes some sense. <marusich>i thought that i had to set it to the path of the gtags file, but that seems incorrect. you have to set it to the directory containing the source, from which the tags were generated. go figure. <guy>marusich: Glad you sorted it out <apteryx>I need some relay for git send-email, so I'm thinking of giving it a try ***dingenskirchen1 is now known as dingenskirchen
<apteryx>it has some Guile integration. I'm curious. <ryanprior>sneek: later tell lprndn: I'm working through your Pantheon packages and ready to start submitting some upstream. Would you like to sign off on my changes before I send patches or would you rather just comment in the issue tracker thread? <ryanprior>If I'm submitting patches that have multiple authors, is there a standard we use for how I can acknowledge that? The GitHub standard is to add a line to the commit message like "Co-authored-by: other name <other@email>" for each co-author <marusich>Glancing at the Git history, I see that we do this. <marusich>Ugh, today I learned that GNU Global doesn't play well with symlinks, which means it doesn't play well with Guix profiles. <marusich>I had trouble convincing Global to index all the things in a profile, so that I could conveniently use it to find references, even in "system" libraries (i.e., dependencies which came from outside the project, like from a profile). <marusich>In the end, the best solution I found was a really dumb one: copy all the files out of the store into a directory (which is now like 500 MB large), and just run "gtags" from the root of that directory. Problem solved. Until I need to update the profile, that is...which isn't that often, I guess. <marusich>If you do that, you can then point global at the directory you created, with GTAGSLIBPATH, and things will Just Work. <marusich>The .po files make magit super slow. How do I avoid that again? <marusich>Do you know why those .po files always seem to show up as modified?? Ludo once explained it to me, I think, but I totally forgot. <janneke>i think "po-update" best be a separate make target <janneke>when the sources change, you want the po's to be updated to send to the translation project <janneke>but that's a maintainers/release management thing, imo <bdju>ugh something wiped my icecat history and now many common sites I go to don't complete as I type... bookmarks and logins remain, about:profiles only shows one profile... <janneke>hmm, if people really care about such data, the profram could probably offer to manage it friendlier, more declarative maybe even <terpri>janneke, like sql databases and json files, where firefox already stores most of that kind of data? ;) <mroh>marusich: maybe something like this helps as a workaround: (setq magit-section-initial-visibility-alist '((stashes . hide) (untracked . hide) (unpushed . hide))) <terpri>i *think* you can also use non-mozilla sync servers for backup, not sure how easy it is to actually self-host one <janneke>terpri: i like having data i care about in git <janneke>and i see very little reason for tie-ing such data to a specific browser <FennecCode>Hey, can anyone help me figure out how to compile a 32 bit binary as a user? I want to work on a project, but it has to be compiled as 32 bit. How would I best get a 32 bit version of glibc into my profile? <terpri>FennecCode, i had a hack for doing that once (to bootstrap smlnj), i'll ping you if i can dig it up <marusich>FennecCode, not sure but perhaps the make-gcc-toolchain is a good place to start? Maybe somebody here knows more. <marusich>(that's a procedure we use to define the toolchains for installation into user profiles, but I am not sure how to specify 64 bits vs 32 bits) <FennecCode>What I tried just now is "guix build --system=i686 glibc", and then installed into my profile based on the path of the package in the store. It seemed to work. <terpri>janneke, i wonder if one could use git smudge filters to archive on-disk firefox profiles in a sensible way <janneke>it would be great if we had one guix curse to setup cross development environments <terpri>probably not great to just keep rapidly-changing binary sqlite dbs in git <terpri>it has a more negative connotation than "spell" <marusich>janneke, so that creates a cross-compilation toolchain for an i686-linux-gnu target, right? <janneke>marusich: that's the idea...i see that it has search variable overrides that are hopefully no longer necessary <marusich>How is it that the cross-compilation toolchain gets used when building i686-linux-gnu-hello, though? It's still using the gnu-build-system, right? <janneke>oh, i'm not using/building "hello" here at all, it's just a placeholder <terpri>(i'd say 'spell' is neutral, 'curse' is a bad spell, 'charm' is a good spell, and of course there are many near-synonyms) <FennecCode>I don't fully understand the context right now, but what about "incantation"? <janneke>yeah, so we could have a "curse" for the mingw cross build, a "charm" for the hurd cross build :-) <terpri>FennecCode, incantation seems neutral to me, though i think it would imply a verbal spell (vs scrawling symbols on the ground or whatever), being derived from latin "incantare" <terpri>(probably related to "chant", for example") *terpri <- classicist and esperantist, nearly useless with living, nonconstructed languages :) <terpri>FennecCode, are you trying to make a guix package that will be compiled with the 32-bit toolchain? or are you going to just manually compile something <FennecCode>I'm just trying to manually compile something for now. I'm not familiar enough with the way that Guix packages work yet. <marusich>I feel like somebody could craft a package using make-gcc-toolchain (or something like it) which would enable the easy installation of any kind of "gcc toolchain" (e.g., a cross-compiler targeting i686-linux-gnu) for installation in their profile. <marusich>I'm just not sure exactly what the right combination of things would be. <terpri>FennecCode, ok, then you won't need my hack (which is specifically for packaging). you might want to use guix environment or similar to keep your main profile clean <FennecCode>terpri: I would, but my profile is already a mess for now 😅 <marusich>FennecCode, if you want to play around with it, perhaps you can naively try defining packages like the examples janneke provided, and then pass them to the make-gcc-toolchain procedure to see if it produces a usable cross-compilation toolchain targeting i686-linux-gnu. <FennecCode>It turns out that I don't actually need 32 bit for this even. 😅 I was just kinda confused on how to build this particular thing <FennecCode>The error I'm running into at the moment is that some stuff related to clocks is undefiend in librt. <FennecCode>ld: /gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/lib/librt.so.1: undefined reference to `__clock_nanosleep@GLIBC_PRIVATE' <FennecCode>Maybe I should try making a package out of this? My questions on here honetly aren't all that interesting 😅 <FennecCode>Like, I'm trying to compile a Mario 64 source port, for reference <ArneBab>When starting an environment with a container (-C), how can I add groups to the user? I’d like to add audio and video <FennecCode>Ok, it was me being dumb. I didn't have gcc-toolchain installed 😅 <dftxbs3e>marusich, hey! to report on the situation: I can't get cuirass to work and actually run builds, otherwise it runs. VM or Docker still isnt possible, but I figured I'll run cuirass without a service on the command line <cbaines>ArneBab, I'm not sure there's that level of control yet, that might require changing the guix environment code <rekado_>I’m trying to import a Guix VM image in AWS EC2. <rekado_>EC2 doesn’t like the vmdk format produced by qemu-img, so I converted it to raw <rekado_>now it complains: EFI partition detected. UEFI booting is not supported in EC2 <rekado_>but my example VM doesn’t seem to have an EFI partition <marusich>rekado the only way i was able to successfully "import" a guix image was to copy the drive image onto an EBS volume and then manually make it the root volume of an existing instance. <mothacehe>rekado_: Are you sure it doesn't have an EFI partition? In "qemu-image" we always create an EFI partition, regardless of the bootloader. <marusich>dftxbs3e, that's great! in a way. I haven't made much progress on the non-determinism investigation, I'm afraid... <mothacehe>rekado_: the new image API should allow you to create a non-EFI image quite easily. <rekado_>mothacehe: I’m out of the loop. Is this the recent changes to build the image without qemu? <cbaines>rekado_, I had some success using packer to generate Guix AMIs for AWS. That's a automated way of spinning up an EC2 instance, adding a EBS volume, doing guix system init to the volume, and then converting that volume to a AMI <mothacehe>rekado_: Yes it's related, let me see if I can provide you a patch to do that. <rekado_>cbaines: ideally, I’d just use “guix system” and then two API requests with guile-aws <dftxbs3e>marusich, as you can see it doesnt run any builds <marusich>Were you able to chat with cbaines about it? I feel like he has experience with Cuirass, but maybe I'm way off base <marusich>I am not sure how to tell it to do stuff, but based on the emails I've seen people exchange, it requires some tender love and care <marusich>i.e. i don't think it just starts building things unless you do everything just so <cbaines>I never really managed to do much with Cuirass, but I can try and help <cbaines>How far have you got, have you got builds in the database or not yet? <dftxbs3e>cbaines, hey, I can give you access to the VM directly if you want - I set up a specification and tried running in one-shot mode and it doesnt run any builds, it creates an evaluation but runs no builds inside it <cbaines>do you know if there are any builds associated with the evaluation? <cbaines>dftxbs3e, if the evaluation succeeded, hopefully you'd have some builds in the database <mothacehe>rekado_: if you apply this ttps://paste.debian.net/1150368/ and run guix system disk-image config.scm, you should get a raw disk-image without EFI partition. <marusich>dftxbs3e, did cuirass complain about the specfile at all? not sure how it's loading stuff, but i wonder how hydra-jobs is in scope <marusich>I'm looking at /root/cuirass-data/specfile.scm <marusich>I see you launched it via /gnu/store/4sny945i7dbr4ws2k45fs89m617xsbmj-guile-3.0.2/bin/guile --no-auto-compile -e main -s /gnu/store/z09azp31ypwmq6m8fwkmn656p42w33jc-cuirass-0.0.1-30.9559fd1/bin/.cuirass-real -D cuirass.sqlite --web -p 80 --listen=localhost -I 5 -S specfile.scm --cache-directory=cache <marusich>Did you see the cuirass-howto.org in the Guix maintenance rpo? <marusich>Although, it seems short and I'm not sure if it's up to date... <marusich>I think the actual cuirass-jobs.scm used by the cuirass instance in our build farm is defined there <marusich>See: git.savannah.gnu.org:/srv/git/guix/maintenance.git <marusich>e.g., marusich@git.savannah.gnu.org:/srv/git/guix/maintenance.git in my case <marusich>see also hydra/modules/sysadmin/services.scm <marusich>There is some stuff about cuirass in there which could be useful. <user123>How do I go back, after following a link in the info viewer, which was invoked by "info guix"? <marusich>To go back to the previous node in the Info reader, press "l" (lower case L). <user123>I mean back to the the page, from which I came <marusich>I'm not sure how to go forward, but there is a way. I can never remember. <marusich>For more info about info, see "info info". <user123>yeah, I tried readin it, but it's too much. <user123>I just want to learn guix, not info. <marusich>FWIW, I only really use these things in info: "i" for index entries, "l" for back, spacebar to go forward, "backspace" to go back, ] and [ to go forward/back by nodes (depth first), n and p to go forward/back by nodes (staying at the same level, which skips subsections), "t" to take me back to the top, "tab" for cycling through links (hit "enter" to access them), and "m" for typing names of links/submenus. <marusich>Oh, also the full text search is useful. control+s, or just / <sneek>lprndn, ryanprior says: I'm working through your Pantheon packages and ready to start submitting some upstream. Would you like to sign off on my changes before I send patches or would you rather just comment in the issue tracker thread? <marusich>The "i" index feature is the killer feature of Info if you ask me. Well written manuals in texinfo are super nice to read as references becuase of this. For example, type "info bash" and then "i" and then "@" followed by enter. Takes you right to the explanation for the $@ parameter. <user123>marusich: I think adding the few commands you've just mentioned to the top of "info info" would be great for new users. <user123>you can just press capital h, but I didn't know that before. <marusich>I was just gonna say that! I did not know until I searched for it :) ***calher is now known as KE0VVT
<zimoun`>user123, marusich: if you use Emacs as Info reader, if I may, I recommand info+.el which adds some colour and other features which improve the experience. <user123>zimoun`:It's neither in elpa or in melpa. RIP <user123>How would installing it via guix work? How would emacs load it, if it's not in init.el? <zimoun`>user123, but it is in Guix. ;-) guix show emacs-info-plus <user123>or should I install it and then load it? <marusich>user123, emacs-info-plus, and basically all the Emacs packages in Guix, use the emacs-build-system. This is an abstraction that one can use in a Guix package to automatically set up various autoloads (if I understand correctly). The effect is, you only need to install the package with e.g. "guix package -i emacs-info-plus" and then maybe add something to your ~/.emacs file to use it. <marusich>For example, I have emacs-helm-gtags installed, and I use a form like (require 'helm-gtags) in my ~/.emacs file to use it <marusich>The benefit of packaging these in Guix is that the management of these Emacs packages now becomes like any other Guix package, and they gain all the benefits that come with that. <marusich>A downside is that it is different from what a lot of Emacs users are used to, e.g. by using elpa or whatever. But we think the benefits outweigh the downsides. <user123>(require 'info+) seems to have worked. <marusich>Generally, this holds for most packages. For example, Python packages are the same way. You could use pip, for example, but you don't have to if it's packaged in Guix. <rekado_>mothacehe: thanks for the patch. I’ll try it. <sneek>Welcome back civodul, you have 1 message! <sneek>civodul, wingo says: it is a good idea :) <rekado_>“…we encourage you to not install too many packages into your base environment, and keep track of versions of packages some other way (e.g. comments inside files, or printing numpy.__version__ after importing it in notebooks).” <civodul>rekado_: NumPy and the NumFocus foundation, Jupyter, etc. are very much into CONDA + Binder <rekado_>civodul: that’s from #guile, about source slot in syntax objects <terpri>good news from #lispm and ams: cadr (mit lispm) emulation is being actively hacked on and is proceeding apace to get the last published versions working <marusich>civodul, I submitted my first one-line guix-daemon patch! I feel so proud. <user123>rekado_: Isn't software meant to lift that burden of manually managing versions and packages? <user123>sounds like python is build on supreme software engineering <zimoun`>marusich: yeah really cool! How can I test it? <terpri>and it's all free software (MIT i think) so could go into guix, unlike my vlm/opengenera efforts <marusich>I tested it by building it manually in the Docker container. <marusich>It took me like an hour to figure out that "guix pull" does NOT build the most recent guix-daemon. That was surprising. <marusich>It uses the guix-daemon package, which uses a slightly older version of Guix to build the guix-daemon. <terpri>(well, i guess my free CL ivory emulator could go into guix, but it's kind of useless unless opengenera is freed somehow...) <marusich>This is usually fine, since we update it from time to time, and eventually updates roll out to the masses. <marusich>But I wanted to test MY change, and it was kind of hard to do that when guix-daemon was pinned to an old version :/ <marusich>The solution was to just use ./pre-inst-env from a local checkout instead of "guix pull" <terpri> https://tumbleweed.nu/lm-3/ has some more if anyone wants to see what's in the works, there appears to have been a lot of progress since MIT freed the cadr source code years ago <zimoun`>marusich: do you used ./pre-inst-env inside the running Docker container? <rekado_>OT: I’m so happy that the manufacturer of my signal generator (built 1981) sent me the old manual with schematics, block diagrams, and component placement diagrams. This is how it should be for all electronics. <zimoun`>marusich: ok. Thanks for the explanations. I will give a try. :-) <marusich>So, I used one of Stephen's images, in which there were dead items that could not be GC'd. If you launch it with something like "sudo docker run --mount type=bind,source=$HOME/guix/repos/guix,target=/guix-dev --privileged $the-image" you can get your checkout in the Docker container. I ran "herd stop guix-daemon". I built the image in the Docker container. Then I ran ./pre-inst-env guix-daemon, basically. <marusich>But you could probably build it outside the docker container too. <mothacehe>Enabling CONFIG_MODULE_COMPRESS cuts down linux-libre size by 63%, that's good news to reduce system closure size! <terpri>also til ams helped design and write dmd back in the day...better known today as shepherd :) <mothacehe>I guess it's because I'm on a fs with user_xattr support <bricewge>Trying to fix the non reproducibility of the iPXE patchset, I have found 3 file with non epoch timestamps <bricewge>They are generated from a shell script using cat and cp <lprndn>sneek: later tell ryanprior: Thanks, I'm glad you had time to look at the packages. How bad was it? :) I think commenting in the tracker thread will be enough ;) <bricewge>How should I go about setting their timestamps? <janneke>mothacehe: hmm yes, i guess so...how did you manage that? <janneke>mothacehe: right, so...hmm. it's less than great to have a test depend on a feature that's not under our control; it's also not great to not test it at all... <janneke>yes, that at least tests that the interface is OK <janneke>the downside is that trying to set (namespace mistake!) "usr.translator" will also throw -ENOTSUP, iirc <user123>How would you inspect the value of a symbol like PACKAGES? (I'm not sure if symbols are all caps in Scheme. In Common Lisp they are.) <janneke>mothacehe: about wip-hurd-vm; i intended to send the patch series to you and civodul too, but only mailed the bug; does that work for you or do you need me to do something else? <mothacehe>no your serie is great, plan to have a look this week-end :) <mothacehe>but I think that all my concerns are adressed <janneke>mothacehe: looks good (given that we cannot otherwise query the file system for availability of the feature first :-) <civodul>janneke: thank you, i'll take a look! <dftxbs3e>cbaines, hey well as I said there's evaluations but no builds! I am using the hello-git.scm example <dftxbs3e>sneek later tell marusich I tried reading code in the maintenance repo and looking at the how to-s and it's been very unclear to me <cbaines>dftxbs3e, sounds like something is going wrong at the evaluation point then <dftxbs3e>cbaines, it clones the repos but it throws no errors or warnings at all <cbaines>dftxbs3e, yeah, I wouldn't be confident that it fails well <dftxbs3e>cbaines, it clones the repo and creates the evaluation when I run with --one-shot, otherwise it creates the spec but does nothing with it <cbaines>That doesn't just mean "do the web stuff", it also means "do nothing else" <cbaines>I think the intention when using --web is that you run another process that doesn't run with --web ***MSavoritias_ is now known as MSavoritias
<dftxbs3e>I couldnt find documentation about that, well I'll run it twice .. ? <rndd>hi everyone! is there a way to define user's packages in config.scm? <dftxbs3e>cbaines, it works now it seems... what a dumb thing <rekado_>mothacehe: that didn’t seem to help. I get “ClientError: EFI partition detected. UEFI booting is not supported in EC2.” <rekado_>I’ve built the image with ./pre-inst-env guix system vm-image doc/os-config-bare-bones.texi <rekado_>rndd: you just define them right there in that file. <cbaines>rekado_, rndd I'm not sure there's a way to control user profiles from the system level configuration <cbaines>You can however specify which packages will be installed in the system profile <rndd>rekado_: yout mean, %base-packages <rndd>i know about it but i asked about something like %myuser-packages <mothacehe>rekado_: vm-image still uses the old image API (forcing an ESP partition) <bdju>rndd: have you considered using a manifest file? <bdju>it would not be in config.scm, but it's a way to declare packages for your user <rndd>bdju: i use them sometimes <mothacehe>except that the image will be raw and not qcow2, I don't think there will be other differences <rndd>bdju: as i undestand, manifest files creates custom profiles. can they install packages directly to my profile? <rekado_>mothacehe: oh, thanks for the clarification <rekado_>rndd: no, you asked “is there a way to define user's packages in config.scm” — and that’s indeed possible <rekado_>but it seems that what you meant to ask was whether the operating-system record has support for installing packages into a user’s profile <rekado_>I wonder why they start with busybox, though <rekado_>couldn’t they just use a Guix-generated root file system directly? <rndd>rekado_: sorry i asked wrong question <rndd>well, my goal is to write packages i need for my user to be able to recreate my working environment when i reinstall os, or change pc. is (specifications->manifest... only way to solve it? <rekado_>specifications->manifest takes a list of package names (and optional versions) in the form of a package specification as you’d use it on the command line <rekado_>and it generates a manifest that “guix package -m” understands <rndd>so... i see it as a valid way to recreate env <rekado_>it shouldn’t be too hard to write a service that conditionally instantiates a manifest for a user <rekado_>no, but it doesn’t sound too difficult to write a service like that. I don’t know of anyone who has done this. <guixy>After a recent update, ungoogled-chromium causes gnome to crash. <guixy>That is the case for my own channel at least. <guixy>Is anyone having the same issue on the default channel? <rekado_>is this with Guix System or on a foreign distro? <guixy>I decided to roll back my channel to the last change I made. <guixy>Previous changes were synchronizing with the default channel. <user123>after a recent update tmux stopped working and started to complain about invalid: LC_ALL, LC_TYPE or LANG. <zimoun`>Dear, the commmand "guix system docker-image gnu/system/examples/docker-image.tmpl" returns an error. The log seems saying it is because qemu-system-x86_64. I am running on the top of Debian. Do I have to setup something special? <rekado_>user123: make sure that 1) glibc-locales or glibc-utf8-locales is installed, 2) GUIX_LOCPATH is set, 3) the glibc linked with tmux is the same version as the locales provided by your glibc-locales package. <travankor>although I've never used gnome in case gnome is weird <guixy>The other non-tiling DEs were broken last I tried them. <rekado_>guixy: what do you mean by “broken”? <guixy>xfce wouldn't let me shutdown or logout. I did report this bug. ***rekado_ is now known as rekado
<guixy>I haven't tried enlightenment in a long time. <guixy>i3 and ratpoison have a learning curve I'm not patient enough to accept <guixy>The reason I need chromium is because the university I attend requires nonfree video conferencing software. ungoogled-chromium is the closest thing guix provides. <janneke> /gnu/store/6wn346cbw1mh6264v426pwj2klgvxr0z-gcc-5.5.0/include/c++/cstdlib:118:11: <janneke> error: ‘::div_t’ has not been declared <bdju>has anyone looked at the emacs-general build failure yet? <janneke>oh wait, i need to use (native-inputs ... ,@(fold alist-delete (%final-inputs) '("gcc" "gcc-lib"))) and (arguments `(#:implicit-inputs? #f ...) <user123>rekado_: I believe the problem was due to me installing "glibc-locales", I haven't manually installed them prior. Currently I've installed "glibc-locales" and "glibc-utf8-locales". I also get the message "guile: warning failed to install locale" I'm wondering how I could make sure that the locales provided by glibc-locales are the same version as the glibc linked with tmux. <janneke>...or just keep my local copy and let others rediscover the recipe if the need arises? <rekado>hah, next error: “Unable to find an etc directory with fstab” :) <janneke>rekado lost their etc directory, how embarassing <janneke>=> \o/ /gnu/store/nwfrhxl3gj61wch8a0af08bhxsqgdcrk-boost-gcc-5-1.72.0 <guixy>I figured out my problem. .config/chromium/Default/Current\ Session was corrupted. I'll see if there's a way to anonymize it so the Chromium devs can take a look at it. <janneke>ah, /me forgot about --disable-deduplication for the Hurd <rekado>I signed up for this Reddit thing to comment on all the misinformation and guide people to the proper help channels <rekado>annoyingly they rate limit comments; I can only comment once every 10 minutes. <mfg>Hi there, i was trying to cross build NetBSD from Guix and it seems that the supplied configure scripts don't detect gcc properly. those scripts are generated with autoconf 2.52. Are there any changes to more recent versions of autoconf which could fix this or do i have to search somewhere else? <davidl>what happens if you remove the /gnu/store/.links directory? What purpose does it serve? <apteryx>davidl: I think you'll loose deduplication of the store <rekado>davidl: if you don’t like the directory you better disable deduplication via the guix-daemon option <rekado>the .links directory contains all unique files <rekado>so when a package contains the same files as another package you won’t use twice the space <davidl>rekado, apteryx: ok, the reason Im asking is that I receive a statting error when running guix gc, so I am removing those files mentioned in the error individually - but I have so many files, that even when I remove them individually it is taking hours... http://logs.guix.gnu.org/guix/2020-02-21.log#133446 <davidl>'s/remove them individually/remove them automatically based on error output from guix gc/g' <rekado>davidl: you should not delete anything in /gnu/store <travankor>mfg: i can't help. but am interested in your work <rekado>by deleting stuff there manually you’re voiding your warranty and all bets are off <davidl>rekado: I was told that those specifically are safe to delete... <davidl>rekado: is that wrong even in this specific case? <rekado>never delete *anything* in /gnu/store; it’s a bad idea <rekado>nckx wrote “(In fact it should always be safe to delete files in /gnu/store/.links but don't do that 😛)” <rekado>if your file system is corrupted try running fsck instead. *janneke would consider buying some of that guix warranty thingy <bricewge>When I get "may not be deterministic" from “guix build --check”, how can I compare them with diffoscope? <bricewge>Nevermid, my console was too narrow, there is a /gnu/store/...-check <sturm1>Hi folks, I'm trying to run a `pip install` in `guix environment --container`, but am getting "Download error on https://pypi.org/simple/pytest-runner/: [SSL: CERTIFICATE_VERIFY_FAILED]". Any ideas? I already have nss-certs in the environment. <sturm1>gah sorry, ignore the above - think it was just an intermittent network issue :P <apteryx>bricewge: guix build something --keep-failed <apteryx>then, diffoscope -x stat /gnu/store/result{,-check}, IIRC <bricewge>apteryx: Thanks, there is less to scroll with that flag :) <apteryx>yeah! I think it's due to hard links in the store <mbakke>janneke: why do you need a boost-gcc5? <janneke>mbakke: to build an ancient c++ code base <mbakke>janneke: there are a few workarounds in Guix due to conflicting headers on CPLUS_INCLUDE_PATH when using a different version of GCC <sneek>guix-vits?, pretty sure was seen in #guix 0 seconds ago, saying: sneek: seen guix-vits? (:P). <mbakke>janneke: grep for 'augment-CPLUS_INCLUDE_PATH' for other examples :( <mbakke>not sure how we can deal with that in a generic way <janneke>mbakke: thanks! ... i managed to build boost-1.72 using gcc-5 in the end (did you catch that?) <janneke>mbakke: so i was wondering if there's a better solution, and whether or not i would add it to guix <mbakke>janneke: oh, neat workaround :-) <mbakke>probably should be a 'hidden-package' though, otherwise you'll have to update the description to explain why users should use it or not ;-) <janneke>okay...i was just wondering...i won't submit a user/client for this, so...yeah <mbakke>right, if there is no user, it's probably not worth adding it to guix proper <janneke>mbakke: yeah..., it's a weird situation; the recipe in worthwhile to not "forget" <davidl>rekado: so say that /gnu/store/.links directory is ruined now.. Im on a foreign distro - could I add --disable-deduplication to the systemd unit file, and run a regular guix package -u for all my users, including root - and then remove everything in /gnu/store/.links, and then finally restart the daemon without the --disable-deduplication flag and Im back on scratch? <davidl>(..to the systemd unit file and restart the daemon*) <mbakke>janneke: maybe you can change some of the other workarounds in a similar fashion instead :-) ***familia_ is now known as familia
<rekado>I wonder how many more checks there are with EC2 <rekado>all of that /etc stuff is created upon booting <rekado>it seems weird to require this to exist before booting <rekado>maybe we’ll have to run the system activation and use the resulting image state <mfg>is it possible in guix to search for a file and get the package which contains it? i'm in particular searching for linux/limits.h <rekado>I really don’t like all those shell scripts and foreign converters that the Nix people seem to be fond of. <rekado>mfg: no, there is no such service yet. <rekado>the Guix Data Service could likely offer something like that in the future <apteryx>mfg: you can probably search your store /gnu/store to find which package it came from <mfg>yeah that's what i have to try then, but i don't know for sure if it's even installed :D - i hope it is <janneke>well, you can do: ls -l /gnu/store/*/include/linux/limits.h <nckx>mfg: linux-libre-headers, here. <Kozo>mbakke: Hey, are you around? <Kozo>I have another machine with a working guix. Doing the pull there and will generate the disk-image <user123>zimoun`: check out the section 8.8.1 while having info+.el loaded. <user123>zimoun`: the highlighting seems to be broken. <zimoun`>user123: yeah, that happens sometimes. The comment in info+.el says: "Be aware that such highlighting is not 100% foolproof." :-) <zimoun`>M-x Info-toggle-fontify-quotations to turn OFF locally when it happens. *user123 writes that on to his piece of paper full of notes, after reading the whole Info manual. <civodul>week-end! let's switch to cool-hack mode <civodul>bricewge: thanks for the backtrace! could you try again, but set COLUMNS=200 before running guile? <mbakke>zimoun`: that means it either has not been updated since the fix, or it's generated in an environment where grafts are disabled *mbakke switches to M-x merge-staging-mode <zimoun`>mbakke: it seems to be 1f9999d now for the devel manual <janneke>yay, civodul in "cool hacking" mode ;) <zimoun`>civodul: I cannot reproduce neither. *janneke rediscovered that the hurd needs --disable-deduplication (prolly to work around a bug) <mbakke>zimoun`: perhaps the 'guix' snapshot on berlin does not have the fix? /me checks <mbakke>zimoun`: indeed, /run/current-system/profile/bin/guix --version is 1.1.0-4.bdc801e on berlin <mbakke>it will be fixed on the next reconfigure <zimoun`>mbakke: Ok. Thanks for checking and explanations. <mbakke>janneke: I'm not sure if civodul has other modes :-) <civodul>i'm tempted to go in cycling mode because my head is full and $PARTNER already entered cooking-mode :-) <janneke>cycling is a great way to come up with cool new hacks <mbakke>probably a good idea, hacking with full head rarely works well <mbakke>there is a nice Nietzsche quote "all great thoughts are conceived while walking" -- I think it applies to cycling too :P <mbakke>anyone know what's causing a 'org.freedesktop.DBus.Error.MatchRuleNotFound' in a build container? <mbakke>i.e. what magic D-Bus incantation is required to make the service visible <leoprikler>from what I could quickly gather, it appears to be a malformed org.freedesktop.DBus.RemoveMatch request <leoprikler>which would be weird since AddMatch and RemoveMatch are probably paired <mbakke>leoprikler: interesting, there are plenty of AddMatches before that error, and it occurs shortly after a RemoveMatch <mbakke>leoprikler: it could be just a red herring though, trawling through strace output :/ <leoprikler>what are the arguments passed to the AddMatches and RemoveMatch(es)? *mothacehe reduced the closure size of bare-bones system to 943MiB (32% less than on master). <mothacehe>various patches, but the main source of improvement is enabling module compression in Linux (CONFIG_MODULE_COMPRESS). <mbakke>leoprikler: yes, looks like the arguments are sane... I think the reason for the MatchRuleNotFound is because the process dies in the mean time <roptat>mothacehe, so it could apply to any system, great! <roptat>are you sure modules don't retain references to store paths that would be hidden by compressing them? <nckx>mothacehe: initrd size matters more than the system IMO. How is that affected? <mothacehe>roptat: no, still have to run further tests. <nckx>That (and maybe references, although modules themselves are self-contained) is the reason for not compressing them. <mothacehe>nckx: initrd is gzipped, so no difference (13.4MiB). <bricewge>civodul: I updated the bug report by an output with larger columns <nckx>mothacehe: Unexpected but good. <mothacehe>nckx: besides Linux the other big space consumer is ... Guix, with 280MiB without dependencies. <mothacehe>I wonder if we could compress all those heavy .go :p <mbakke>apparently someone wrote their thesis on the KDE Akonadi test suite, perhaps I have to read that to understand what's going on :P *nckx fondly remembers gzexe'ing their entire system to free up more space on their 250MB hard drive. <nckx>It didn't boot, but boy was it small. <apteryx>mothacehe: I remember reading something an optimization possibility to reduce .go file sizes; it wasn't done because the space inneficiency could be well compressed. *guix-vits mumbles "services should work..." repeatedly -> reboot <mothacehe>apteryx: oh interesting, I'll start a discussion on the ML then. <apteryx>so compressing those would probably lead to nice gains, else we could try to optimize the binaries produced. <mothacehe>Guile is also heavy (50MiB) and we have it two times (static & dynamic version). <roptat>if we're going to use the baseline compiler, we won't really optimize these modules <nckx>mothacehe: I assume you did choose XZ, right? *nckx y no zstd support :( <mothacehe>nckx: no, kept the default which gzip, but I'm going to try with XZ now :) <cbaines>raghavgururajan, hey, have you got some time this evening to debug bayfront SSH things? <bougyman>Can't find out what guix stands for at guix.gnu.org or wikipedia or ... <bougyman>Any article or thread about the name itself somewhere i'm missing? <nckx>mothacehe: ‘("CONFIG_MODULE_COMPRESS" . m)’ <nckx>Are you sure that's not a no-op? <cbaines>bougyman, from memory, I think it's something like Guile + Nix = Guix <cbaines>raghavgururajan, great, so I take it that you still can't connect via SSH? <raghavgururajan>raghavgururajan@bayfront.guix.gnu.org: Permission denied (publickey). <cbaines>raghavgururajan, OK, can you send me the public part of the key that you think should be authorized? <nckx>raghavgururajan: cat ~/.ssh/id_ed25519.pub, but it should match what I added. <cbaines>raghavgururajan, that matches what should be authorized. Can you try connecting again, I'll see what's in the logs <nckx>raghavgururajan: Could you also try explicitly specifying that specific key: ssh -i ~/.ssh/id_ed25519 raghav…@… <cbaines>Hmm, there isn't much to go on in the server logs *raghavgururajan will be back in 5min <terpri>nckx, what's missing zstd support? (haven't read backlog) <nckx>terpri: Well, in general I hope Guix will one day switch to zstd for everything 😉 but I was talking about CONFIG_MODULE_COMPRESS here. <nckx>I'm weary that gzip/XZ will increase boot time noticeably but we'll see. <apteryx>nckx: you can already achieve this with btrfs + zstd, no? <nckx>Where I still use btrfs. <terpri>ah right, looks like linux doesn't support zstd support yet, although i think someone posted a patchset for it <nckx>apteryx: I was just talking in the context of mothacehe's experiments, not whether they're worth it or not. I do think file system compression is the way of the future. That does mean that GRUB is doing the decompression instead of Linux, and we know (from LUKS) how spectacular the speed difference can be. <nckx>terpri: It does, but 5.7 hasn't made it to Guix yet. <nckx>Or I'm thinking about kernel compression. Anyway, zstd-everything will land soon enough, I'm sure. <terpri>hm...linux master doesn't have a HAVE_KERNEL_ZSTD option like other compression algos <nckx>It obsoletes gzip on x86 at least. <nckx>Much higher speed, same compression ratio. <janneke>and implementation-wise, is it just as simple? *nckx opts out of arguing for the sake of argument. <cbaines>raghavgururajan, do you mean the bit that mentioned: Permissions 0644 for '/home/rg/.ssh/rg.pub' are too open. <terpri>anyone know what's up with grub's luks slowness, btw? i know they can't just use linux code (gplv2), but surely there are fast and free crypto libraries out there to borrow from... <nckx>raghavgururajan: chmod 600 ~/.ssh/id_rsa.pub <nckx>raghavgururajan: chmod 600 ~/.ssh/id_ed25519 <nckx>That's what I get for hurrying. <terpri>i suppose i can just see for myself <cbaines>raghavgururajan, some logs from your end may help, could you run ssh with -vvv and send me the output? Maybe don't share it in the channel, I'm not sure how sensitive the output is <mfg>does gcc have default search directories on guix? or is it empty, because they usually don't exist? (/{include, lib}, /usr/{include, lib}) <nckx>terpri: I've wondered the same myself. Does it run in real mode? Would that make a difference? I dunno. <nckx>raghavgururajan: Did you get any further in private? cbaines: Have you tried just dropping the key into /home/raghavgururajan/.ssh/authorized_keys? <nckx>Using that work-around or the Guix Way? <nckx>Where does this ‘rg’ come from? That's not standard. <raghavgururajan>nckx: When I created the key, the mentioned rg as preferred filename for pubkey. But it seems it also used it for private key. <raghavgururajan>nckx and/or cbaines: Is there a way to register my private+public keys in ssh-agent, so that I do not have to pass `-i` argument each time? <nckx>You should just use the defaults if you've never used the software before. ssh won't use your custom name by default… But glad you got it working. <cbaines>raghavgururajan, adding an entry to ~/.ssh/config for bayfront with the right values for IdentityFile and User should make things easier going forward <nckx>raghavgururajan: mv ~/.ssh/{rg,id_ed25519}; mv ~/.ssh/{rg,id_ed25519}.pub <mfg>how do i get the store path for a package? is it possible with the cmd interface? <cbaines>mfg, guix build foo (where foo is the package) <nckx>raghavgururajan: Instead of fighting the defaults, *use* them. <nckx>raghavgururajan: When you get to the point where you're juggling multiple same-algo SSH keys (=not now), you'll probably be more familiar with SSH anyway 🙂 <nckx>cbaines: Would it be acceptable to add myself to bayfront as well? Then I can help Raghav with this stuff myself instead of chewing gum on the sidelines. <cbaines>hmm, that could be me not fudging the user stuff correctly, is there any indication of what directory it's trying to make? <cbaines>nckx, I'm fine with that, if you push the relevant changes to maintainance.git, I can reconfigure <cbaines>raghavgururajan, I think ~/.config lacked the write permission for some reason <cbaines>I've fixed that, can you try running guix pull again? <guix-vits>nckx: have "solved" the tor-service trouble i has by deleting /var/lib/tor and `reconfigure`. Now it's working. <nckx>Glad to hear it, although we'll never know what happened. <nckx>guix-vits: Are you running a relay or just a client proxy? <nckx>If the former, remember that your keys have changed. <guix-vits>nckx: just a client, to proxy my https traffic similar to how it shown in Arch Wiki. <guix-vits>i didn't saved what was deleted, but seems (in comparison with what i've now) that some files in /var/lib/tor were owned by "scanner" (whoever that is). This is the only difference i'd notices. <pkill9>does anyone get a hash mismatch when trying to build boost-signals2? <nckx>That's a pretty big difference (they should all be tor:tor). Sounds like your GIDs got shaken up. It happens. <davidl>How do I write #:use-module in modules that are in channel A when the module to be specified is in channel C? Explanation: I have a module in a guix channel - say channel A, which is dependent on channel B, which in turn is dependent on channel C. The module in A uses simply #:use-module C-module (where C-module is a module defined in the 3rd channel C), and I receive the following error when pulling <davidl>channel A: (exceptions misc-error (value #f) (value "no code for module ~S") (value ((C-module))) (value #f)). <nckx>pkill9: I don't think it ever built successfully/was correct, so I'm inclined to just change it. <guix-vits>davidl: IDK, but did you'd tried to use (add-to-load-path "/some/dir")? <davidl>What would I write in the A-module if I need to use (add-to-load-path "/path/to/C-module"? <nckx>rekado: Did you ever use 71154fe737b135cf9d53e9af8c410920e42523ac successfully? ☝ <guix-vits>davidl: idk, but maybe it will be a '(add-to-load-path "/path/...")' before (define-module? <nckx>rekado: Disregard, looks like an oversight when updating boost on core-updates. <nckx>raghavgururajan: While a scheduled ‘guix gc’ is running, nothing else can run. <guix-vits>(big-garbage-collector-lock "open sesame, <cut>") <terpri>nckx, i wouldn't even know where to start tbh. run grub under qemu/etc. and step through it with...something? <terpri>looks like grub may contain a fair bit of custom crypto code, which isn't ideal <terpri>(don't quote me on that as i'm not a grub expert, but for example there's grub_crypto_cbc_encrypt which ends up calling a "method" of a grub_crypto_cipher_handle_t argument, things like that) <terpri>oh, remember when i was talking about that hack for building 32-bit binaries on 64-bit installations? here's the key snippet: <terpri>(depends on (guix build-system) and probably other modules) <terpri>no idea if it's the right way to do things, but it got smlnj working (before it had usable amd64 support) <nckx>terpri: I think the magic word is ‘grub-emu’ (implemented as just another GRUB architecture), but I've never used it, nor does it seem to be in Guix. <terpri>nckx, neat, thanks for the pointer <terpri>we have...libgcrypt, i think, for general crypto tasks? dunno if it's unsuitable for grub for some reason though *terpri pushes another research topic onto the stack <terpri>i imagine grub has to minimize dependencies, but diy crypto is always a bit suspect <terpri>(if that's behind the slowness, again, i'm no grub expert) *nckx was unfortunately born with a ring buffer that happily overwrites itself. :-/ <nckx>No part of GRUB writes to file systems so I'm not sure it matters in this case. <nckx>I mean, the ‘security bugs’ (sigh) in GRUB I know about were NOT at the level of subtle bugs in home-grown crypto. <nckx>They were ‘hold down this button and the prompt goes away’. <terpri>oh, i think i heard about that one. probably a "fun" one to fix <nckx>Hanging libressl or libgrypt on the back or rewriting GRUB in rust won't save you from that attitude. <nckx>Not against defence in depth, just being cynical. It's Friday after all. I'm always cynical on a Friday. <terpri>i like rust, but i'm not rewriting anything in it until there's a gcc frontend ;) <terpri>not optimistic about that happening soon, even gnustep now recommends clang because gcc's objc support has fallen so far behind <NieDzejkob>oh, I see GRUB LUKS slowness is not only on my TODO list :P <nckx>terpri: Oh, I didn't know that. What a very Friday thing. <terpri>not for serious technical reasons AFAICT, just no labor-power to get features like blocks (C++-esque lambda expressions) working *jackhill wonders how gccgo is doing <terpri>so with that snippet pasted above, you can use `(build-system i686-build-system)' in your package and IIRC it will build it with a 32-bit toolchain and make a 32-bit binary that can be installed in a regular 64-bit profile (dragging 32-bit dependencies along with it, of course) *nckx .oO lambdas, you know, like in C++. <terpri>it may have bitrotten as it's a couple years old and i switched to attempting a polyml->mlton bootstrap (which is also quite tricky for different reasons) <terpri>my sml-related hacking is for hcoop.net, as adam chlipala cofounded hcoop and wrote a bunch of our custom tools in sml :) <apteryx>neat little improvement: (dependencies or package changed) <apteryx>when upgrading a profile. I think it used to say something like upgrading from 1.0.0 to 1.0.0 <NieDzejkob>terpri: wasn't polyml bootstrapped from more or less a hexdumped blob anyway? *civodul posts fun observations about the size of .go files <terpri>NieDzejkob, polyml is written in c, you may be thinking of smlnj, which indeed involves hexdumped blobs <raghavgururajan>nckx: Approximately how long the sheduled gc takes? Also, does it happen everyday? <apteryx>I thought GRUB slowness was a "feature", to make brute forcing user passwords more costly <nckx>apteryx: That's… not how it works. Attackers use the fastest implementation, users the slowest. <terpri>NieDzejkob, huh, never noticed that before. i wonder what that data's even for <apteryx>but if the key is wrapped in ten layers of expensive crypto, you can't really get away from the computing required, unless you found a flaw in the crypto itself <nckx>raghavgururajan: Twice a day, once of which is more thorough than the other. I don't have access to bayfront (yet), but if it's anything like berlin: hours. <NieDzejkob>apteryx: currently, both GRUB and the kernel do the key derivation during boot. GRUB takes much longer than the kernel <terpri>apteryx, it's not inherently slow crypto like bcrypt(?), the kernel does the same luks decryption as grub <apteryx>good point... I see what you mean then. and I agree that it's annoyingly slow. <nckx>apteryx: ‘required’ is the key there. GRUB does it much slower than Linux, yet both manage to read the disc just fine. <terpri>presumably an attacker would be using cryptsetup or something for brute-forcing disk access, not going through grub <cbaines>raghavgururajan, I wouldn't wait around for the gc to finish, it's going very slowly <nckx>The idea of a dim-witted attacker renting a GPU cluster to boot GRUB on it is too hilarious to discount. <cbaines>once it's done, hopefully you'll be able to pull, and I'll be able to reconfigure <terpri>nckx, or renting workers on mechanical turk or whatever to manually type passwords at the grub prompt on VPSes :p <nckx>Now that's too depressing and economically sensible to discount. <cbaines>Hmm, maybe I'll just stop it, I can try again later... <NieDzejkob>now I want to make a CPU emulator that uses mTurk for its ALU <cbaines>raghavgururajan, I've done so, so try again. It's hard to tell if it's worked, because everything is slow... <nckx>raghavgururajan: By the way, the gc's are scheduled at 04:00 and 16:00 local time. I'm guessing bayfront is in the same time zone as I am. It's 23:05 here. There's your answer. It's not a nice one. <nckx>cbaines: I've lost your nice monitor URL. Is bayfront monitored? <nckx>How does it not just flatline twice daily? <nckx>raghavgururajan: I *think* so. I checked and bayfront is set to (timezone "Europe/Paris") like me, not UTC. <apteryx>What's a good, quick way to test a SMTP server? I tried telnet, but it seems the connection closes on EHLO (due to TLS possibly) <apteryx>in fact what I'm troubleshooting as a local SMTP relay (I know the remote server works) <nckx>apteryx: I've used swaks and (shudder) raw openssl s_client in the past. <cbaines>Having not used a computer which uses spinning disks for quite a while, I wonder if bayfront is just as slow as computers used to be, and I've forgotten <cbaines>Or I wonder if there's a hardware/software issue causing it to be so unresponsive... <nckx>If so this sounds like a use case for something like bcache (not -fs). And no, I'm not a fan-boy, I've never used it myself. <nckx>Well, unless we buy a few TB of SSDs 🙂 <cbaines>nckx, I'm quite happy to throw a few TBs of SSD's at it, I started a thread on the list about this a little while ago <cbaines>Even in terms of storage space the hard drives offer, you can get 16TB drives now! <cbaines>I'm hopeful that the Guix Build Coordinator approach will allow build farms to work, without the big store constraint <cbaines>Doing 100,000+ builds for x86_64-linux for 100+ recent Guix revisions, and storing nars for all the outputs, it's 230GB of data <terpri>idk why you'd want traditional hard drives for anything but backups tbh <nckx>Which for ‘drives we already have for $0, Alex’ is, well, $0. <nckx>But I agree, I was an SSD hold-out and boy did I waste years waiting on I/O… <apteryx>nckx: the tool gave me confidence that what I was seeing in telnet was real <nckx>It is! Glad I could help. <rekado>terpri: cost is why we have 37TB (post RAID) of SAS disks attached to ci.guix.gnu.org instead of SSDs. <cbaines>nckx, so bayfront finished reconfiguring, but I forgot to git pull first :( <nckx>I admit to trying and worrying that it might've gone wrong again. <cbaines>experience says this won't actually create your home directory, but I know how to do that manually at least now <terpri>i've only priced out consumer-grade stuff i guess, and not in those quantities <nckx>And I'll have to chmod +x .profile IIRC. <nckx>Or .guix/profile? We'll see. <terpri>1tb sata ssds are getting fairly cheap though <nckx>Someone (rekado?) mentioned RAID-0 SSDs here y'day. <terpri>not criticizing your design choices, just curious <nckx>That together still gives me a funny feeling. <rekado>nckx: that’s for the root file system on all build nodes <nckx>I think that's a good call. <rekado>I didn’t want IO to be the bottleneck after spending much too long picking reasonable CPUS <nckx>You picked them? I thought they were donated. <rekado>no, we asked for money, stretched the budget repeatedly, and then maxed it out. <rekado>we didn’t have unlimited amounts of money, and we had to justify spending as much as we did. <rekado>looks like jupyter cannot be installed because two of its inputs request different variants of ipython <rekado>python-ipywidgets asks for (prompt-toolkit-2-instead-of-prompt-toolkit python-ipython) <rekado>but python-qtconsole just wants python-ipython <cbaines>I think I saw someone comment about that issue, I can't remember if it was on IRC or the mailing list... <kmicu>1tb SSD are getting fairly cheap‽ <cbaines>nckx, I think you should be able to login to bayfront now <cbaines>(I did have to create your home directory and stuff, so it's probably not quite right) <nckx>cbaines: I am! Thank you. <nckx>cbaines: I have skellington dotfiles though. Unless you copied those manually too. <cbaines>nckx, thinking about it, I'm not sure what your users password is... I didn't set one, but let me know if you need me to set an initial one for you <nckx>It's unset, I think that's normal. An initial one would be appreciated. <ngz>Hello. Is there any issue with Guix repository? It seems that I cannot push anything at the moment. <ngz>I get this: "[Kmake: *** [Makefile:5974 : authenticate] Erreur 1" <cbaines>I think there were some changes in this area recently <ngz>I added the pre-push hook a couple days ago <nckx>ngz: That's obviously a local error, so no need to be scared. The repository is cybersecure. <ngz>I was happily pushing to the repository 24 hours ago. <nckx>There was a change to the hook in the past hour or so. <ngz>I want may happiness back. Now. :) <ngz>Ok so I need to copy it again? <nckx>I can't say. You didn't paste the actual error nor can I think of why it would be failing only now. <ngz>It is actually the same. <ngz>The script I have in .git/hooks/pre-push is the same as in etc/git/pre-push