<usney>I really love the new documentation for guix! <usney>Well done guix team and community this time it worked flawlessly for me trying it again. I noticed that the documentation has been updated the last time I needed to use it. <usney>the documentation where it is always <usney>it appears to have been updated <usney>It is old documentation that had been updated <usney>this is for the foreign distro install so maybe it hasn't been updated for the guixd distro <usney>where is a good place like reddit I can get help and give help with guix? <usney>I need to reboot ryanprior I'll be back in a giffy <ryanprior>There is a Guix subreddit. I'm not on there & have no idea how helpful or friendly they are. <vagrantc>hrm. can't build guix from git: error: failed to load 'gnu/packages/networking.scm': <vagrantc>ice-9/eval.scm:293:34: Wrong type to apply: #<syntax-transformer base32> *vagrantc will retry again with a fresh "guix pull" ***dingenskirchen1 is now known as dingenskirchen
<nckx>vagrantc: It's 3102e8d37cbc77871e920e5328fa0045f09bf20b but I don't understand why. <vagrantc>nckx: thanks for the pointer ... will try reverting it and see if i can get further <wdkrnls>I have a dream of visualizing changes to my data using the r-v8 package. Unfortunately, it depends on having bindings to the V8 library. Supposedly that is BSD licensed. Has anyone tried to package it for guix? <nckx>vagrantc: At least it didn't break guix pull, which was my main worry. I'm trying to reproduce your error but am stuck waiting for build slots. <dftxbs3e>nckx, hey, is it OK to discuss ppc64le port here? It's possible it gets a bit floody but I also think it would be great for people to be able to read <sneek>Welcome back dftxbs3e, you have 1 message! <sneek>dftxbs3e, marusich says: FYI I was successful in reproducing 4 out of your 5 powerpc64-linux binaries - gcc-stripped-7.4.0-powerpc64-linux-gnu.tar.xz differs. <nckx>dftxbs3e: It's absolutely fine. <dftxbs3e>marusich, not sure why it differs, maybe it's not reproducible <marusich>I used diffoscope on the two binaries and there were a lot of differences... I suppose I could open up a bug report, but I haven't yet, since it was built from a commit not in the official guix project yet <vagrantc>with "guix package -u" there's the "--do-not-upgrade=PATTERN" option, but with "guix upgrade --do-no-upgrade=PATTERN" it doesn't recognize that option ... intentional? <dftxbs3e>Well yes, bootstrap binaries arent 100% up to date, as in, I got the big endian ones working once and never touched them again <dftxbs3e>Since then, I merged core-updates into my tree and still need to re-test everything <dftxbs3e>I could build GNU Hello without much changes at all so most of it just works <marusich>You worked around the bug by manually fixing the .go files, and thus created a new set of bootstrap binaries for powerpc64-linux-gnu. Using this, you were able to build many packages for powerpc64-linux-gnu. <marusich>Long term, it sounds like most people are using powerpc64le-linux-gnu, and distros are deprecating their powerpc64-linux-gnu builds in favor of powerpc64le-linux-gnu. But getting either one would be great for Guix for now. <dftxbs3e>Also, I don't know shit about GNU Guile or Scheme so it's not making my task easy <marusich>Just to make sure I'm gettin the terminology right, it looks like you chose to give the powerpc64-linux-gnu triplet the "powerpc64-linux" "Guix system" name. Did you intend to use "powerpc64le-linux" for the little-endian version if it worked out? <ryanprior>How do you delete a profile? Just rm -rf the folder or do you have to tell guix about the deletion specifically somehow? <marusich>ryanprior, I think you can just remove the symlink. Guix will clean up broken symlinks when it walks the symlinks from the gc roots. <marusich>I answered my own question; it looks like you intended to do that. Cool, those names make sense. <marusich>So you are saying the next priorities are: (1) for powerpc64-linux, fix or work around the guile problem and (2) for powerpc64-linux, get cuirass working so it's easier to see what's broken and for others to participate. <vagrantc>nckx: yeah, reverting that commit seems to be working <marusich>So one question I have for you dftxbs3e, is: using your manually fixed up bootstrap binaries, you were able to bootstrap your powerpc64-linux system. You can build packages now. Are you able to build bootstrap-tarballs on this system right now? If so, does the newly built bootstrap guile suffer from the same segfault problem? <dftxbs3e>well that would still make an impossible to bootstrap situation <dftxbs3e>since those would depend on an hacked tarball <dftxbs3e>without the hacked tarball, no one would be able to bootstrap ever again <dftxbs3e>that hacked tarball isnt built with GNU Guix only <marusich>Guix as a project, at least as the time we discussed it, agreed that although cross-compilation of bootstrap binaries is nice, it is best to be able to bootstrap from the architecture in question. <dftxbs3e>We could move the GNU Guile object compiling from bootstrap-tarballs to commencement.scm <marusich>It is better for owners of POWER9 hardware to be able to bootstrap from POWER9 hardware, than to require them to bootstrap by cross-compiling from a less trustworthy architecture like x86_64 <dftxbs3e>okay sure, but what do you bootstrap with? <ryanprior>How do you keep track of guix environments in your scm? What I've been doing so far is to put a manifest in the project root and check that in, then run `guix environment -m env.scm` when I'm ready to hack on the project. <dftxbs3e>Fedora, Debian, Ubuntu, others? Which have unknown or obscure bootstrap paths? <dftxbs3e>You can't, it doesnt work on it's own, it needs a working system <ryanprior>But that means the project doens't have a profile, which means I can't use guix to install new packages into it, it's vulnerable to gc, etc. <marusich>So concretely, one possible solution is for me and you to both do whatever it is you did to manually work around the bootstrap guile segfault issue. Replace the .go files, I think it was. If you can describe to me how you did that, I could do it, and we could hopefully arrive at the same result. <ryanprior>I could create a profile, but if I create it in the project directory, what parts do I check into source control? Just project-dir/.guix-profile/etc/manifest ? <marusich>Using that, we could maybe run "guix build bootstrap-tarballs" on POWER9 systems and confirm the results are the same... And we could use that result as the (second set of) bootstrap binaries. They would differ from the first set because they had been built natively on power9. <ryanprior>Then if I do check in that manifest file and somebody clones my repo & wants to populate that profile, what do they run to do it? <marusich>and hopefully that second set would not require manual tweaks, like replacing the .go files <marusich>and then maybe someday somebody fixes the cross-compilation bug, so it becomes possible for people to cross-build the bootstrap binaries and verify that they're the same. but waht I am saying is that, perhaps, the important thing is to first produce bootstrap binaries - even with a bit of manual work - that allow us to build functional bootstrap binaries on POWER9. <marusich>I'm just saying that it is more important to be able to build POWER9 bootstrap binaries from a POWER9 Guix system, than it is to be able to cross-build the POWER9 bootstrap binaries from another architectutre. <marusich>It would be nice to have both options, of course. <dftxbs3e>marusich, okay well get a guile bootstrap tarball, then extract the tarball and seek for .go files in it and you'll instantly see what you need to replace <dftxbs3e>you will be able to find these same files in /usr/share something in Gentoo which also has GNU Guile 2.2 installed <marusich>when you say "replace", how did you do it? <marusich>ah, ok, so you actually just replaced them with whatever was in gentoo <dftxbs3e>I used the Archive Manager GUI tool I think <dftxbs3e>but you would extract, replace and re-tar with some specific command <dftxbs3e>I don't remember how I did it exactly, it's been months <marusich>i also wonder if it would work without the .go files, though it would just be slower? <dftxbs3e>marusich, I actually havent tried, I was so pissed with GNU Guile being slow at that stage of it's own bootstrap process even on many cores I really didnt want to go through it again <estraw>Hi, I was wondering if anyone could help me with a problem I've been having with `guix offload`? <dftxbs3e>It is especially slow on powerpc64[le] because GNU Guile upstream doesnt provide pre-built Guile Objects for it <marusich>Another way to generate the bootstrap binaries would be by hand, e.g. get their source and do the compilation by hand <marusich>it would be great to solve the cross-compilation bug but i am also not a guile expert, and since it's an older version i'm not sure how easy it will be <ryanprior>estraw: if you post your problem somebody might have ideas, I don't know anything about `offload` though <estraw>I have a low-powered laptop and a much more powerful desktop so ideally I would want builds to happen on the desktop if possible <marusich>dftxbs3e, to unblock work i suspect we should try just deleting the .go files from the bootstrap binary and see if it still works. out of the manual fixes, if this works it seems like the simplest and least gross <marusich>*from the bootstrap guile's tarball, i mean <estraw>so i got a machines.scm file set up just like in the manual, but `guix offload test` fails with `guix offload: error: failed to connect to `#<input-output: channel (open) 7f82892d6fa0>': Protocol error` ***catonano_ is now known as catonano
<estraw>which is confusing because right before that, it says `guix offload: Guix is usable on '(desktop IP)' (test returned "/gnu/store/883yjkl46dxw9mzykykmbs0yzwyxm17z-test")` <marusich>if it works, i don't see why we couldn't just then build new bootstrap binaries from power9 directly, use those, and work on the cross-compilation bug fix later <estraw>I have guile-ssh installed on both machines and everything so I am confused about what is happening <estraw>I was wondering if it was a bug and I should go ahead and report it on the mailing list <marusich>Either way, dftxbs3e, before we can even do that, wouldn't it be good for us to polish up your changes that enable cross-building the bootstrap binaries for powerpc64-linux? That way, we (and anybody) could then run 'guix build --target=powerpc64-linux-gnu bootstrap-tarballs' using the official version of Guix, and we would be in a position to then either fix the cross-compilation bug or provide manual steps to describe how to make the first set <marusich>of official power9 bootstrap binaries from there. <marusich>I think getting those changes (but not yet the bootstrap binaries themselves) into master (or core-updates or wherever) is probably the very next step we should take. <dftxbs3e>marusich, yes, that would be great. But without GNU Guile cross compilation bug fixed that's not mergable to GNU Guix <dftxbs3e>or we remove things manually from the tarball <haha>you need 'guix install guile guix' <haha>Then import each other's keys through guix archive --authorize <haha>Please use guix archive --generate-key to generate the key <marusich>my understanding is that it would be ok to merge the changes into guix to enable the cross-building of the bootstrap-tarballs. the fact that cross-compiling them from x86_64 succeeds but produces a bootstrap guile that, when run on power9, segfaults, is not a blocker since it won't impact anybody <estraw>haha: did the key generation and have guile installed already, but i haven't tried doing `guix install guix` yet. Let me try that real quick <marusich>of course it would be great to fix it, but i think we will make more forward progress and be more likely to get help if it's in guix proper <marusich>and who knows...maybe cross-compiling from arm or something works fine :P <dftxbs3e>marusich, I think it's probably an endianness bug <estraw>haha: same thing occurs, "failed to connect to `#<input-output: channel (open) 7fb4db9fb3c0>': Protocol error" <haha>Where do you use guix? If you are using it on other distributions, you may need the correct environment variables <estraw>i'm using it on Ubuntu, so foreign distro <haha>this is my debian server's /etc/profile.d/guixenv <marusich>dftxbs3e, on wrinkle with merging your changes to guix is going to be that guix prefers a very specific format for git commit messages, so we'll probably have to create a new branch that cherry-picks the changes and reformats them to meet those standards <marusich>there is also the issue of the fact that one of the bootstrap tarballs is not reproducible; i suppose i should create a bug report about that, too <dftxbs3e>marusich, yes I am not really following the convention because I don't know it and it's been cognitive load for me to ensure I don't get it wrong and then need to force-push to fix it <estraw>haha, I'll try making sure those environment variables are set <estraw>unfortunately I have to go right now so i'll try that and if it doesn't work I'll see about reporting it on the mailing list or something <haha>Okay, maybe it should be written in /etc/profile.d/guixenv.sh <haha>On debian, it only executes /etc/profile.d/*.sh by default <haha>Well, it seems that I am late. <marusich>dftxbs3e, I can help with that. I guess I'm just saying, after we merge some commits, you may have some "duplicate commits" in your repo. I was just wondering what the best way to deal with it would be. <marusich>Maybe it would make sense to have a branch in your repo specifically to hold the changes we have polished up and intend to merge? <haha>Expect guix offload to have more friendly error prompts and better documentation in the near future. <ryanprior>Is there a reasonable way to check a profile into git if I create one in a project root dir? <dftxbs3e>marusich, yes, and we can cherry-pick unmerged commits onto it later <marusich>ok. i will try to collect the commits you have made that i can find that seem to provide what is needed to add powerpc64-linux (but not the bootstrap binaries yet) <marusich>i will rewrite them in the format guix wants <dftxbs3e>In the mean time I'll try re-doing things properly thing GNU Guix master branch see if the double situation has changed <marusich>that would be great. i suggest you try core-updates though <marusich>gcc, glibc, those low level dependencies, they tend not to be updated on master frequently <marusich>they are more likely to be up to date on core-updates <marusich>ryanprior, to make it possible to reproduce the profile, you could provide a manifest file and also a channels file. with both, any user of guix can reproduce the profile <marusich>alternatively, you could provide a package definition in a single file, along with a channels file, and then people could do 'guix build -f thefile.scm' to build it, or 'guix environment' to get its inputs in an ad-hoc environment <dftxbs3e>marusich, core-updates is no more, it's been merged into master <dftxbs3e>core-updates is also likely to be broken so it's not really a good choice I think :-/ - considering it's been merged recently I think there's not much more that has changed in core-updates later <vagrantc>core-updates doesn't have any huge updates on it at the moment since it was recently merged <marusich>i need to step away for a little while, but when i return i will get to work on rewriting the commits. i will also try to poke more at the guile segfault... <ryanprior>marusich: by a manifest file, do you mean the file named "manifest" in the profile directory? <ryanprior>I just saw you're stepping away, I'll ask later =D <marusich>dftxbs3e, ahhhh, i just realized that "just delete the .go files" may not be so simple for the bootstrap guile, since it seems it ONLY contains the .go files <marusich>I think I was looking at the wrong thing. <marusich>The guile-static-stripped-2.2.6-powerpc64-linux-gnu tarball does indeed contain both .go and .scm files. <nckx>ryanprior: See --manifest in (guix)Invoking guix package. <nckx>Didn't mean to butt in; I'll butt back out. <dftxbs3e>marusich, I think it will work if you just delete the .go files :p <ryanprior>So what I get from that answer is no, there's no reasonble way to check a profile directory into source control. That's too bad, & maybe something we can fix. <nixfreak>So I'm trying to understand roll-backs and generations, so each download you do is a generation or the previous generation is all the packages at that current state ? <ryanprior>nixfreak: each time you install, uninstall, or update a package (or many at once) it creates a new generation. It doesn't modify your old generations or the packages they point to, so you can always time-travel back to a previous state. <nckx>ryanprior: You can by checking in your channels.scm and your manifest.scm, and treating the profile directory as an artefact of those. It's not source. <ryanprior>Inconvenient that guix provides commands for manipulating profiles but not for manipulating manifests. <nixfreak>so can I create two different profiles say I want desktop A with the first one and Desktop B with the second , both are separate ? <dftxbs3e>marusich, also that: "dynamic linker name not known for this system "powerpc64-linux"" - GNU Guix master doesnt have the linker name for big endian <ryanprior>If a profile contained its source within it, you could check that data in and regenerate the profile on demand elsewhere. <ryanprior>nixfreak: in addition, if you have two profiles that are non-conflicting (say, one provides your desktop files, and another provides your Python dev tools) you can even use multiple profiles at the same time. <nckx>Guix is a bit⌠searching? when it comes to manifests, as illustrated by the fact that two totally different file formats are called âmanifestâ. <nixfreak>ok , so where can I read about that , and how to download packages to a specific profile? <ryanprior>nckx: yes it's definitely a jagged edge of guix right now imo & could use an overhaul. <nixfreak>So I can delete all my generations accept for the first one and I will still have all my packages up till now or no? <ryanprior>nixfreak: if you remove old generations then you won't have the history anymore of what your old states of your machine were, but the packages will still be on your system until you run `guix gc` which will find and delete them. <nckx>Generations are similar to snapshots on certain file systems, except you don't create them manually. Every time you âguix <something> <package>â it creates a new generation for you. <marusich>dftxbs3e, right, we'll have to pull in your patches to build it. <marusich>By the way, i just tried removing the .go files and it was super slow but it ran --version OK <marusich>I also see that we define a %guile-3.0-static-stripped which looks very similar to the %guile-static-stripped that is used in the bootstrap tarballs. I am going to try cross-building it to see if version 3 also suffers from the segfault. <lfam>Is anyone running an Icecast server with Guix System? <reepca`>so initialize-user-namespace in (gnu build linux-container) allows for specifying the guest uid at which the mapping should start but not the host uid at which the mapping should start. So for example, if you had CAP_SYSADMIN but uid 1000, you still couldn't use it to map real-uid 500 to some uid in a container. ***bubble01 is now known as zpataki01
<reepca`>the reason we use multiple build users is so that we can kill any leftover processes of a build, right? <marusich>i thought the reason we use multiple bulid users is to ensure that different users can't interfere with another builder's build <marusich>i.e., builder1 and builder2 cannot write each others' files or outputs <haha>Whether Guix System should provide a linux-libre-virt kernel? there is a problem with the default kernel running on the kvm server. <marusich>but if they're both in a sandbox, i guess it wouldn't matter if they were the same user? <haha>This problem seems to be caused by CONFIG_WQ_POWER_EFFICIENT_DEFAULT = y. <reepca`>yeah, I'm focusing on the "containers are available" scenario right now <reepca`>in which case the only reason I can recall that would still apply would be that if you don't kill all the users that can write to the output prior to chown'ing it, there's a race condition where the setuid bit can be set <reepca`>but it just occurred to me that we're already using a pid namespace <reepca`>so when the "init" process of that namespace dies, so do all processes in it <reepca`>oops, s/kill all the users/kill all the processes/ <usney>I can't seem to update guix with guix pull <marusich>dftxbs3e, it built the bootstrap-tarballs successfully previously, right? ***bubble01_ is now known as bubble02
<nckx>usney: Bit more info would be nice. <usney>it just stalls I am using a vpn if that would cause that issue nckx <usney>I can't ping the link that guix pull uses too <nckx>I guess that would depend entirely on the VPN (and I've never used one). I just pulled successfully from two machines, albethem both in the same spot. <nckx>usney: You can't ping git.savannah.gnu.org? <nckx>Then it's definitely something on âyourâ (provider's) end. <usney>I've pulled successfully using this vpn before <nckx>Can you afford to try without it? <nckx>Otherwise an mtr or so from within the VPN might be interesting, although I'm not sure how actionable it'll be. <reepca`>"download stalls" sounds not unlike what I've run into before with my potato connection, where the router discards its routing table every 10 minutes or so <nckx>usney: If not, you can always replace the âguixâ channel with https://github.com/guix-mirror/guix. It's not official but the last commit is currently signed by nckx, no idea who that is but they sound legit. <nckx>(Obviously assuming that file doesn't already existâŚ) <nckx>Inb4 I'd gladly recommend another mirror host if I knew of one. <usney>nckx I recently manually changed my host name ***bubble01_ is now known as bubble02
<marusich>dftxbs3e, I tried cherry-picking some commits from master to build %guile-3.0-static-stripped, and it failed to run with a different error than the segfault: <marusich>I'm not sure if that's really good or bad. Maybe it means the segfault doesn't happen on Guile 3? Or maybe it just errored out before it got to the point where the segfault would have occurred... <marusich>To be clear: I cherry picked some commits from master that enabled me to cross-build %guile-3.0-static-stripped via: ./pre-inst-env guix build --target=powerpc64-linux-gnu -e '((@@ (gnu packages make-bootstrap) tarball-package) (@ (gnu packages make-bootstrap) %guile-3.0-static-stripped))' ***bubble01_ is now known as bubble02
***reepca` is now known as reepca
***rekado_ is now known as rekado
*mbakke has watched too many french TV shows lately <mbakke>janneke: well just one, but still ... I don't consider myself a TV person :P <mbakke>I just could not stop watching "Le Bureau" <janneke>mbakke: interesting...there's a literary book sequence called "Het Bureau" in Dutch <janneke>apparently they are completely separate <civodul>mbakke is talking about "le bureau des lĂŠgendes", right? <janneke>anyway, it's already getting busy at the guix office :-) <civodul>so how's everything today comrades? bright and sunny? <rekado>today we may need to reboot berlin.guix.gnu.org to apply an upgrade to the two 10G network cards <rekado>and if this doesnât fix our problems we will swap the two cards, using the âbrokenâ one for communication with the build nodes and the âgoodâ one for communication with the outside world <rekado>(if that also doesnât fix it we will swap out the server for one of the new build nodes, but perhaps not today.) *efraim chooses to read mbakke's "not good" as civodul not having watched the show ;D <janneke>mothacehe: time to open a "merge wip-hurd-vm" bug, wdyt? (some squash/cleanup/drop/ implied) <civodul>rekado: thanks for the heads-up, crossing fingers! <mbakke>civodul: I suppose the static-web-site-job uses the 'installed' guix, which has not been updated with the fix yet <civodul>mbakke: ah yes, you're right, silly me <janneke>yeah, civodul,mothacehe: one main question would be about the qemu-image cross build for the hurd: do we drop it just before or right after merging? but perhaps that's also best to talk about in the bug <azvede>so.... is guix os like qubes in not supporting running virtualized? I've tried installing from ISO in vmware workstation, vbox, and hyperv... and the qemu image in vbox and hyperv... all have failed so far... trying to troubleshoot but figured I should ask <rekado>azvede: you can run Guix System in Qemu+KVM <mbakke>civodul: I guess we should just update the 'guix' package <azvede>installing from iso, I get through the install config process, then it fails whhile loading packages <rekado>azvede: itâs explicitly supported. We also offer a Qemu image for download. <rekado>azvede: âfails while loading packagesâ â how? <azvede>typically by going into a loop like "loading fonts, hash does not match, falling back to another source, loading, no match, fall back, etc." <mbakke>azvede: did you notice the package name / URL ? <azvede>it was different each time... would normally get through a few packages each attempt then hang and die <azvede>trying to get to that stage again to copy out details <azvede>vmware and vbox both said the qcow2 drive had no bootable OS <azvede>ah crud.... internet going fritzy.... I'll try some more things and come back tomorrow with details.... sorry for not having them tonight <sneek>abralek, you have 1 message! <sneek>abralek, civodul says: re Guile-WM, i don't know if the issues are documented, but you can give it a try and see how well it works for you! <abralek>However protocol-configuration is defined like a general one. So my question is how you do you think I need to add that feature? <abralek>Is it ok, to just add yet another configuration field, or specified a dedicated IMAP protocol configuration? <abralek>civodul: re Guile-WM, ok, Thanks I will check. Many thanks for the review by the way! I will respond to your commens later on. *rekado rebuilds GHC yet another time⌠<mothacehe>janneke: pushed the non-controversial commits of mine to master. Now looking to "WIP hurd-directive". <mbakke>rekado: do you think it's possible to add a 'lib' or 'cabal' output to GHC that does not reference the compiler? <pinoaffe>hi guix, lxrandr only seems to work when xrandr is also installed, but xrandr is not a propagated input of lxrandr - is this a bug or is this one of those "choose your own implementation" things? <rekado>mbakke: thatâs what Iâm trying right now and the reason for the rebuild <rekado>mbakke: the reason why all Haskell packages keep a reference to GHC is because of the core packages that it installs <rekado>unfortunately, I think a âlibâ output alone with â--libdirâ wonât work, because the compiler executables actually also live in âlibâ <rekado>I would like a separate output for built-in packages and one for the compiler stuff <mbakke>pinoaffe: sounds like lxrandr needs to be patched to include the absolute file name of 'xrandr' <rekado>but the build system doesnât seem to allow for a split like that. <lprndn>rekado: just to say that I'll probably try something on the lightdm service. (getting rid of the greeters field altogether) <lprndn>rekado: we would just use a greeter record as input of the greeter field from seats. I think it make sense and follow the spirit of upstream config. also we could introduce a set-greeter-configuration procedure... <pinoaffe>mbakke: ah yes, I guess that that should also work <rekado>lprndn: ah, yes. The shepherd service would only have to collect the greeters from all seats and augment PATH before running. <chromebook>Is a shell provided in the initrd of Guix System? <chromebook>My Guix System server failed to boot. I don't know how to use repl to diagnose the problem. <mbakke>chromebook: I suppose rolling back is not an option? <chromebook>This is a cloud server, I can't connect to its vnc while grub is running <jas4711>hi. i have a machine that i installed guix on 2018-August and i just did some 'guix gc' runs to clean up /gnu/store a bit. still, it contains a lot of *.drv files for old stuff. are they really required? how do i clean them up? <mbakke>chromebook: maybe you can (use-modules (guix build utils)) and (substitute* "/boot/grub/grub.cfg" (("default=0") "default=1")) to make a roll-back <cbaines>jas4711, what settings are you using for --gc-keep-outputs and --gc-keep-derivations for the guix-daemon? <chromebook>Does anyone use make nconfig in the Guix System to configure the kernel? I want to modify my kernel configuration but it tells me that I have not installed ncurses <chromebook>Actually I have installed ncurses in the user's profile <efraim>chromebook: start with 'guix environment linux-libre' and then add more packages as needed, 'guix environment linux-libre --ad-hoc ncurses' <efraim>chromebook: did it tell you what else it wants? <chromebook>Just told me that ncurses was not found and needs to be installed. <efraim>i thought pkg-config should be there but lets make it definate <efraim>'guix environment linux-libre --ad-hoc ncurses pkg-config' <chromebook>I will try again in a while, I now manually modify the kernel configuration and it is now compiling. <civodul>(not typing on a keyboard, typing as in "static", ooooh) ***Savoritias is now known as MSavoritias
<mothacehe>civodul: I did hesitate, but you're right it makes more sense, I'll change that. <mothacehe>janneke: I'm not sure what to think about <hurd-menu-entry> in (gnu bootloader). This kind of abstraction would mean that we need to add a new record for each new supported Kernel. That makes some duplicated code. <mothacehe>maybe we could have a "kernel" field in <menu-entry> and have a kernel specific record inside? <janneke>mothacehe: yes, i wrestled with that and decided to just choose the "simplest" solution initially <janneke>when i look at how it's used (initialization and later with the match in bootloader/grub), this seemed easiest <janneke>it's tempting to instead of "hurd" try to support "multiboot", but that really felt like a stretch <janneke>ah, also i took the choice for "linux" instead of "kernel" to mean: let's keep this specific <janneke>but i'm really fine with linux->kernel and adding a "hurd" field, i maybe civodul can venture an opinion? <mothacehe>janneke: yup agree about "multiboot" support. We can also choose to keep what you did and wait for a third type of Kernel to deal with that complexity. <janneke>mothacehe: yeah, i did not see an obvious simple/good choice so i postponed that :-) <janneke>if you look in bootloader/grub, you see that we pull "libc" out of thin air <mothacehe>But having "label", "device" and "device-mount-point" fields is maybe not that great. Let <janneke>another option could be some base <menu-entry> plus a specific extension structure <mothacehe>yes having those "with-parameters" for mach and glibc works but still seems a bit hacky. I need to think more about it. <mothacehe>janneke: yes we could have hurd-menu-entry and linux-menu-entry inheriting from menu-entry. <dftxbs3e>sneek, later tell marusich yes I think it used to build at that point <civodul>janneke, mothacehe: did you start a discussion on guix-patches or -devel? <civodul>but anyway, i'm not sure 'kernel' would work <janneke>civodul: no, not yet -- only here ATM <civodul>so we have linux and linux-arguments <civodul>i think we must simply mirror what GRUB does because it got the abstractions right <civodul>so that would be adding a "multiboot-modules" field <civodul>which would be a list of of commands <civodul>like (list (list (file-append hurd "/hurd/ext2fs") "...") (list (file-append hurd "/hurd/exec") ...)) <civodul>in practice presumably only (gnu bootloader grub) would implement it <mothacehe>civodul: makes sense. extlinux has also support for multiboot but I see no point adding it right now. <janneke>possibly -- would could still have <menu-entry>, then have <linux-menu-entry (adding the linux stuff) and <multiboot-menu-entry> inherit from that? *janneke just copies mothacehe's idea from history above ;) <civodul>we don't quite have record inheritance without GOOPS, except on 3.0 <mothacehe>"linux" is a command of Grub after all, same as <civodul>janneke: so i'd so just one big <menu-entry> with all these fields <janneke>copying something that's done right, makes sense! <civodul>and with the understanding that some are mutually exclusive <civodul>besides, i'm interested in using inheritance more once we've dropped 2.2 support <civodul>(3.0 supports inheritance for all record types) <mothacehe>it would also be nice if "mach" and "glibc" could make their way through "multiboot" or "module" field of <menu-entry>, instead of appearing out of nowhere in (gnu bootloader grub). <janneke>civodul: if we add multiboot-modules to <menu-entry> (instead of kernel, hurd), won't that push grub-specificness from grub.scm into system.scm? <mothacehe>janneke: that would also mean that <boot-parameters> is also extended to contain a "multiboot" entry. So yes, the complexity would move to (gnu system) but that's not necessarily "grub-specificness", because extlinux bootloader also has multiboot support for instance. <dftxbs3e>sneek, later tell marusich also there's a netdata instance on the POWER9 VM I gave you access to, you can reach it by redirecting the 19999 port to your local machine. It allows you to monitor the resource usage of the machine during builds <civodul>janneke, mothacehe: Mach would be 'kernel' <civodul>glibc doesn't need any special treatment i think <civodul>and yes, <boot-parameters> needs to be extended to reflect these addition <civodul>so to sum up, the following fields would be added to <menu-entry>: kernel, multiboot-modules <civodul>janneke: it's not GRUB-specific though, in the sense that GRUB closely matches the underlying abstractions <civodul>that is: "multiboot kernel + modules", or "linux + initrd", etc. <lprndn>rekado: for the lightdm service, what do you think about adding not documented fields to greeter fields to set greeter-name and stuff necessary to avoid using (cond ...)? Or is it awkward programming practice? <nixfreak>Ok , so I read a lot on generations and giux pull , so basically you want to upgrade your packages per profile instead of of just using giux pull to upgrade everything, is it possible to create offline repos like this also? <cbaines>nixfreak, I'm not sure what an offline repo means? Interpreting "repo" as Git repository, they generally work offline. <cbaines>as the the Scheme Crash Course page you mention, can you describe what issue you're having? <nixfreak>I'm trying to paste a screenshot to show you <bricewge>lprndn: I can't find where 'greeter-name' is used BTW <cbaines>nixfreak, ah yeah, that does look like a font issue. I'm not sure what to suggest unfortuantely <nixfreak>ok , I'm just going to use qutebrowser then <civodul>or try "fc-cache -fv" and restart icecat <civodul>perhaps you're actually missing a font <lprndn>bricewge: Here I don't refer to any field we use for now. I meant "the name used in the greeter-session field of lightdm.conf". I'm exploring other possibilities. <apteryx>bricewge: I was able to NFS boot the ts-7970 board from a rootfs hosted on my Guix System :-). Keys were: for the NFS server, specifying older versions (2 and 3), enabling UDP; use the following exports line: /path/to/rootfs "*(rw,no_root_squash,no_subtree_check)", and finally, specify the option 'v3' for the Linux command line argument: nfsroot=10.42.0.1:/path/to/rootfs,v3. <nixfreak>@cbaines , that worked. I didn't know that existed <cbaines>but yeah, out of date font caching is an issue <bricewge>lprndn: I'm lost here, a 'lightdm-configuration-greeter-name' field does exist (at least in some revision of your patchset, but I don't find it on my branch...) and rekado's diff does contains a 'greeter-name' procedure that uses a 'cond' but he doesn't use it in its diff... <bricewge>apteryx: Awesome, I should try with my BeagleBoneBlack. What distro did you boot on your ts-7970? <apteryx>bricewge: an image generated by Buildroot (this is work related) -- although I'd be thrilled attempting to migrate away from buildroot to Guix System <lprndn>bricewge: You're right. I'm trying to replace the input of the greeter-session field of seats with a greeter record. Does it make sense? <bricewge>apteryx: Adding support to boot Guix System from NFS will hopefully help you going in that direction <apteryx>bricewge: yes! It seems it shouldn't be too hard, given the support is in the kernel Linux <lprndn>to remove the `greeters field of the lightdm-service-type used in rekado's diff. <bricewge>apteryx: What are you missing else to have feature parity with your current tool-set? Just curious <bricewge>In his talk mothacehe suggest that he could already use Guix in some ways instead of Yocto and Buildroot <kamil_>Hi Guix o/ I've defined my first package, but I'm having a problem with building it. I get a cryptic message that says: "guix build: error: #<unspecified>: not something we can build". I can't find any typos in objects, such as "#:use-module" and "#:configure-flags". What could be wrong? <rekado>kamil_: you probably use âguix build -f file.scmâ; in that case file.scm must end with a package value, not a definition. <nixfreak>I'm sure the devs get this question , but "why scheme"? why not CL (common lisp)? <apteryx>bricewge: not much really, we're just using Buildroot because it's established in our team (alongside Yocto) <rekado>kamil_: (define foo (package âŚ)) does not evaluate to a package value but to #<unspecified> <rekado>hence you should end your file with âfooâ <apteryx>bricewge: But I've yet to try switching the complete workflow so I guess I'd have similar remarks to what Mathieu had *rekado finds CL icky in ways that Scheme is not. <dutchie>had most of a message typed out saying "this python package that uses cython isn't building" but then i noticed that i had added the native-input for cython to the wrong package def :) <bricewge>lprndn: Thanks I understand know. Having undocumented fields doesn't sound good; 'match' could be used instead of 'cond' tho <kamil_>rekado, what you mean is that that there should be a package value at the end of file.scm, or in the name of the file.scm itself? <apteryx>lsblk sometimes doesn't seem to refresh the list of block devices; is there anything I can do to "help" it? <rekado>the name of file.scm doesnât matter <rekado>âguix buildâ reads the file and whatever value comes last is built <kamil_>rekado, Pardon my ignorance, but I don't know what a package value is yet. <rekado>in your case that last value is #<unspecified>, because the last expression is one that doesnât have a return value <rekado>your file ends with (define my-package (package âŚ)) doesnât it? <apteryx>I'm guessing we're lacking some udev rules to make lsblk refresh its content (it uses udev db) <rekado>is the last expression in the file a definition? <mroh>good morning guix! lets have a nice day! <apteryx>nckx: my use case is I plug a SD card USB adapter, and it exposes block devices such as /dev/sd{c,d}. <nckx>mroh: Excellent advice! I've already started. <apteryx>I see those under /dev/*, but lsblk doesn't show them, sometimes. <nckx>Oh, that's odd. I've never seen that happen (but then I plug in things⌠monthly). <kamil_>rekado, is an "expression" in the context of a package-defining file something like (description"") or (define-public name-of-package)? <nckx>lsblk shouldn't use udev to *get* the devices. <nckx>Just to find out more about them. <apteryx>this leads to confusion and in the worst case me dd'ing the wrong drive ;-) <apteryx>then I don't know what is wrong, I seem to be the only person on my team having problems with this SD card adapter. <nckx>But this is such weird behaviour that I'm not going to further speculate with dd in the room. <apteryx>to be clear the dd part is entirely human error (me thinking this /dev/sdf drive must be the one that the sd card should have mounted when it's in fact some other external drive plugged in -- with lsblk not being helpful :-)) <nckx>kamil_: An expression is anything that returns a value, like â1â or â"string"â or something more complex. So â(package âŚ)â foo is an expression that returns a package object, so is âcoreutilsâ. But â(define name (package âŚ))â just binds a package value to a nameâit doesn't return anything itself. <nckx>apteryx: All I can think of is that on my old laptop (or maybe kernel) SD cards showed up as /dev/sdfoo, now they show up as /dev/mmcfoo. <nckx>Meanwhile the TLS handshake has completed (<10s, nice) and that's not your issue. <dutchie>hmmm, now ctypes is giving me "cannot open shared object file". i have the package containing that file as both a native-input and a propagated-input (which feels wrong) but i'm not sure what else I need to do to make it visible <nckx>apteryx: lsblk should use /sys as its source of truth, which is directly populated by the kernel (assuming drivers). So /dev/sd{câŚf} exist? Any partition devices alongside them? <nckx>Do â/sys/class/block/sd{c..f}â exist & look sensible? <nckx>Thinking mainly of the content of âsizeâ & âueventâ files. <bricewge>kamil_: Add 'nano' at the end of the file <kamil_>It's been built successfully. Awesome! <bricewge>apteryx: As you think we are missing udev rules: does your coworkers have 'hwids' installed on their systems? <nixfreak>so I should be able to create a manifest say for nim and nimble to install dependencies say for inim all in one shot <janneke>mothacehe: i locally rebased and somewhat cleaned-up wip-hurd-vm, and pushed to my gitlab <janneke>i guess we'll want address the <menu-entry> thing before resetting savannah <apteryx>nckx: the weird thing about this adapter is that it readies block devices before any actual SD card is plugged in <nckx>apteryx: I had some time to dig around in the Drawer Of (dusty) Doom here for SD card readers. I'm still sceptical it's udev, but who knows⌠I can't reproduce your weirdness no matter how or when I eject, sorry. <roelj>In the past there used to be a few graphs showing the number of commits to the Guix repository over a time period. Are these available somewhere? <nckx>roelj: Remember anything about them? <apteryx>nckx: ah, thanks for trying anyway :-) <apteryx>maybe this device is actually special <nckx>None of mine create phantom device nodes for empty slots. Ejected cards immediately vanish from /dev. <nckx>And I certainly don't run anything like udisk. <roelj>nckx: I think Ludovic used a web interface for this. I'm trying to find a reference to it.. <roelj>Some repository hosting website <mothacehe> janneke: Ok. I'm working on "WIP hurd-directives". I'll ping you when its done so that you can rebase your branch on top of that, if it's ok for you? <rekado>this seems to be 8 months old, though <mothacehe>basically, I'm setting "-o hurd" and stuff as partition-file-system-options, so that we can spare the "(if hurd ...)" conditional. <nckx>Creating a non-GitHub account on âOpen Hubâ requires a phone number. <janneke>i have just literally reverted the three <hurd-menu-entry> commits, and am dabbling with extending <menu-entry> <janneke>planning on mailing a WIP'py diff around when it starts to work (or when get stuck ;-) <apteryx>I reconnected multiple times, with the SD card in <rekado>Iâm going to shut down cuirass on ci.guix.gnu.org to prepare for a reboot and firmware upgrades on all nodes *civodul supports the endeavor from far away <lprndn>rekado: I have news on the lightdm PATH issue you had. In fact lightDM doesn't need the greeter in its path but its own /bin, /sbin. <mothacehe>It deals with the first half of "WIP hurd-directives", now the other half! <janneke>i just "moved" <hurd-menu-entry> into <menu-entry> (well, just like civodul proposed of course) and am now looking into boot-parameters <mothacehe>Perfect :) The boot-parameters stuff is a bit wobbly from what I remember. You may want to check that reconfigure, switch-generation & friends are still working afterwards. *civodul watches enthusiastically while doing less-fun stuff for work <janneke>mothacehe: hehe, which tests do i run for that ;-) *janneke feels civodul's encouragement and is glad to see rekado join again <civodul>the thing is to ensure that old guix can read new "parameters" file and vice versa <civodul>this should be easy since the new fields are optional <janneke>right, modulo typos that should be pretty easy to do <civodul>the funny thing is that people will be able to reconfigure and reboot into GNU/Hurd :-) <janneke>yeah, but once they do... *evil grin* <janneke>it's pretty amazing, supporting that on what /seems/ to be just one / <janneke>some smallish things need to happen still, i guess <civodul>actually i don't know what happens when you try running on an ext2 partition that doesn't have the "hurd" owner <civodul>well, probably you can't set passive translators <civodul>but if that's the only thing, that's kinda okay <civodul>then again, it has to be old-style ext2, not ext3/ext4 <janneke>ah, right...well, someone might write a patch <janneke>i was thinking even more mundane, activation, /run/current-system switching etc *janneke exports <menu-entry> for first rewrite...not sure if that's OK <janneke>well, for a first rewrite everything is OK...;-) <civodul>ah right, activation wouldn't quite work, too :-) <bricewge>lprndn: 'greeters-directory' should work too, no? <bricewge>We could appens each greeters to that that config entry or use 'file-union' to get a directory containing the greeters binaries <lfam>I was wondering, why update the Syncthing dependencies without updating Syncthing? <lfam>efraim: Mainly I ask because Go packages should try to use the exact versions of the dependencies specified in their go.mod files ***bubble01_ is now known as bubble02
<lprndn>bricewge: the seat configuration needs a greeter-session name anyway. One to look for in the greeter-directories. but maybe you're talking about something else? <bricewge>It was set to "/run/current-system/profile/share/xgreeters" in previous patches <lprndn>bricewge: yes, but I think I don't understand what you mean. Can you clarify? :/ <bricewge>lprndn: You said that "lightDM doesn't need the greeter in its path but its own /bin, /sbin." which I understand to be /gnu/store/...-lightdm-1.30.0/{,s}bin which is problematic in Guix since those paths will only contains lightdm's own binaries and not the greeter <bricewge>lprndn: Hum, RIcardo's patch correctly set greeters-directory put he got rid off lightdm-profile-service, so /run/current-system/profile/share/xgreeters is probably empty <bricewge>Don't listen to me, it seems I can't read <lprndn>bricewge: haha no problem. :) Just to clarify, what I found is that lightdm needs to have its own binaries in its path to work. The greeters'ones aren't needed, probably because we hardcode their path in the greeter's .desktop file. <ryanprior>My GUADEC talk was accepted! I'll be giving a 25-minute brief practical workshop on packaging GTK apps in Guix. <efraim>lfam: I had an extra two hours and I had time to build syncthing with each commit. I was also trying to work through an inconsitency with some of keybase's dependencies <lfam>efraim: So, some of these packages are used by both Syncthing and keybase, but at different versions? <efraim>I didn't check the versions as much for keybase, but go-github-com-rcrowley-go-metrics and go-github-com-syndtr-goleveldb don't want to play nicely <lfam>Don't play nicely with Syncthing? Or with keybase? <lfam>Maybe the Syncthing package should just use it's bundled dependencies instead. <efraim>that seems like a step backward though <lfam>In Go, it's not quite right to use the wrong versions of dependencies, unlike with other languages <lfam>I don't think it's necessarily a problem. They are all free softare <lfam>And, we can't really progress with Go packaging until we do something about this issue anyways <efraim>it'd make packaging easier, but make license auditing harder <lfam>Only a bit harder. The source code will be in the Syncthing tarball <lfam>It was suggested that we treat importer outputs as fixed output derivations for languages like Go, and I think it's the right move <lfam>Guix can technically handle multiple versions of dependencies, but it's not convenient <lfam>And already we have trouble with Syncthing regarding the murmur3 package <efraim>are we not caching enough build artifacts with go? I know we don't save any with rust right now <lfam>What we are doing is not idiomatic and it's not really nice to the Syncthing upstream to distribute the package with differing versions of the dependencies <lfam>Currently we don't re-use any built artifacts for Go. It may be possible but I didn't figure it out yet <lfam>The packages are effectively source-only <lfam>Does keybase also come with bundled dependencies? <lfam>I'm a bit confused. Does Guix have keybase packages? <efraim>and non-free fonts and a bunch of build instructions for an electron package <efraim>not yet, I have one that I'm working on <lfam>Can we revert your changes until they are useful in Guix proper? <efraim>Some of them look like version bumps but really are just relabeling the version <lfam>In the long run we will probably have to do something like that importer fixed-output derivation idea for Go and Rust <lfam>The workflow seems impossible otherwise <efraim>I thought about modeling the #:install-source keyword for rust and using it for build artifacts, but making it go to a separate output on packages with useful binaries <efraim>then we'd get the dependency tree and possibly also reuse build artifacts <lfam>Right, I was thinking along those lines too <lfam>It would be great to get the dependency tree, although I think there are cycles that are being elided by not keeping a graph <lfam>Like, that's the reason the rust build system is how it is <efraim>I was going to leave the #:cargo-inputs as-is to ease the transition and allow easier use of source-only inputs <rekado>ci.guix.gnu.org is rebooting now <PotentialUser-41>has anyone running guix on armhf systems seen problems with the recent master branch? <lfam>PotentialUser-41: Why? Are you having problems? <PotentialUser-41>networking started failing on activation for me after the recent merge from core-updates to master <PotentialUser-41>i fixed it locally by patching syscalls.scm but i was curious if it was just me <lfam>Not sure but, in general, you'll get more help more quickly by being specific about what problems you have and what you tried <PotentialUser-41>Sure, on boot all networking fails to activate including loopback. A not-so useful message is logged. I tracked the issue down to guix/build/syscalls.scm. <PotentialUser-41>so syscalls end up being set up for hurd since it doesn't match the string suffix rather than linux <lfam>That sounds like a bug PotentialUser-41. Can you report it at <bug-guix@gnu.org>? <PotentialUser-41>Ok, will do. I have a patch that resolves the issue that I can submit too. <lfam>Okay, please include that in your bug report <rekado>bah, problems with booting the server <rekado>and the management interface wonât let me log on so I have to remote control a human in the data centre⌠<rekado>looks like our post-reconfigure hook to copy the kernel to the root file system stopped working <butterypancake>for guix system, how do I make it so shepherd runs for each user? So users can create user services? <rekado>yeah, so now we need to manually boot kernel and initrd that *do* exist on the root file system from before the hook stopped working <rekado>of course those system generations have long been removed <civodul>i don't get how it could stop working, we'll have to investigate <civodul>also, how can the system generations be removed while they're in grub.cfg? <rndd>hi everyone! is it possible to comment guix channel and pull other channels? <civodul>rndd: from the command line you can use --url to pull the 'guix' channel from a different URL <civodul>however, this is not authenticated, so you don't know whether you're pulling the "real" guix <civodul>so... not recommended, if that's what you had in mind <butterypancake>hey guys, I'm having trouble finding any documention of user level services. I found an article on how to create some by using the .config/shepherd/init.scm file but that only works after I run the shepherd command as a user. Is there a way I can make it so shepherd is automatically run for all users? Also where is all the user level services documention? <rekado>civodul: I think the problem is that it copies *-profile instead of *-linux-libre* <rndd>civodul: i'm trying to learn packaging and wanted to just pull my own test chanel without guix becaus it has some problems <rekado>so it did copy the kernel but under a wrong name <civodul>like xyz123-linux-libre instead of "kernel"? <lfam>butterypancake: Currently, support for user shepherd is pretty simplistic. You can start your user's shepherd by running `shepherd` <civodul>rndd: you must always have the "guix" channel, you can't pull from just another channel <lfam>butterypancake: The documentation is in the shepherd manual <lfam>butterypancake: You aren't missing anything. It's not yet integrated like in systemd <civodul>rekado: oooh i see, that's because /run/current-system/kernel is now a profile <lfam>butterypancake: We do want to make it more integrated and sophisticated! Help wanted :) There has been discussion on the Guix mailing lists about this subject <rndd>civodul: is it right way to force users update guix channel? <rekado>weâre taking a screenshoot of the grub console and manually type out the long-hash-profile directory in the GRUB boot line <butterypancake>lfam: ok, thanks. There isn't any way to automatically run shepherd? I know I'm going to forget. And I don't want to put it in my profile or anything because I use multiple operating systems <civodul>rekado: the kernel profile thing is from Feb. 18 :-/ <lfam>Systemd is a primary reason I still use Debian for my workstation butterypancake. <civodul>lfam: what do you miss the most from systemd? <butterypancake>civodul: how about it running your services when you log in :P I'm currently missing that <lfam>civodul: Two things: First, fully integrated unprivileged services. For example, they can be configured by the user *or* by the administrator, but even when the administrator sets them up and enables them, they can still be managed without privileges. And second, sophisticated logging <lfam>The first is more important for Guix, I think. <efraim>the full systemd user services are really nice <efraim>and that you can have them start at boot without logging in <lfam>Unprivileged package management, unprivileged service management... a match made in heaven :) <lfam>Yes! Like efraim said. It can be configured in a really sophisticated way <lfam>But, even basic support would be enough to onboard new users... I mean, new developers :) <lfam>Logs are nice to have but not that important on a workstation, IMO <lfam>Systemd unprivileged services are what allowed me to feel like I could really take control of my Debian workstation and ditch macOS completely, back in the day. Before Debian adopted systemd, I didn't feel confident <civodul>lfam: yes, user services sound real nice, though i don't have experience with that (i do like in efraim's post :-)) <rekado>it says device not found (as it used to, because the external storage isnât available), and then it just loops back without any more output *jonsger doesn't know what I would get from user-services when I have root permissions :9 <civodul>rekado: the kernel or initrd says "device not found", or is it GRUB? <civodul>are you trying to boot a pre-Feb 18 generation? <rndd>is it right way to force users update guix channel? <civodul>lfam: it's not the royal "we", for sure, it's actually close to "you" ;-) <nckx>jonsger: Most modern printers (or print servers) don't need any configuration, the rest I've always been able to configure through the regular CUPS GUI (localhost:631). <nckx>rndd: Why would you force that? Sounds like a bad plan. <civodul>rndd: do you want to "force" users of your system to upgrade guix? <nckx>It's trivial for them to circumvent. <jonsger>nckx: ah oke, good hint. Will try that... <rndd>civodul: nckx: no i want to be able to pull from custom channels instead of guix -_- <nckx>So where will the guix come from? <nckx>Your guix is the result of guix pull, not some external thing. <lfam>civodul: I thought so, that's why we haven't done it yet ;) <nckx>If your channel provides a working guix, you can call it 'guix and guix will pull from it. <rndd>nckx: but i have error with wrong ID <jonsger>nckx: so do I need the cups service or the package? <nckx>rndd: I don't understand that, sorry. <lfam>Worse is better as they say <civodul>lfam: perhaps we should start with a spec, like how should it behave etc. <civodul>to what extent should it be connected to Guix, is also a question <nckx>jonsger: You might have to enable the service manually. I'm blissfully unaware of the default. <civodul>like perhaps there's user services on one hand (from a shepherd perspective), and guix-deployed user services on the other hand <efraim>we already have elogind, which provides loginctl enable-linger $USER <nckx>rndd: You can't âpull a channel without guixâ because there won't be a guix command to *do* anything with your channel's packages. <rndd>nckx: this error "guix pull: error: Git error: object not found - no match for id (20f524a44b1a9728045be1198ff795697557796c)" <nckx>Is this the staging snafoo? <nckx>Hm, no, 20f524a44b1a9728045be1198ff795697557796c is on master. <nckx>rndd: Can you share your channels.scm. <rndd>nckx: i renamed my custom channel in "guix" <rndd>nckx: so, i can just create another repo, put there guix source code and i will be able to use it as my guix channel? <emys>Getting `guix substitute: error: connect: No route to host` is a server dodwn? <nckx>rndd: You can use your own Guix fork as guix, yes. I always pull from file:///home/nckx/guix, which is guix + some patches. However, my key is trusted by âmake authenticateâ, I've never tried committing unsigned commits to my local fork. ***ChanServ sets mode: +o nckx
***nckx changes topic to 'GNU Guix | substitute maintenance in progress | get Guix at https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.debian.net | Guix in high-performance computing: https://hpc.guix.info | This channel's logged: http://logs.guix.gnu.org | 1.1.0 is out! https://guix.gnu.org/blog/2020/gnu-guix-1.1.0-released/'
***ChanServ sets mode: -o nckx
<rekado>civodul: we have no pre-feb 18 generations any more. <emys>cbaines, is there a notification channel that I can subscribe to to get maintenance announcements? <emys>I realized its in the channel info <nckx>rndd: You'll also need to use âguix pull --allow-downgradesâ if you like rebasing your channel. That's new. <nckx>emys: no, I put that in there just now thanks to you đ <nckx>We could use info-guix@ for this but we currently don't. <nckx>That would be a good policy. <TZander>Computing Guix derivation for 'x86_64-linux'... \substitute: guix substitute: warning: ci.guix.gnu.org: connection failed: No route to host *nckx makes topic an animated gif with GDPR modal. ***ChanServ sets mode: +o nckx
***nckx changes topic to 'GNU Guix | â ď¸ substitute maintenance in progress â ď¸ | get Guix at https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.debian.net | Guix in high-performance computing: https://hpc.guix.info | This channel's logged: http://logs.guix.gnu.org | 1.1.0 is out! https://guix.gnu.org/blog/2020/gnu-guix-1'
<cbaines>I don't think I check the topic before posting about problems, so I can completly understand people still asking... <nckx>That trims the final URL but that's rather moot at this time. ***ChanServ sets mode: -o nckx
<vagrantcish>i guess it's a good time to build with --no-substitutes and eventually get some "guix challenge" data... *TZander did quickly scan the topic... But I didn't notice it in this 3 lines of text with the 7 brightly colored links in there <rekado>this wasnât supposed to take that long <cbaines>I feel sorry for you rekado :( it's not great having to fight issues like this <nckx>cbaines: The fact this brings down our home page make it hard to effectively communicate this officially. I agree using info-guix@ for this would be good. <nckx>TZander: How about now? đ <nckx>We can't do anything about colours, those are all your client's doing. <cbaines>nckx, well, if I remember correctly, it's the issues around certificates that is the main blocker from hosting the website on multiple machines... maybe I can try and look at that. <civodul>rekado: can you list the contents of /store from GRUB and boot the latest kernel and initrd you find there? <cbaines>nckx, it would be a good step forward if at least the static sites had some hosting redundancy <TZander>cbaines: an nginx front-end to multiple back-end machines is a typical solution <nckx>cbaines: That's not an obvious reason. Why would that be? <nckx>You don't need to share private keys with LE certs. <cbaines>nckx, I think we're using the ACME challenge where it makes a request to the machine, and I'm not sure that would work well if there was multiple machines for the same domain <TZander>cbaines: as substitutes go, I would not mind a system of mirrors that most distros use <nckx>cbaines: Which challenge? <cbaines>TZander, mirrors would be great. The additional churn in Guix substitutes makes it a little more challenging than packages for some other distros, but it's definately possible. The only working strategy I know of that's actually been tried is a caching proxy though, which has some disadvantages for redundancy. <emys>cbaines, info-guix sounds good <rekado>I donât want to do this any more :( <jonsger>half an hour later an I can finally print :P <nckx>cbaines: rekado was working on an rsync proxy before their tragic passing and trip straight to hell. <nckx>cbaines: It's coming đ <nckx>cbaines: I saw knot running on berlin the other day, but it seems we don't self-DNS for g.g.o. I thought we did & could use DNS-01 challenges. Hm. <civodul>i know all too well what it's like to be in such a situation :-/ <TZander>cbaines: archlinux uses a long list and follows the strategy that if the url is 404 on one, it goes to the next host in the list. That strategy may help the churn becoming a problem as your mirrors can update once a day and still be useful (but preferably more often) <rekado>civodul: ah, misread your earlier comment <rekado>yes, Iâm trying to boot an older kernel <rekado>the problem with the newer ones is not only that they are saved as /store/âŚ-profile but also that the contents are symlinks <roptat_>I was thinking, do we fallback to SWH when doing a guix pull and specifying a commit? (same with guix time-machine?) <nckx>TZander: Not great for Guix. Checking every single mirror in turn will make substitute scanning even slower. We should treat 404 as more authoritative than đ¤ˇ, or at least make it configurable. <mbakke>how much disk space does bayfront have? maybe we should set it up as a caching proxy and run it in parallel with berlin <cbaines>I think just through building things <TZander>nckx: the situation where a 404 happens is only for packages that have been compiled in the last ${rsync-interval}, all others will succeed. My guess was that this is still a tiny percentage of downloads. <cbaines>As I mentioned earlier today, I'm intersted in getting it not to build staging and core-updates to see if that saves some space <mbakke>cbaines: I see, nice graphs though :-) <mbakke>there is little benefit in having bayfront build core-updates and staging indeed *mbakke proceeds to the the staging rebase again <cbaines>mbakke, I sent some patches to guix-sysadmin today if you're interested <nckx>TZander: Arch can assume that all well-behaving mirrors âshouldâ have all packages, though. Guix can't. My machines will poll ci.guix for many packages that ci.guix will never build, ever. <nckx>I'm not saying that's a big problem (we'd just have to wait & see) but it's very different from traditional repo-based systems like Arch. <TZander>have to admit, I'll have to trust you on that <nckx>I checked: 63% of my requests to ci.guix return 404s đ I'm not representative. At all. <nckx>Why would I query ci.guix while it's down? <TZander>I think he asks ow you checked the number of 404s <TZander>nckx: maybe good to combine with a change to 'pull' that gets an older revision so stuff has sttled a bit. I mean, its not fun for me to see my 4 years old laptop having to compile something. <TZander>could be a two-flies-in-one thing ;) <TZander>(naturally, devs and core people would still get the latest...) <TZander>me, I always get this warning whenever I use guix.. guix package: warning: Your Guix installation is 7 days old. <rekado>hmm, the old kernel doesnât boot <apteryx>bricewge: I had missed your reply about hwids. They are mostly using Fedora; let me check. <kamil_>On another subject, is git-fetch'es #:recursive? option depreciated? I'll be packaging the second of two dependencies a package I want on Guix needs, and, unfortunately for me, its Github repository uses git submodules, which are fetched build-time using native-inputs git, making it way harder than should be to package this particular library/extension/depedency.. <nckx>TZander: So that's the problem. That warning is there because your missing 7 days of potential CVE fixes. So âadd a delayâ becomes maintain a stable branch to which security fixes are cherry picked, which becomes effort, costing time we already (provably) lack. :-/ Automation & tooling would help a lot. <nckx>kamil_: It's not deprecated but discouraged insofar as it's usually equivalent to using bundled packages. <TZander>7 days of CVE fixes, sorry thats too much hyperbole for me <nckx>(It's literally the motivation for adding that warning though.) <TZander>its throwing the baby out with the bathwater. Or simpler: its avoiding a 'good enough' solution because of a wish to be perfect (surprise, you can't reach perfection) <vagrantcish>that also seems like hyperbole ... it's not like it's forcing you to update <civodul>rekado: yes, so you need to pick a kernel that matches /store/*-linux-libre*/bzImage <TZander>vagrantcish: the point is that 'guix pull' could get a 10 hours old version, which enables a simple mirror system, is most likely not going to happen as perfectionists will state that the only way to do this is "maintain a stable branch to which security fixes are cherry picked". <nckx>You are twisting my words. Don't do that. <TZander>apologies, didn't intent that. this is how I understood it <vagrantcish>TZander: and arbitrary time delay doesn't necessarily even give you any better hit rate with substitutes ... sometimes old substitutes get tossed out <vagrantcish>or an "old" version might have bugs in dependency packages that cause them to fail to build, and then you end up building expensive things to rediscover the bug ... <nckx>TZander: How would you know when a commit was pushed (hint: not, unless you add support to the server to tell you, and at that point we can just add that support to Cuirass instead: hey, what's the newest commit that's fully attempted?). <vagrantcish>not fully understanding the issue, i don't see why the produced objects can't simply be rsync'ed to a directory along with the generated data (.nar? .narinfo?) and served as a static cache which may or may not have all the content <nckx>vagrantcish: They can, that's the plan. <TZander>nckx: why do you need to know when a commit was pushed? <TZander>sounds like you want to do this client side instead of server side. <vagrantcish>because the client is what decides what it needs from the server? <nckx><the point is that 'guix pull' could get a 10 hours old version> requires knowing which commit is 10 hours old, i.e. when it was pushed (that it was committed a week ago on a developer's machine is irrelevant). *nckx was going to say what vagrantcish said. <TZander>For instance, we have a script (I recall seeing that) which shows you the git sha1 that has the best substitute support. So you would not go for exactly 10 hours old, the server just updates the git with the best supporting revision as the builds complete <nckx>TZander: This is also a separate problem with no (AFAICS) overlap with the question of mirrors. That's probably a good thing. <nckx>TZander: Yes. That's what I describe above. <nckx>As an alternative to your time-based approach. <nckx>âŚon the Internet? Can it be? Must be a scam. <civodul>TZander: you can also set GUIX_DISTRO_AGE_WARNING=1m, if you think that's OK for you *nckx runs AFK. (But really o/ ) <TZander>now, your server can do a once every x-hours sync. And it would then just advertise "I'm at git revision N". So I pull, my guix updates to the rev my local mirror is at. <nckx>civodul: Oh, TIL. That's not documented. <TZander>civodul: ah, I'll definitely do that. Thanks <vagrantcish>though how you define what the "best" commit is is a bit tricky ... a large number of trivial-to-build substitutes might be fine to rebuild on the end user's machine, whereas a very small number of large expensive builds would be hard to rebuild <vagrantcish>simply which git revision it's trying to build doesn't tell you what the "best" supported git commit is <vagrantcish>is it expensive disk space? expensive ram? expensive time to build? <TZander>a system doesn't have to be perfect to be useful. And I think this is a time when some worldwide mirror system could be suggested as useful. <TZander>I mean, the baseline is that I have had times when I did an update and then ended up building for 4 hours... <vagrantcish>although it's times like these i decide it's good to just rebuild everything for good measure :) <pkill9>guix publish could record how long it took to build previous revisions <rekado>civodul: I tried booting an old kernel, but I guess the initrd also needs to match *nckx returns to replace them, with pizza. <rekado>with the latest initrd I just got stuck because megaraid_sas had a version mismatch *rekado thanks Madalin for being in the data centre at almost 11pm <nckx>TZander: I honestly think there's a misunderstanding here. Nobody's against mirrors, for reasons of perfection or otherwise. They're just completely separate from delayed/stable/whatever pulling, so we can discuss that separately. That's good. <nckx>TZander: What's keeping mirrors from landing in your neighbours' back yard RIGHT NOW is the permissions on some files, and the fact that berlin is currently on fire. <TZander>cool, I got confused with your message 1 minute past the hour: "Not great for Guix.". @nckx <nckx>TZander: Oh, wow, no, that was only addressing the âdo like Arch, try each mirror in turn on 404â strategy. I think that could be suboptimal is all. <reepca>what about if we tried mirrors in parallel, perhaps with exponential ramp-up? <reepca>e.g. try 1 mirror, if we get a 404 simultaneously try 2 other mirrors, if we get a 404 simultaneously try 4 other mirrors... <apteryx>rekado: wooh :-) Good job keeping your cool while working it! <civodul>rekado: woow, thanks a *lot*, to you and to Madalin <nckx>reepca: Or some kind of âauthoritative not found, stop lookingâ? Thinking it through I'm not sure that can work though. <mbakke>anyone familiar with 'git mergetool'? i have done hundreds of commits, and never tried it ... perhaps I should? :P <nckx>mbakke volunteers to do all tricky merges ever cool. <nckx>mbakke: I have tried to use it but struggled to make it worth the effort. I guess if you're actually familiar with $super_cool_gui_merge_tool it's a life saver, but I reverted back to âlaunch emacs, search for >>>>â under pressure. <mbakke>nckx: yeah, reading further it needs to offload to some third party tool <rekado>booted the old kernel but ⌠it detects 0 network interfaces <rekado>but thatâs not a big deal, I hope. Itâs enough to copy the new kernel to /store and reboot <nckx>Yeah, it's (very) vaguely like âgit bisect runâ. <civodul>rekado: yeah, perhaps the old kernel is trying to load modules from /run/current-system/kernel/, which don't match *nckx adds: âŚand merging non-trivial stuff is always stressful pressure for me :-/ <apteryx>mbakke: yeah, `git mergetool` IIRC just calls whatever tool you configured to launch <rekado>with some luck itâll be back in the next 30 mins <mbakke>I was reading the git-merge manual mainly to see if there were ways to better (automatically) annotate merge commits, but does not seem like it <sirmacik>my luck then, wanna do pull savannah is down, wanna check website, guix.gnu.org down :/ <apteryx>mbakke: have you tried ediff? In Emacs. <mbakke>apteryx: not sure, I use Emacs for all my merges so I guess? <mbakke>I just follow the conflict markers and look for the pretty colors <apteryx>mbakke: if you use Magit your press the 'e' key when presented with a conflict, it'll launch ediff *sirmacik just yesterday discovered that if he wants to add commit message to patch, he has to put it in the second line of commit message <mbakke>apteryx: oh, I don't think I've tried it then :P <sirmacik>then the first one is the subject of send-email <apteryx>then it'll pops its controls in a different window by default, which I don't like, but you can configure it to use the same window with: (setq ediff-window-setup-function 'ediff-setup-windows-plain) in you .emacs <sirmacik>mbakke: btw. thank you for your email this morning! <mbakke>did I send emails this morning? :P <mbakke>it was morning here too indeed, but off-list so I kind of did not register it <rekado>weâre still waiting for the management interface to finish the firmware upgrades <sirmacik>rekado: guix website runs on bare metal? <nckx>sirmacik: It runs on the build farm head node. guix.gnu.org == ci.guix.gnu.org. <sirmacik>mbakke: no problem, at first I was sending my mails as sirmacik too, but then saw everybody uses name and last name so I switched too *nckx wants to buy rekado a drink. <sirmacik>rekado: I know it sometimes doesn't sound like it, but having managed both vpses and baremetals I'm in hardware and own datacenter camp <rekado>Iâm not too happy with the management framework that we must use for these servers. <mbakke>someone suggested recently to add a commit hook that checks the commit message, I think it sounds like a good idea <rekado>I want a simple serial console with SSH access <rekado>apparantly thatâs no longer a thing <mbakke>rekado: what vendor is it? I think both Dell and IBM offer serial access if you know how to poke it. <rekado>itâs a proprietary thing: idrac <rekado>with the expensive idrac you can get serial access, but you still need to jump through hoops <rekado>I have to use the HTML5 serial console after clicking through a bunch of pages and pop-ups <rekado>and then I have to use the on-screen keyboard because shift, ctrl, and alt are swallowed <rekado>everything about this is so very painful <rekado>with my old Sun servers I could just SSH into the management console and that was it <mbakke>yes, those HTML5 terminals are horrifying :/ <rekado>from there I could do everything and start a plain serial console <rekado>who thought this would be a good idea? <rekado>the web interfaces are shiny (in a 2005 kinda way) but they are also really poorly organized <rekado>you *have* to click around to find things over and over again <mbakke>dell has a utility to apply firmware upgrades without having to use iDRAC console, not sure if it's free software though (and the firmware packages surely aren't) <rekado>Iâm now staring at OpenManage Enterprise â so many buzz words <rekado>and I donât know why I need to switch to different pages all the time <rekado>give me a list of firmware updates and a way to queue up their installation <azvede>figured out my problem yesterday was a network connectivity isuse.... does guix-build-webkitgtk-2.28.0.drv-0 normally take 3+ hours to build during a new install of guix system distribution? <rekado>but no: tabs, and buttons, and drop-downs, and meaningless progress bars that are divorced from the actual progress <rekado>azvede: when you build webkitgtk from source it will take a long time <nckx>azvede: It always takes that long to build but no, it wouldn't ânormallyâ build at all. <rekado>azvede: but you should not *have* to build it <azvede>I didn't try to make it build.... I tried to do default OS install <azvede>did I miss an option to say "don't build everything from source?" <nckx>If your network connection is bad it's possible that Guix tried to substitute it (=download a binary), failed, then managed to fetch the sources so you didn't get an error. <nckx>Just a very warm machine. <nckx>In any case, don't retry now, you'll get no binaries at all (server maintenance). <azvede>that makes a load of sense.... I've been having potato network for the last 3 months <mbakke>on a possibly related note, I've been considering hacking Cuirass to populate the publish cache after building a derivation <nckx>guix will grow a â--substitutes-onlyâ flag, it's only a matter of time. <sirmacik>mbakke: unrelated note, is there a way to trigger rebuilding of substitutions on say stumpwm package update? That was the whole reason why I sent patches for those packages <azvede>honestly it's pretty awesome that it could just do that for me <nckx>sirmacik: When updates are pushed to master the builds are queued right away. <sirmacik>no, I mean stumpwm package was updated, but none of its contrib tools <nckx>azvede: Guix mostly works, and when it does it's transparent magic. <sirmacik>and they just won't work if not compilled with updated sbcl/stumpwm <nckx>sirmacik: I'm afraid I don't understand the question then. <mbakke>sirmacik: anything that depends on package A will necessarily get rebuilt if package A changes <azvede>nckx, no kidding, "couldn't grab your packages, don't mind me while I build them for you" is some absolute flipping magic <sirmacik>nckx: hm. I can see that when there is some sbcl update, stumpwm package gets updated too. But there are some other packages with addons/tools for it and they didn;t get that update, but should <roptat_>sirmacik, so they don't depend on sumpwm when they should? *sirmacik checks the source <nckx>As mbakke said, if they depend on stumpwm they will be automatically rebuilt. It's impossible that they aren't. If they don't depend on stumpwm, well, then they shouldn't be rebuilt and all is fine đ Circular, but still logic. ***roptat_ is now known as roptat
<nckx>Then they must be rebuilt; hard âmustâ. <mbakke>sirmacik: then they would have been rebuilt (guix enforces that); maybe you just forgot to update them locally? <sirmacik>so should get an update on reconfigure as well <sirmacik>but after restartung stump I got an error <mbakke>sirmacik: do you have stumpwm in the configure.scm too? <sirmacik>recently heard from Pierre that's not preferred way but I don't really like manifest files <mbakke>then restarting stumpwm must have re-used the old store items somehow <sirmacik>I'll pay closer attention ion next sbcl/stumpwm update <nckx>sirmacik: The way you describe it (ârebuilt addon package and it workedââhow?) it sounds like you might be mixing packages from your system profile (configure.scm) and user profile (guix install, guix upgrade, guix package -foo). Is that possible? <nckx>As in: does âguix package -I <regex or just .>â list them? <nckx>The regex is probably optional but never mind. <sirmacik>I had a leftover from working on sbcl-pass patch <mbakke>sirmacik: no worries, glad you found the issue :) <nckx>sirmacik: Don't be. You learned something. <nckx>Guix is software and therefore buggy, but unlike other stateful package managers it's built in a way that it can't âforgetâ or âmissâ or âsuddenly rememberâ things. <nckx>sirmacik: If it seems like it is, look again. It's probably you đ But that's good: it means you won't be chasing ghosts. <nckx>We don't pay either of you enough. <civodul>i'd offer you beverages next time we meet but that might be a long time from now :-/ <cbaines>in the mean time though, we can probably do some work on making it less risky to reboot berlin <cbaines>especially making things like serving the website and maybe substitutes less dependent on a single machine <civodul>i think i fixed the kernel/initrd copy stuff <civodul>we should prolly reconfigure while we're at it <civodul>so that next time it's hopefully less bumpy <rekado>I already copied the current kernel to /store <rekado>thereâs still another bump, though <rekado>grub.cfg contains a âsearch --fs-uuidâ line <rekado>the uuid it looks for is the uuid of the external storage <rekado>which doesnât exist before the kernel boots <rekado>thatâs why we get this âdevice not foundâ error <rekado>itâs not fatal, but someone has to âpress any key to continueâ <rekado>and thatâs a little inconvenient <civodul>and you have to manually set the root device, no? <rekado>it just works when I press a key <civodul>perhaps a mechanical device could help?... <rekado>if we could replace it with just âsearch --set --label my-rootâ that would not be necessary <rekado>because the kernel and initrd are both on the root disk already <rekado>so⌠the NIC firmware upgrade didnât do anything for us <rekado>good news is that one of the new build servers is not afflicted with this disease <rekado>so my uneducated guess is that the network card on ci.guix.gnu.org is broken <marusich>Does anyone know why we aren't using Guile 3.0 as the bootstrap guile? I see that in gnu/packages/make-bootstrap.scm, we now have %guile-3.0-static-stripped in addition to %guile-static-stripped (which is Guile 2), and they seem very similar. <sneek>marusich, you have 3 messages! <sneek>marusich, dftxbs3e says: yes I think it used to build at that point <sneek>marusich, dftxbs3e says: also there's a netdata instance on the POWER9 VM I gave you access to, you can reach it by redirecting the 19999 port to your local machine. It allows you to monitor the resource usage of the machine during builds <rekado>the network team says they saw lots of out-of-order packets on that switch port <rekado>and this could lead to automatic speed reduction <rekado>so, next step is to deploy the berlin configuration to one of the new build nodes <rekado>weâll need to migrate the HBA cards, so thereâll be downtime unless we find spares <nckx>Are these machines otherwise the same? <rekado>I want to do this ASAP, before the end of this week <TZander>on doing a 'guix pull' I see both 'guix-system' and 'guix-cli' being built. Is the 'guix-system' actually relevant for someone that runs guix on top of a host machine? <rekado>nckx: no, berlin is quite a few years older <rekado>nckx: they are so different that I couldnât even just take the 10G NIC from the new server and pop it into berlin. <nckx>rekado: You're as bad as me at sleeping. Thanks for answering! <leoprikler>probably not, but you might want to be able to make disk images <reepca>TZander: 'guix system reconfigure' isn't useful, but most of the other subcommands are. <reepca>I got the system I'm running on by plugging in a second hard drive and running 'guix system init' straight from ubuntu <rekado>so itâs easier to just use the new server <nckx>Oh, VMs exist, I always forget. <rekado>berlin would still make a good build node <apteryx>rekado: thanks again for troubleshooting this! good night <nckx>â was for TZander but applies to berlin equally. 