<mroh>No, didnt know that software before. looks like a stripped down openstack
<mbakke>they are quite different in practice :-) whereas Openstack falls over if you look at it wrong, Ganeti never really fails :P
<mbakke>I've run both "in production" and would not recommend Openstack to anyone...
<mbakke>the declarative OS variants of Ganeti are really neat, you can create tailor-made variants that get built from scratch with an up-to-date Debian, while Openstack requires use of pre-defined images and really an extra layer of Puppet/Salt/Ansible on top to configure and update the thing
<mbakke>additionally Ganeti can conveniently install and configure Puppet etc with a hook in the installation process
<mbakke>Ganeti is typically used where people have VMware or Hyper-V, as a sort of infrastructure foundation
<wdkrnls>I was curious if there was a policy on the length of time for which binaries are available? Is it for a week?
<apteryx>fun. build in the open: no failure. build in a pure environment: no failure. build in a containerized environment: lots of failures. build in the normal guix builder container: a few failures.
*apteryx is trying to make sense of the build failures encountered on ruby-asciidoctor-pdf
<passt_>Hello. On my machine the "guix system reconfigure" command can no longer find the "activate-service.scm" derivation in the store. Booting into an older generation and changing the system.scm did not solve the issue. The issue happened after a kernel panic during a system reconfigure however I have a hunch that it's not too relevant. Any guidance/similar experiences?
<passt_>Fixed. Pulling a commit of guix before the Maven build issues, switching to a working profile generation, reinstalling the "guix" package, in that order worked.
<NieDzejkob>mbakke: I decided that it'll be easier after #42146
<NieDzejkob>any idea why 'export LC_ALL=C.UTF-8' errors out with "-bash: warning: setlocale: LC_ALL: cannot change locale (C.UTF-8): No such file or directory"? It works on debian...
<apteryx>that's why it works in the guix build container but not in the 'guix environment' one.
<NieDzejkob>how are you checking for configured IP addresses? /etc/hosts is for DNS stuff
<apteryx>it's a ruby program, doing: Socket.ip_address_list
<apteryx>it returns an empty list in the guix environment (). And it fails trying to access the first element and accessing a property of this non-existing element.
<apteryx>but yeah, just writing that /etc/hosts file is not enough
<apteryx>in DerivationGoal::runChild, there's code that initializes the loopback interface
<apteryx>I guess the laziest approach to get something similar is to pass the --network option to guix environment, while disconnecting my internet ;-)
<apteryx>interesting. The test failures only happen inside the 'guix build' container.
<bdju>two icecat crashes today! not good. I think both may be related to pasting text
<bdju>I've lost some typed text both times so I'm starting to get annoyed... anyone else having issues?
<NieDzejkob>pasting things in icecat in those rich textboxes websites use has been broken in many unique ways for a while now for me
<bdju>last crash was middle-click pasting some copied text into the riot web chat box, first crash today was ctrl-v pasting a url into a new private browsing window
<apteryx>bdju: perhaps you are running out of ram?
<zimoun>apteryx: I did some tests about bug#42371. It seems a race condition, depending on --cores, --max-jobs, your number of processors and the number of guixbuilder users. And it depends too on --quiet or not.
<apteryx>that's my experience of running riot in the browser
<bdju>apteryx: surely not, I keep htop showing on another monitor and I have 16GB of RAM anyway
<apteryx>it sounds like you'd have to request consent fom the trademark owner as written at the bottom of this page, as changing the sources at least minimally is routine in Guix packaging.
<apteryx>or if you prefer to be safe rebrand it, but that's sounds like more work
<lfam>I guess there are some issues regarding SSH environments and `guix copy`. It fails completely when copying to Debian but fails later when copying to Guix System. I suspect the remote shell doesn't find Guix because it's not a login shell
<alextee[m]>is there any way it could be reworded to make it compatible with guix packaging, but at the same time require consent if any actual functionalities are changed? apteryx:
<lfam>Copying to Guix System fails with 'guix copy: error: unknown error while sending files over SSH', which is unfortunate, but not my goal ATM
<apteryx>lfam: right, there's a bit of shell script exiting early from .bashrc on Debian/Ubuntu IIRC, which may trick you if you defined environment variables there to find Guix.
<apteryx>(exiting early in the case the shell is not interactive)
<lfam>I define those variables in ~/.profile or ~/.bash_profile, since they should normally be defined for login shells, but I remember that non-interactive SSH shells are different
<alextee[m]>apteryx: you said that that trademark policy wont be compatible with guix if guix were to modify some source files. i'm looking for some wording that would allow distros to modify source files for minor things without infringing the trademark, so i can include that in the trademark policy, if you can suggest something
<apteryx>oh, I see, you want to suggest a change of policy to the trademark owner, so that their software can be more freely/simply included in free software distros.
<alextee[m]>but anyway, for guix there are no patches needed for the source code since i maintain the package, so I guess it's fine. only build flags are passed
<lfam>I think there's more problems than just the grafts
<lfam>`guix describe` on the receiving end show commit 03f9a8c35be387f37badcd2c830ac7414ac17225. No channels or anything that would affect Syncthing
<lfam>On the sender, I do `guix time-machine --commit=03f9a8c35be387f37badcd2c830ac7414ac17225 -- archive --no-grafts -r --export syncthing > ~/tmp/syncthing.nar`
<lfam>I copy that over and import it, but the receiver still decides to build Syncthing
<lfam>I'm curious, how does the generate-key stuff work? When I generate the new signing key, does that machine automatically start signing things with it? Or do I need to do something like restart the guix-daemon?
<lfam>Well, I restarted the guix-daemons on both sides after generating the key and authorizing it, respectively
<lfam>I'm going to try with a single-output package.
<lfam>I'm guessing that, in the former, the `guix build` command escapes from the time machine
<lfam>This `guix environment -- guix build --no-substitutes` is something I use for debugging
<alextee[m]><mbakke "alextee: on an unrelated note, '"> yes i actually already have the patch ready, but im waiting to release a new zrythm version because the old one is incompatible with the new libcyaml!
<mbakke>alextee: ha, awesome :-) it will take a few weeks before staging is ready to merge, so no hurries
<mbakke>lfam: I'm curious, why do you run 'guix build' inside an empty 'guix environment'?
<lfam>mbakke: Sorry, I was writing shorthand. That's not the actual invocation
<lfam>I shared the full command lines a couple minutes earlier
<mbakke>ah, still, why do you run 'guix build ffmpeg' in 'guix environment ffmpeg'? :-)
<lfam>Here is an example outside of time-machine: `guix environment --no-grafts ffmpeg -- guix build --no-grafts --no-substitutes ffmpge`
<lfam>I want substitutes for dependencies but I need to build ffmpeg locally, for example
<lfam>When debugging machine-specific build failures, for example
<alextee[m]>NieDzejkob: what would a better trademark policy be then? also does FSDG not allow trademarked logos/names? these things are covered by trademark law automatically in some countries too, so if you fork a project you pretty much need to change its name
<alextee[m]> As long as the practical requirements are reasonable, however, free system distributions may include these programs, either with or without the trademarks.
<alextee[m]>so as long as there's an easy way to produce a version that doesn't include the trademarks (a build switch for example) it sounds like FSDG is OK with having packages that include trademarks if they allow use of them for redistribution (but not modification)
<NieDzejkob>btw, are you aware that rhythm is usually spelled with an extra h?