IRC channel logs

2020-07-17.log

back to list of logs

<nckx>I can't find a Nix example in that linked DPL thingy. 🤷
<NieDzejkob>I think they misunderstood and thought Guix is a package registry like PyPI or crates.io
<bonz060>apteryx: I see they've moved all their conversations to their community plafform :(
<bonz060>NieDzejkob: a lot of people don't know what guix is. Having a CI that supports it would be a nice step.
<bonz060>I'll try to reach out to the travis team via e-mail and see how that goes
<bonz060> https://travis-ci.community/c/languages/nix/48 <-- It's at the header
<roptat>bdju, fixed! you can run "guix pull" and enjoy your icons :)
*nckx visits GitHub: ‘You contributed code to the 2020 GitHub Archive Program and now have a badge for it. Thank you for being part of the program!’
<nckx>It seems NixOS is going into some vault.
<nckx>No news about guix-mirror.
<bdju>roptat: nice!!! looks great. thank you for your hard work.
***nckx is now known as guix
***guix is now known as nckx
<mroh>impressive work on and with ganeti! ty mbakke!
<mbakke>mroh: thanks, are you familiar with it?
<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?
<wdkrnls>(for packages)
<mbakke>wdkrnls: I don't think there is an official policy, but I think in practice GC roots stay valid for 1-2 releases
<mbakke>Guix releases, so 6-12 months
<wdkrnls>thanks :) I was curious if maybe a `guix gc` was being run pretty frequently to keep hard disk space reasonable.
<wdkrnls>Mostly, I'm due for a `guix pull` having not run one for two weeks, but just downloaded gthumb and noticed I had to compile. So, it made me curious.
<mbakke>right, occasionally the CI fails to build something, then it won't retry until the next time the package or any dependency changes :/
<raghavgururajan>Hello Guix!
<raghavgururajan>I get this error during build. error: ‘invoke’ is not a member of ‘std’
<raghavgururajan> https://disroot.org/upload/EfMM_1diLWltQ-WS/cairomm.diff
<nckx>mbakke: Does the CI GC care about age though? I thought it just booted random store items until space was made.
<raghavgururajan>That diff is to be applied on top of https://git.disroot.org/raghavgururajan/guix-wip-desktop.git
<wdkrnls>ah, so adding some kind of exponential backoff feature might eventually be of value to add - especially for underpowered devices such as e.g. Librem 5 phones using Guix.
<nckx>raghavgururajan: Try using a newer GCC (native-inputs `(… ("gcc" ,gcc-10))) and adding -std=c++17 to CFLAGS.
<mbakke>nckx: no, I think the friendly CI admins just run 'find /var/guix/gcroots/auto -mtime N -delete' every now and then
<nckx>gcc@10 is probably overkill but should work. So should 8 or 9
<mbakke>that reminds me, I wonder how NieDzejkob GCC9 work went
<nckx>mbakke: Oh, it's run by helpful gnomes, OK.
*nckx leaves out tasty snacks for the gnomes.
<raghavgururajan>nckx: Thanks!
<nckx>If that still doesn't work try -std=c++1z instead. I don't keep up with all the C++ stuff.
<nckx>Life's too short.
<nckx>Actually, the build system should set -std= for you if GCC is new enough, so just try a newer GCC first.
<nckx>raghavgururajan: ☝
<raghavgururajan>nckx: That's exactly I did. I wanted to see if work without the CFLAG.
<raghavgururajan>Shoot! it started to gcc-10.
<raghavgururajan>bayfront to the rescue.
<raghavgururajan>*started to build
<nckx>Heh. Maybe try a slightly older one.
<raghavgururajan>nckx: 7, 8 and 9 did not work.
<raghavgururajan>How do I build gcc-10? guix build gcc@10.1 not working.
<nckx>I guess it's a dependency of gcc-toolchain@10.
<nckx>So building that should build what you want.
<raghavgururajan>Cool!
***terpri_ is now known as terpri
<nckx>But if 9 doesn't work I'm not too hopeful. Sounds more like a missing -std= flag after all. I've got to go, be back in ~half an hour.
<raghavgururajan>nckx: It worked with gcc-7 with "CXXFLAGS=-std=c++17"
<raghavgururajan>Also didn't need the gcc-7 native input. Just the flag works.
<nckx>That's great to hear.
<mroh>wow, maven-build-system! also impressive work!
<mroh>current master fails to compile guix-extra: http://paste.debian.net/1156742
<mroh>in `guix pull`
<nckx>roptat: ☝
<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 is now known as Guest94585
***apteryx_ is now known as apteryx
***terpri__ is now known as terpri
<jeko>Hello Guixters !
<jeko>I can't pull :'(
<jeko>$ bzcat /var/log/guix/drvs/4y/42zgxq6abq8mg4rbx9l9lylkkn5b2v-guix-extra.drv.bz2
<jeko>[...]
<jeko>no code for module (gnu packages maven)
<cbaines>I noticed that too, I think I know what's going wrong...
<efraim>C.UTF-8 on debian is created specially by them
<cbaines>I think I've got a fix, but now I have the hard part of writing the changelog entries for the commit message...
<jeko>erk
<jeko>how bad is it?
<cbaines>I've pushed a fix now, hopefully it'll work
<NieDzejkob>efraim: I began suspecting that too, do you have a link to the source for that?
<NieDzejkob>eh, I'll just link to https://github.com/commercialhaskell/stack/issues/856
<jeko>cbaines: cool!
<efraim>NieDzejkob: https://sources.debian.org/src/glibc/2.31-1/debian/patches/localedata/locale-C.diff/
<jeko>cbaines: it does work !!!
<NieDzejkob>efraim: thanks!
***dongcarl7 is now known as dongcarl
<rekado_>hji: minified JavaScript should be removed and minified from source.
<rekado_>hji: that’s what I’m doing in all R packages that bundle JavaScript.
<roptat>Oops, what did I do?
<zap>Hello Guix!
<mbakke>sap zap
<mbakke>roptat: 'guix pull' broke, but cbaines fixed it :-)
<zap>sap mbakke :)
<zap>anyone knows how the store item "validity" is evaluated by 'valid-path?'? I'm getting store-protocol-errors even when I pass to it items that are in my profile.
<nckx>hji: Which Guix packages were those?
<zap>I've tried to bootstrap bash in new environment and ran (valid-path? %store (string-append (package-output %store bash) "/bin/bash")) but still not getting #t. Is it expected behaviour?
***danjelalura94 is now known as danjeladd
<NieDzejkob>zap: it might be asserting that the /bin/bash part isn't there
<zap>NieDzejkob: the thing is that I got the directory with 'ls -l `which bash`' so it is definetly there. valid-path? seems to work with items that I've just created with add-text-to-store though.
<nckx>zap: The docstring says it accepts store items. Try without "/bin/bash".
<nckx>I think that's because add-text-to-store does create a top-level /gnu/store/<item>.
<zap>nckx: NieDzejkob: yes it worked thanks! I thought I allready tried it. Apparenly it was a `danglind-quote-sexp-selection-typo'
<efraim>does anyone have simplescreenrecorder working? I'm having trouble getting it to record my audio
<NieDzejkob>Hmm, I usually use OBS Studio for this
<efraim>that was my first plan, but I can't run OBS on my computer
<efraim>I suspect it's an opengl issue
<jboy>is ludovic still developing the guix jupyter kernel? it appears to be broken currently.
<jboy>and there haven't been public commits in 6 months...
<NieDzejkob>sneek: later tell civodul: jboy asks: is ludovic still developing the guix jupyter kernel? it appears to be broken currently.
<sneek>Okay.
<jboy>děkuju
<mbakke>prosit
<KE0VVT>Guix doesn't seem to provide the "ffprobe" package. youtube-dl: ERROR: ffprobe/avprobe and ffmpeg/avconv not found. Please install one.
<roptat>KE0VVT, isn't that provided by ffmpeg?
<nckx>It is.
<KE0VVT>roptat: You're right. The command worked after installing ffmpeg. Thanks!
*NieDzejkob attempts to patch in the ffmpeg path into youtube-dl
<efraim>We discussed it in the past, ffmpeg is quite wanted but too heavy to patch in
*NieDzejkob runs 'guix size ffmpeg'
<NieDzejkob>wow
<apteryx>efraim: wouldn't youtube-dl be near useless without ffmpeg? (I don't use it, so I don't know :-)
<roptat>it only needs ffmpeg when it couldn't download a video that has both sound and video and it instead download both separately and needs to merge them
<rekado_>woo, mcclim!
<rekado_>thanks, Guillaume!
*rekado_ throws away own WIP mcclim.scm :)
<NieDzejkob>roptat: also when you ask for just the audio and it has to split it out of the merged file served by youtube
<apteryx>It seems to me that both sides could be argued for (patching ffmpeg in vs not). I guess this means status quo :-).
<apteryx>are there connectivity related differences between a 'guix environment --container' and the container used by 'guix build'?
<apteryx>Where (in the code) can I inspect how that 'guix build' container is set up?
<apteryx>is it on the daemon side?
<apteryx>because in a guix environment -C, there are no IP addresses configured, but apparently in the guix build container there's one (perhaps 127.0.0.1?)
<apteryx>ah, found it: writeFile(chrootRootDir + "/etc/hosts", "127.0.0.1 localhost\n");
<apteryx>under nix/libstore/build.cc
<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
<bdju>thank you for the suggestion anyway
<apteryx>mbakke: interesting work on ganeti! Seems it was a multiarmed beast to tame.
<apteryx>interesting & impressive :-)
<lfam>Is it possible to compose time-machine and copy? Something like `guix time-machine --commit=cabbage syncthing -- copy --to=lfam@server`
<lfam>It fails with "guix copy: error: failed to connect to `#<input-output: channel (open) 7f4def848c20>': Protocol error"
<mbakke>lfam: I use guix copy $(guix build foo) a lot
<mbakke>apteryx: thanks! :)
<lfam>The copy does work outside of time-machine, but I want to be working from a specific Guix revision
<mbakke>even though I have years of experience with Ganeti, it was still a huge challenge, stateless deployment is clearly a very alien environment for it..
<apteryx>sneek: later tell zimoun wow! that's a lot of interactions to account for
<sneek>Got it.
<apteryx>sneek later tell zimoun I'm glad it's reproducible to others at least!
<sneek>Will do.
<apteryx>mbakke: It seems the outcome of this challenge was a positive fallback of patches being contributed back into their upstreams, so that's very neat :-)
<apteryx>s/fallback/fallout/
<lfam>If I do `guix copy /gnu/store/...-syncthing --to=leo@server`, it still fails with that protocol error
<lfam>"guix copy: error: failed to connect to `#<input-output: channel (open) 7f2aa23f7c00>': Protocol error"
<lfam>It works when I do `guix copy syncthing --to=leo@server`
<lfam>I'm going to try composing time-machine and archive
<mbakke>apteryx: I'm just building up enough street creds to submit that far-reaching 'disable-version-symlinks.patch' :P
<apteryx>hehe ;-)
<alextee[m]>question for maintainers: is this an acceptable trademark policy for software included in guix? https://www.zrythm.org/en/trademarks.html
<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
<lfam>Hmph
<apteryx>you have to put the vars in ~/.bashrc and pay attention to what I wrote above.
<lfam>Yes, I understand that issue
<lfam>I'm also struggling with `guix archive` on its own. I thought I had set up the signing key situation correctly but the receiving end is still trying to build the things I copied over
<lfam>I generated the key, added it to acl on the remote, restarted the guix-daemons on both sides, and then generated the archive
<lfam>But the receiving side still wants to build the thing
<apteryx>alextee[m]: sorry, I'm not following. Could you please try to explain your idea differently?
<apteryx>lfam: OK :-(. I seem to recall having a similar experience, with no solution on memory.
<lfam>I'll keep debugging
<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]>apteryx: yeah, im the trademark owner :-)
<alextee[m]>and i want my software to be freely included in free software distros, as long as there's no change to the core functionalities, then i would prefer renaming and replacing the logo
<apteryx>perhaps add the "substitantial' qualificafier to those modifications.
<apteryx>and give an example that common minor modifications done for packaging purpose fall into the acceptable category of modifications.
<apteryx>substantial*
<alextee[m]>im wondering if there are legal interpretations of "substantial" and "packaging purposes"
<alextee[m]>but that sounds like a good start, thanks
<alextee[m]>i would have to be super specific i guess
<mbakke>lfam: wrt guix archive, did you use '--no-grafts' on the exported item?
<lfam>No mbakke
<lfam>I made it work with `guix archive -r --export hello`
<lfam>But I'm struggling to make it work with syncthing
<mbakke>lfam: then the receiving end needs to build the ungrafted prerequisites
<mbakke>lfam: yes, that's because hello has no grafts :)
<apteryx>alextee[m]: by the way, Zrythm looks like a neat music software! Congrats. Does it compete in the same space with Ardour?
<apteryx>mbakke: ah! tricked by grafts once more :-)
<alextee[m]>apteryx: thanks! yeah, although it focuses more on electronic music and MIDI rather than recording and editing audio
<apteryx>OK :-)
<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.
<apteryx>hmm. lots of bundled stuff with ruby
<mbakke>alextee: on an unrelated note, 'staging' needs a newer version of libcyaml, which means we need a newer version of zrythm, hint hint :-)
<mbakke>apteryx: oh? I did some ruby packaging recently and did not notice
<lfam>I noticed an inconsistency in Guix command composition when using time-machine
<lfam>guix time-machine --commit=03f9a8c35be387f37badcd2c830ac7414ac17225 -- environment --no-grafts ffmpeg -- guix build --no-grafts ffmpeg --no-substitutes -d
<lfam>guix time-machine --commit=03f9a8c35be387f37badcd2c830ac7414ac17225 -- build --no-grafts ffmpeg --no-substitutes -d
<lfam>Those commands give different derivations
<lfam>Normally, they would be the same
<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
<mbakke>oh I see, clever
<lfam>Or, in this case, debugging nar signing
<lfam>Usually Guix composes well on the command line, so this issue surprised me
<lfam>Well, I guess it's why time-machine requires you to leave out the actual `guix` command, and that does not work for my example
<NieDzejkob>alextee[m]: any trademark policy hostile to modification is gonna have a hard time getting included in guix
<mbakke>ref IceCat and IceDove
<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]>^
<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?
<alextee[m]>NieDzejkob: yes, s intentional :-)
<alextee[m]>the misspelling*
<alextee[m]>because it "looks cooler"
<lfam>It's really a case where if you don't get sued, then it was okay
<lfam>We packages lots of things with trademarks but the trademark owner does not take action
<lfam>I was able to copy and import store items successfully with ffmpeg, but it still fails for syncthing
<lfam>I wonder if only works for packages with a single output
<jonsger>what package does provide "l3regex.sty"? do we have l3regex already?
<roptat>jonsger, sounds like a texlive thing?
<jonsger>roptat: yeah, but I don't know which package does provide it
<roptat>no idea, but I'm running find on my build server, let's see if it built it
<jonsger>btw I'm starting to review your php stuff roptat, as far as I can :)
<roptat>cool, thanks!
<roptat>the closest match seems to be texlive-latex-l3kernel, but it doesn't contain l3regex
<roptat>fedora seems to provide it in texlive-l3experimental
<roptat>opensuse does it in texlive-l3kernel
<jonsger>roptat: how do you find that out? with rpm -q on a running system/container?
<roptat> https://pkgs.org/download/tex(l3regex.sty)
<roptat>also, https://www.ctan.org/pkg/l3regex says l3regex is supposed to be in l3kernel
<roptat>yes, there's a l3regex.dtx in l3kernel's sources
<roptat>but I don't know latex enough to understand why it's not built into a sty file
<jonsger>me neither :(
<NieDzejkob>latex is two layers of black magic at once :/
<jonsger>maybe updating latex can help, but I have no idea...
***dingenskirchen1 is now known as dingenskirchen
<dadinn>hi all
*vagrantcish waves
<dadinn>is there a release file in Guix, which I could use in a script to verify what distribution I am in? Something similar to /etc/os-release
<vagrantcish>not out of the box ... some people have made configurations to make one
<dadinn>... or /etc/debian_version
<dadinn>maybe /etc/configuration ?
<dadinn>I mean, is it the case that it always has to be /etc/configuration ?
***jonsger1 is now known as jonsger
<NieDzejkob>I think you can count on /gnu/store existing iff you're on Guix
<dadinn>NieDzejkob: actually /gnu/store sounds good!
<vagrantcish>well, /gnu/store also exists on foreign distros with guix installed...
<dadinn>vagrantcish: fair enough
<vagrantcish>depends on what you need it for :)