IRC channel logs


back to list of logs

<civodul>janneke: i miss some context, but tomorrow we can take a look!
<apteryx>nckx: the error was due to a 'jenkin-build' subvolume name instead of 'jenkins-buildS' in my file system declaration...
<nckx>apteryx: …
<nckx>You are all of us at some point.
<apteryx>I did find some strange things though... reconfiguring on very close configs, it seemed like the system generation didn't change; sometimes reconfiguring upon a working version of my config magically "enabled" a previous one which shouldn't have worked. It was all very confusing and I don't still understand what exactly was happening.
<Blackbeard>My school finally sent my proof of enrollment
<Blackbeard>I was really worried they wouldn't send it
<Blackbeard>Because of coronavirus they are working less
<Veera>civodul: make authenticate is complainig about this key B943509D633E80DD27FC4EED634A8DFFD3F631DF
<Blackbeard>This weekend is basically the last and after that almost 95% of my time will be for guix
<Blackbeard>I will still have a bit of school but very little
<Veera>civodul: which is not present in civodul-key.gpg
<Blackbeard>That's why I've been a bit silent this week
<lfam>Veera: That key should be here:
<lfam>Veera: Do you need help finding these keys yourself?
<Veera>lfam: I can do that
<nckx>Blackbeard: That is most excellent news.
<nckx>So our rsync uses a bundled copy of zlib for compatibility with 2014.
<nckx>So I'm gonna disable that.
<nckx>So yeah.
<nckx>‘Heads up.’
<Veera>lfam: thanks. I think I should get all keys for all guix project members.
<lfam>nckx: Urgh
<nckx>Isn't that the point of the keyring? Shouldn't we just add Hartmut's key?
<Blackbeard>nckx: yes :)
<lfam>nckx: It is in the keyring
<nckx>…civodul recommended importing ~/.config/guix/keyrings/channels/guix.kbx hours ago…
<lfam>Well, it's in 'build-aux/git-authenticate.scm'. I'm not sure how the keyring is built
<nckx>Not that that exists, but it *looks* relevant and that's what counts.
<nckx>You & me both, fam.
<Veera>eh: now this key is not there F556FD94FB8F8B8779E36832CBD0CD5138C19AFC
<Veera>I downloaded all keys of all guix project members
<lfam>What commit Veera?
<Veera>commits are d68de95 to 9ae3e79
<lfam>Veera: That key was added only a couple days ago
<Veera>lfam: how to get it
<Veera>lfam: make authenticate is not proceeding without it
<lfam>It's on roelj's savannah page
<lfam>Veera: For every missing key, look it up on 'build-aux/git-authenticate.scm'. Then go to savannah and get it from that user's page
<Veera>lfam: got the key
<Veera>lfam: okay I will do that
<Veera>lfam: thanks
<lfam>Okay :)
<jonsger>lfam: you already have AV1 videos to play?
<lfam>jonsger: There are some good samples here:
<lfam>And streaming sites are beginning to use it
<jonsger>but I guess they wont work with Icecat
<lfam>My goal is have rav1e in Guix before FFmpeg 4.3 comes out. Not sure when that will be...
<lfam>I'm also excited for the AVIF still format. It's wildly better than JPEG
<lfam>Finally we are shedding the first generation of perceptual compression codecs
<lfam>Already replaced MP3 with opus
<jonsger>yeah I'm also exited but I wait for hardware with AV1 support
<lfam>Yeah, that will be the true watershed
<lfam>Netflix on the phone
<lfam>Incredible image quality with poor latency and bandwidth
<lfam>And big improvements to live streaming too
<lfam>Even broadcast TV will improve a lot
<jonsger>slightly different topic: Firefox 76 will be enable VA-API
<nckx>Support for my 2012 ThinkPad.
<jonsger>I first need to switch to wayland
<KE0VVT>On one hand, I like Wayland compositors a lot. On the other hand, I kinda want to run CDE.
<Veera>lfam: got success with make authenticate
<Veera>lfam: thanks again
<lfam>Great :)
***wxie1 is now known as wxie
<apteryx>bricewge: eh, thanks for following up on that eudev issue!
<apteryx>bricewge: also, I think I recall you had an interest in root on a Btrfs subvolume; if that's the case still, I've tested the latest patches here quite extensively and it works well!
<apteryx>rekado: the latest MUMI looks really nice! Thanks for putting it together!
<apteryx>you only need to get the subvolume name right in your config, unless you want to waste a couple hours like I did today ;-)
<nckx>Oh hey mumi loads in bounded time now.
<nckx>What wizardry is this.
<apteryx>feels great!
*apteryx wonders what hack has the best value for this late Friday night... elpy vs make checksuming the files when their mtime differs before GUILEC'ing them.
<nckx>‘elpy’ is mysteriously vague.
*apteryx comtemplates option 2 as the source tree slowly gets rebuilt after checking out a branch
<nckx>apteryx: Fine by me! Yes plz.
<apteryx>yes. It's broken on master.
<nckx>Welp, I've never used or heard of it so there's my totes unbiased preference.
<apteryx>It's the best thing I know of for doing Python in Emacs
***amfl_ is now known as amfl
***wxie1 is now known as wxie
<lfam>nckx: I'm curious, did rsync's bundled zlib offer better compression?
<nckx>lfam: Yes, but it was 1. marginal 2. itself deprecated. See man rsync.
<nckx>This is not going to break anybody's bandwidth.
<lfam>I was just curious
<nckx>Curious is good.
<lfam>That man page section '-z, --compress' is a master class in confusing documentation
<nckx>Yes, I agreed 😃
<nckx>I was going to paraphrase it in the commit message but gave up.
<lfam>It's already like a 10th level paraphrase of what is really going on
<lfam>A game of telephone
<nckx>My commit message? Oh. I just wanted to communicate 1. this commit gud thing 2. if you disagree: reconsider.
<nckx>The 2 is always implied but it's nice to restate it sometimes.
<nckx> ???
<nckx>Is this normal?
<nckx>On my laptop it returns the FQDN in /etc/hostname.
<nckx>On this server it does not.
<nckx>Hm, apparently ‘hostname --fqdn’ (and only hostname --fqdn) takes the leftmost name from /etc/hosts.
<nckx> This is entirely reasonable and acceptable behaviour ♫
<nckx>Custom hosts record on all machines it is, then. Sigh.
<lfam>nckx: Not your commit message, the man page quotation
***wxie1 is now known as wxie
<nckx>It has that ‘expanded by several people over several years & never rewritten’ feel.
***wxie1 is now known as wxie
<marmulak>guys how is it possible that ungoogled-chromium is 322.6MiB
<brendyyn>no idea. on Arch, Ungoogled-chromium is 186MiB
***chipb_ is now known as chipb
<lfam>That's a good thing to work on
<midnight>That sounds good. "Ungoogled." Just.. like in general.
<brendyyn>chromium wayland segfauled 5 seconds after i opend it ;(
<Veera>I am running sudo ls /root and it is not working
<Veera>su - root is doing fine
<brendyyn>describe "not working"
<Veera>I want to do sudo -E ./pre-inst-env guix-daemon --build-users-group=guixbuild
<Veera>when I enter root passwd it says sorry please try again
<Veera>same with sudo ls /root
<brendyyn>sudo requires your password doesnt it? not the root one
***wxie1 is now known as wxie
<Veera>sudo -E ./pre-inst-env guix-daemon --build-users-group=guixbuild; why this waiting only and doing nothing
<guix-vits>Hi Guix.
<Blackbeard>guix-vits: hi
***wxie1 is now known as wxie
<lfam>Veera: It's waiting for commands from other users. Try opening another terminal and doing `./pre-inst-env guix build hello`
<Veera>If I interrupt using Ctrl-C why does not it runs again
<Veera>It says socket in use
<lfam>I don't know Veera
<jakobrs>From where am I supposed to source the $GUIX_PROFILE/etc/profile file?
<Veera>lfam: I have to reboot to get it working again.
<Veera>lfam: So how you run it
<Blackbeard>jakobrs: what shell are you using? Bash?
<lfam>Veera: I run it with systemd or shepherd
<lfam>Veera: On Debian or Guix System
<jakobrs>Blackbeard: zsh. But if I put it in .zshrc it's not sourced by, for example, sudo
<Blackbeard>jakobrs: is this Guix system or a distribution?
<Veera>lfam: so by default is it running in guix; then I don't need to invoke it. is it?
<jakobrs>Another distro
<lfam>jakobrs: It should go in your login shell initialization files. For zsh that's ~/.zprofile or /etc/zsh/zprofile for all users using zsh
<lfam>Check the FILES section of the zsh man page
<Blackbeard>jakobrs: please do as lfam says then do $ source ~/.zprofile; echo "$GUIX_PROFILE"
<Veera>lfam: if $GUIX_PROFILE/etc/profile sourced once is it enough
<lfam>Only source it once
<jakobrs>I don't doubt that putting it in zprofile will make it work
<jakobrs>I just want to make sure I do this "correctly"
<Blackbeard>jakobrs: ah good :)
<Blackbeard>jakobrs: what distribution are you using ?
<jakobrs>I ended up installing guix manually, but it was a lot easier than I expected
<Blackbeard>ah wonderful :)
<janneke>yes, it was an else-less if
***apteryx_ is now known as apteryx
<raghavgururajan>Hello Guix!
<bricewge>Hello raghavgururajan!
<Blackbeard>raghavgururajan: hi :)
<guix-vits>Hi raghavgururajan.
<bricewge>No package depend on gnupg-2.0, should we keep it?
<raghavgururajan>Folks! cmake is trying to find a file provided by one of the inputs. But I have to manually set "-DCMAKE_PREFIX_PATH=". What is the default path?
<guix-vits>bricewge: if you're in those thing, can you also examine the 'python2-pyte'? it's only defined in terminals.scm and occurring in ./NEWS.
<guix-vits>i'd searched from git root
<bricewge>guix-vits: It's easy you can do it by yourself: guix refresh -l python2-pyte
<raghavgururajan>Here is the package-definition
<guix-vits>bricewge: thanks, i'll try this later on.
<guix-vits>raghavgururajan: why not
<raghavgururajan>guix-vits Habit :-D I primarily use Disroot and Snopyta services.
<raghavgururajan>guix-vits I didn't work?
<guix-vits>not in w3m; JS-capable one is on V-screen#3 (1366x766)
<raghavgururajan>guix-vits ^ :-)
<guix-vits>"PrivateBin is a minimalist..." -- they've a good sense of humor.
<raghavgururajan>Haha, what software does uses?\
<guix-vits>raghavgururajan: as the sources on GitLab... anyway i need to open JS-tab
<raghavgururajan>guix-vits Cool! I am looking for generic way to confiure flag for cmake build system.
<guix-vits>raghavgururajan: aside from README, only file ./build/rpm/bctoolbox.spec.cmake contains CMAKE_PREFIX_PATH.
<guix-vits>but that is rpm-spec
<guix-vits>Probably there is some Cmake's default
<raghavgururajan>guix-vits I see. But then why our cmake-build-system gives that error?
<guix-vits> -- "By default this is empty"
<raghavgururajan>what about the variable "BcUnit_DIR"?
<guix-vits>i'm not a developer, idk
<guix-vits>`cd guix; grep -l CMAKE_PREFIX_PATH *`
<guix-vits>raghavgururajan: something usable?
<raghavgururajan>guix-vits Nah! All of them used the empty value as " ".
<guix-vits>at least it's a "standard way", then.
<raghavgururajan>The thing is, I tried them already. But didn't work. I would like to know how paths inside build-environment are parsed.
<bricewge>Does some knows how to connect to tor hidden services in Guix.
<bricewge>I tried tor, torsocks and tor-service-type with no luck so far.
<guix-vits>bricewge: i'd started `tor --runasdaemon 1`, set content.proxy in qutebrowser to socks://localhost:9050/ , and opened as http://sejnfjrq6szgca7v.onion/
<guix-vits>. but
<guix-vits> https://sejnfjrq6szgca7v.onion/ -- "Connection refused"
<bricewge>guix-vits: Thanks for trying.
<bricewge>I followed in icecat but the check report “Sorry. You are not using Tor.”
<mbakke>any objections to moving 'grpc' and 'python-grpcio' into a new (gnu packages rpc) module?
<mbakke>nckx: shouldn't rsync get a snippet that removes those libraries from the source too?
<mbakke>also, on the core-updates branch, rsync is used during early bootstrap, this will be a fun merge :P
<guix-vits>bricewge: is there any "proxy" entries in about:config?
<bricewge>guix-vits: It work now, Using the settings as you in IceCat with tor-service running,
<guix-vits>bricewge: about HTTPS in .onion:
<guix-vits> https://3g2upl4pq6kufc4m.onion/ --
<guix-vits>bricewge: you can create a new profile, and maybe a .desktop that icecat --profile TOR (instead of TorButton, if it's not working).
*guix-vits need to research how to set proxy in nomad, but later
<bricewge>guix-vits: Good idea!
<nckx>mbakke: I don't think it should. There's no freedom or buildability issue. This way, users can still build rsync with the bundled zlib if they want.
<nckx>Glad I got this in just in time 😃
<mbakke>nckx: huh, I always prefer to purge bundled source code to guarantee that the system libs are used; make the source smaller (easier to audit); notice if the unbundling becomes ineffective in the future, etc
<mbakke>nckx: do you think we should run the ungoogled-chromium scripts in a phase instead of a snippet then?
<raghavgururajan>nckx o/
<nckx>That makes it sound like I'm in the ‘snippets are only for FSDG issues’ camp. I'm not really. If you want to add a snippet & patch the Makefile to remove some assumptions about zlib/ and popt/, fine by me mbakke. 👍
<brendyyn>is there guix-vits how do you make .onion work on guixsd?
<mbakke>nckx: right, patching build scripts is no fun, especially when unnecessary... I thought it was an easy delete-file-recursively :-)
<raghavgururajan>nckx Are you familiar with this build error?
<guix-vits>brendyyn: i do that wrong: `tor --runasdaemon 1`, then a Web-browser's proxy settings.
<mbakke>raghavgururajan: looks like CMake fails to locate the bcunit input
<guix-vits>brendyyn: then browser is accepting the onion addresses as usual ones.
<brendyyn>would be good to have systemwide .onion support
<guix-vits>brendyyn: idk; i'd heard that anything "system-wide" with a tor is a SSEPA (Self-sustained-evil-pinnocio-approach). Like "make a strong wall between you strictly hidden and strictly puplic activities". For fan, there was some instructions on Tor's Wiki and Arch-Wiki.
<guix-vits>brendyyn: fear no, i'm not a developer.
<brendyyn>what do you do with guix then xD
*guix-vits pulling guix since 2020-n
<mbakke>rekado: thoughts on moving grpc and python-grpcio into a new (gnu packages rpc)?
<brendyyn>It seems geiser is not smart enough to find to go to the point of definitions inside (arguments ...) ?
<raghavgururajan>mbakke Yeah, how do I pass the correct path to the cmake?
<mbakke>raghavgururajan: you'll need to figure out what the build system does to locate bcunit
<brendyyn>this wrap-program procedure is doing my head in. i learnt scheme because i didn't have enough brain cells for syntax
<mbakke>raghavgururajan: maybe bcunit itself needs to be built with CMake so that it installs bcunit-config.cmake or something, dunno
<raghavgururajan>mbakke build-system is looking for values in these variables. "Add the installation prefix of "BcUnit" to CMAKE_PREFIX_PATH or set
<raghavgururajan> "BcUnit_DIR" to a directory containing one of the above files."
<raghavgururajan>mbakke Ah I see. I used gnu-build-system for the package "bcunit".
<mbakke>raghavgururajan: then you might be able to pass "-DBcUnit_DIR=" (assoc-ref %build-inputs "bcunit") in #:configure-flags.
<raghavgururajan>mbakke Thanks. Is this correct?
<raghavgururajan> (arguments
<raghavgururajan> `(#:configure-flags
<raghavgururajan> '("-DCMAKE_SKIP_INSTALL_RPATH=ON"
<raghavgururajan> "-DBcUnit_DIR=" (assoc-ref %build-inputs "bcunit"))))
<mbakke>raghavgururajan: you'll need to use string-append for the bcunit flag
<raghavgururajan> (arguments
<raghavgururajan> `(#:configure-flags
<raghavgururajan> '("-DCMAKE_SKIP_INSTALL_RPATH=ON"
<raghavgururajan> (string-append "-DBcUnit_DIR=" (assoc-ref %build-inputs "bcunit")))))
*guix-vits C-mode: you should add a test if bcunit is really string!
<raghavgururajan>I think I am doing the string-append syntgax wrong
<raghavgururajan>guix-vits You may be right. I am getting an error regarding string.
<raghavgururajan>ERROR: In procedure system*:
<raghavgururajan>Wrong type (expecting string): (string-append "-DBcUnit_DIR=" (assoc-ref %build-inputs "bcunit"))
<raghavgururajan>mbakke ^
<guix-vits>raghavgururajan: it was a joke, btw
<cbaines>'( is starting a quoted list, you might need to use quasiquoting if you want to evaluate code inside the list
<mbakke>raghavgururajan: it should be #:configure-flags (list (string-append ...))
<raghavgururajan>mbakke Oh, I though (list and '( are same.
<mbakke>as cbaines mentioned, quoted lists won't evaluate code inside the list, but (list ...) will
<guix-vits>mbakke: `( ?
<rekado>mbakke: moving grpc sounds fine
<raghavgururajan>mbakke Ah I see. Btw, I don't get syntax error now. But getting the same old error. May be I'll try using cmake for bcunit package too.
<guix-vits>`( the same as '( for me.
<mbakke>guix-vits: by using the quasiquote, you can unquote inside the list with comma. I.e. `(,(string-append ...)).
<guix-vits>mbakke: thanks.
<mbakke>rekado: OK, I'll do that, so that we don't have to introduce more modules in python-xyz when they get updated (I have patches to update them too, but it breaks all the users.. required for core-updates though).
***wxie1 is now known as wxie
<brendyyn>Hmm, I don't know if it is correct to wrap a program with prefix or =?
<brendyyn>prefix would mean it would also have the users PYTHONPATH appended, = wouldn't. But which is correct for a user application?
<rekado>“prefix” means that the environment variables that the user sets are augmented. With “=” they are overwritten.
<rekado>I encountered are a couple of problems with “prefix”, especially when using PYTHONPATH, as it doesn’t seem to be processed in order.
<brendyyn>rekado: Yeah I just investigated wrap-program and learnt that, but I don't think there is any guideline
<rekado>for a Python application I would probably pick = nowadays.
<rekado>(and I use wrap-script instead of wrap-program)
<brendyyn>oh dear theres another one
<rekado>wrap-script is new
<rekado>it’s only for scripts
<brendyyn>I was thinking of improving the documentation for it, since the prefix, =, etc notation is not documentation is it going obsolete
<rekado>with wrap-program on “something” you get “something” and “.something-real”
<rekado>this can be annoying
<rekado>wrap-script just changes “something” directly.
<brendyyn>Yeah I remember the the discussion, I see you made that magic version
<brendyyn>oh just my luck. One of the executables is a python script, and the other is a binary
<brendyyn>perhaps the binary doesnt been wrapping anyway...
<rekado>so you get to use both!
<brendyyn>great fun
<brendyyn>greetings cbaines
<brendyyn>it doesn't error when there is no guile, it just enters #f
<brendyyn>rekado: So guile must become an input of this program?
<brendyyn>why is there no `guile` symbol set to the latest guile?
<rekado>there’s a branch for that
<rekado>yes, guile needs to be an input
<brendyyn>I thought you were going to right some crazy wrapper that understood how to insert code into every scripting language under the sun.
<mbakke>it feels weird to update a package only to move all users to an older version :P
<mbakke>my build server must be wondering why I'm building three identical versions of TensorFlow simultaneously
<rekado>brendyyn: no, it just places a Guile script ahead of scripts that are written in languages where # marks a comment.
<rekado>the script sets environment variables and then passes itself to the target interpreter
<rekado>the target interpreter ignores the Guile script at the top
<brendyyn>I notice the simple-services a created for dbus are not listed in herd status. is this a limitation of herd?
*guix-vits indeed, guile manual is big
<rekado>I’m slightly optimistic about Intel’s announcement of their discrete GPU.
<rekado>Intel GPU chips on laptops usually work really well with free software.
<rekado>I hope we can finally get graphics cards that work *well* without proprietary blob.
*nckx intels brendyyn.
<nckx>brendyyn: I don't think so. You haven't created any *new* Shepherd services to show.
<nckx>mbakke: Which parts of u-g are currently run in a snippet? I don't see any.
<nckx>U-G would be a site to behold.
<brendyyn>It seems that wrap-script and wrap-progam do not work the same. with exactly the same arguments, just swapping 'program' for 'script', the resulting cli tool breaks
<mbakke>nckx: the whole computed-origin-method thingy is just a fancy snippet
<mbakke>rekado: AFAIK all Intel GPUs since 2015 requires proprietary blobs if you want any kind of accelerated graphics
<mbakke>even on-die ones
<rekado>huh, really?
<nckx>brendyyn: Are you on current master? There was a recent bugfix to the Guile wrapper.
<brendyyn>nckx: how recent?
<rekado>mbakke: bah
<nckx>mbakke: How is Chromium not one big FSDG fuck-up? Sounds like the right approach to me.
<rekado>I was hopeful because on this laptop that I’m using because my Librem broke down again the integrated graphics works well enough for modelling with Blender.
<rekado>it’s an Intel HD 5500, so Q1 2015.
<nckx>civodul: Didn't you fix the argument passing bug in wrap-script that was definitely real and there and not some COVID-fueled fever dream I battled last week? Thanks.
<mbakke>nckx: well, u-c was an extreme example, a better one is 'cmake' on core-updates
<mbakke>we go to some lengths to remove the bundled sources, although not really required :-)
<brendyyn>nckx: the output seems identical though? i dont see a bug
<mbakke>...I just could not help myself...
<mbakke>nckx: I think the wrap-script bug must be fixed in (guix build utils) & you know what that means
<nckx>Ah, silly me, I was mentally counting wrap-scripts 3 users.
<nckx>brendyyn: You just said a wrapped script blew up.
<nckx>That's the bug.
<brendyyn>blew up? whats that mean
<nckx>I do not understand what I am assumed to do with that infodump.
<brendyyn>nckx: they appear to be doing effectively the same thing
<brendyyn>Hmm maybe you are right. i see the cli tool with no args is passing its own path to it's self as the first argument
<nckx>Yes. ‘Appear’. 🙂
<mbakke>huh, I've had dinner and my three TensorFlow builds are still not done... time for some IRL housekeeping.
<nckx>That's bugs for ya. Cowardly hiding in plain sight instead of politely making themselves known.
<brendyyn>im looking for that commit that changes wrap-script
<nckx>Maybe it hasn't been merged. Cut my memory some slack. Let me find the report.
<nckx>I'd replied but must've been on IRC.
<nckx>mbakke: This won't have to wait for c-u-next, will it? :-/
<brendyyn>nckx: You are a genius. $_$
<raghavgururajan>mbakke It worked. I had to use cmake-build-system for bcunit as well.
<nckx>brendyyn: True, but that's not my patch, I'm afraid. I just ran into the same bug on the same day.
<nckx>(Your $ reminds me that, yes, someone is in fact pretending to pay me to pretend to work, so I should pretend harder. Later, nerds.)
<mbakke>nckx: there is one last full-rebuild coming up before we start it For Realz, mainly to get jannekes wip-hurd work. So I suppose we can squeeze in that patch.
<nckx>Plz do. civodul ☝
<NieDzejkob>mbakke: Oh, could we also update the default Rust during that rebuild?
<brendyyn>nckx: I'm testing it. it looks like it involves rebuilding just about everything
<NieDzejkob>brendyyn: yeah, that's why we're talking about core-updates
<nckx>brendyyn: Yeah, that's the problem and why it isn't merged yet. It needs to go on core-updates. I naively thought (‘think’ is very much the wrong word here) only of wrap-scripts very few users, not the rebuild-the-world module that contains it.
<NieDzejkob>maybe we should break up (guix build utils) somehow?
<nckx>You can copy, past & fix your own wrap-script/brendynn to test, if that's worth anything now.
<brendyyn>maybe i should just wait :/
<NieDzejkob>mbakke: (to be clear, that's apply those two patches and then change (define-public rust rust-1.39))
<mbakke>NieDzejkob: that's not a world-rebuilding change, is it?
<mbakke>NieDzejkob: rust@1.20 does not build on core-updates atm (see, so it's not great to change things that depend on it
<civodul>nckx: i reported the wrap-script bug but didn't fix it :-)
<brendyyn>civodul: your patch doesn't seem to fix it
<joshuaBP`>hmmm, stopped playing sound for some reason...
<joshuaBP`>my local videos play just fine...
<brendyyn>i get the same output with the ""
<NieDzejkob>mbakke: adding the new versions is not world-rebuilding, but making them the default is.
<NieDzejkob>well, it will rebuild the rust-world
*brendyyn looks at ', syntax and brain-melts
<NieDzejkob>it's small enough to go on staging, I think, but if rust is going to need a rebuild anyway...
<mbakke>NieDzejkob: staging seems like the best branch for those patches indeed. We might end up doing another staging merge before core-updates anyway.
<mbakke>brendyyn: sometimes you need to quote the result of the unqoted expression :-)
<brendyyn>mbakke: didn't help my brain with evaluating it
<brendyyn>hmm we're at 1.3 million lines of code. i had assumed it was around 0.5. thats what it was when in started on guix in 17, so i guess i must have checked
***wxie1 is now known as wxie
<civodul>brendyyn: which patch? i didn't provide one for the wrap-script bug
<brendyyn>you provided a suggestion there
<civodul>oh right, sorry!
<civodul>ah well, too bad
<brendyyn>hmm im not sure ive applied it correctly tho
<brendyyn>hang on
<mbakke>janneke: I notice GRUB on 'master' no longer needs the custom version of Flex, let's get rid of it
<brendyyn>my scheme skills suck i cant even make my own module available in the build environment
<mbakke>ooh, GRUB works with the latest Qemu too, luxury
<mbakke>at this rate we're down to < 1 millon LoC in no time
***tristanC_ is now known as tristanC
<janneke>mbakke: yay!
<brendyyn>civodul: nevermind, it does get rid of the "", but it seems to still be wrong in another way
<brendyyn>basically the cli tool thinks a wrong argument has been passed to it even when there are no arguments
<brendyyn>OK i made it work. basically i got rid of the cons bit.
<brendyyn>previously it seemed to run ./foo ./foo args
<brendyyn>i dont know how could possibly have not been completely broken like that tho up until now
<raghavgururajan>It appears there has been new releases for GnuPG.
<nckx>brendyyn: It was. I guess nobody used it [in some specific way].
<nckx>raghavgururajan: Yep, I'm updating it as we speak.
<raingloom>sorry, i need some quick help. how the hecc do i mount a WebDAV file system? sftp finally works now, but gio tells me it needs glib-networking and i installed it and it still doesn't work :|
<NieDzejkob>raingloom: what's the exact error?
<brendyyn>can anyone understand this guix offload failure?
<raingloom>gio: davs:// HTTP Error: TLS/SSL support not available; install glib-networking
<raingloom>glib-networking is installed system-wide
<mbakke>brendyyn: does 'guix offload test' work?
<brendyyn>mbakke: no
<NieDzejkob>brendyyn: what error are you getting there?
<brendyyn>guix offload: error: unknown error while sending files over SSH
<str1ngs>raingloom: what is the value of echo $GIO_EXTRA_MODULES
<NieDzejkob>brendyyn: Hmm, what does `ssh foo guile --version` say?
<mbakke>brendyyn: does ssh host guile -c "'(use-modules (guix config))'" work?
<brendyyn>the guix offload test informed me its on guile 3.0.0
<brendyyn>my (client) guix i think is a week or 2 old
***altanil is now known as halfdan
***halfdan is now known as halfdann
<brendyyn>did we just change to 3.0, and thats causing an issue?
<mbakke>brendyyn: you need to make 'guix' available on GUILE_LOAD_PATH on the remote, e.g. by installing 'guile3.0-guix' into the user profile
<raingloom>str1ngs: /home/raingloom/.guix-profile/lib/gio/modules:/run/current-system/profile/lib/gio/modules:/gnu/store/cpaghi44za87m3dgfwskqy5yk6r9mmpp-dconf-0.32.0/lib/gio/modules
<civodul>"+;;; Copyright © 2020 6033fe7de85d" hmm
<str1ngs>raingloom: does /run/current-system/profile/lib/gio/modules contain the glib-networking module?
<raingloom>str1ngs: hmm... not that i can see... . that's bad.
<str1ngs>raingloom: what command exactly causes this error?
<raingloom>str1ngs: gio mount davs://
<raingloom>(with my-username substituted for my actual username)
<str1ngs>raingloom: can you try installing glib-networking to your user profile see if that fixs this?
<str1ngs>guix install glib-networking
<str1ngs>you can always --roll-back after
<raingloom>i did that with an --ad-hoc env, didn't change anything
<str1ngs>please try with user profile
<raghavgururajan>nckx Awesome! :-)
<raingloom>str1ngs: same result.
<str1ngs>raingloom: and with a new terminal same effect?
<raingloom>str1ngs: yep.
<brendyyn>mbakke: turns out my /etc/environment had load paths for 2.2 since i first set it up, so i set them to 3.0, now ive upgraded to a new error guix/ui.scm:1833:12: In procedure run-guix-command: In procedure =: Wrong type argument in position 1: #f
<mbakke>brendyyn: that's progress, I guess :P
<brendyyn>im not exactly sure what a correct environment should be
<str1ngs>raingloom: and $GUIX_PROFILE/lib/gio has the networking module?
<str1ngs>raingloom: stat $GUIX_PROFILE/lib/gio/modules/ . should not fail
<raingloom>str1ngs: it has and
<str1ngs>raingloom: can you check $GIO_EXTRA_MODULES again make sure it has that path in it
<raingloom>echo $GIO_EXTRA_MODULES
<raingloom>echo $GIO_EXTRA_MODULES
<raingloom>dammit. pasting is hard
<raingloom>but yes
<raingloom>it's first in the path
<str1ngs>it should have /home/raingloom/.guix-profile/lib/gio/module yes
<str1ngs>that's strange
<raingloom>yup. i hoped the sftp errors and invisible gvfs were the end of the bugs ;_;
<raingloom>hmmm (#:configure-flags '("-Dlibproxy_support=false")))
<raingloom>might this be the problem?
<str1ngs>not sure
<str1ngs>raingloom: can you try this. guix environment --ad-hoc nomad -- nomad -Q
<str1ngs>this should open guile https webpage.
<str1ngs>I don't know a better way to test if glib-networking is working.
<raingloom>it opened the guile website
<str1ngs>okay so glib-networking is working
<raingloom>well, at least partially.
<str1ngs>but in nomad I wrap GIO_EXTRA_MODULES. so I wonder if it's a propagation issue
<raingloom>maybe. i'm also not sure if just installing it in the user profile is enough, after all, gvfs is a system wide service.
<str1ngs>that might make sense if gio just does a RPC call to gvfs
<str1ngs>probably over dbus
<str1ngs>raingloom: what is the full gio command you are using?
<str1ngs>nvm you posted that already
<str1ngs>raingloom: check glib-networking is actually in system packages
<raingloom>str1ngs: checked. it is.
<str1ngs>reconfigure just encase the see if /run/current-system/profile/lib/gio/modules contains the modules
<raingloom>str1ngs: doesn't that mean having to restart? come to think of it, i never figured that out.
<raingloom>but in any case, i'm building a VM with the same config right now
<raingloom>well, same config, newer guix commit
<raingloom>(so it'll take a while)
<str1ngs>raingloom: restarting might help, but only if /run/current-system/profile/lib/gio/modules is populated
<str1ngs>raingloom: it would not hurt to restart after a reconfigure just to be safe
***jsoo_ is now known as jsoo
*guix-vits is kexec supported in guix?
<NieDzejkob>I don't think you need any special support; we do have kexec-tools available as a package
<raingloom>guix-vits: it'd probably have to be supported in shepherd. kexec tools by itself was not enough for me in Arch, i needed systemd help.
<str1ngs>ah livepatch like service would be interesting :)
<guix-vits>thanks people.
<raingloom>well, this will take a while. gonna go catch up on studying >_>
<raingloom>thanks for the help so far str1ngs (in case you leave in the meanwhile)
<nckx>You need init system support to shut down gracefully. If you don't care about that, kexec away.
*guix-vits (pen sounds) "Dear mr. L'yonya, please, we there have an init problem ...."
<joshuaBPMan>Hey guix, trying to upgrade my guix system in giving me an error when it tries to update gpgme.
<joshuaBPMan>The build log says command "which" not found.
<joshuaBPMan>Is there a way to disable make check during updates?
***dddddd_ is now known as dddddd
<guix-vits>nckx: ?did the update touched gpgme ^^^
<nckx>guix-vits: No…
<nckx>Seems to be a missing input in gpgme, not related to gnupg.
<joshuaBPMan>nckx: Is there a way that I could help you guys fix this tiny bug? Is it even a bug?
<nckx>joshuaBPMan: No, there isn't.
<nckx>That was a response to your previous ‘can you skip tests’.
<nckx>Yes, it's a bug, I'll fix it.
<joshuaBPMan>nckx: ahhh. Basically you are going to add "which" to the inputs right?
<nckx>First I want to find out what happened.
<nckx>But then, yep.
<joshuaBPMan>ok. Thanks.
<joshuaBPMan>Do you want me to file a bug report? Or is it not worth the effort?
<nckx>Thanks, but it's not worth it 🙂
<guix-vits>joshuaBPMan: IRC counts as a bug report too, afaik.
<nckx>Indeed. Thanks for the report, joshuaBPMan & guix-vits.
<joshuaBPMan>ok. Cool.
<apteryx>is /bin/sh visible in guix environment --container but not in the build side container?
<apteryx>Cause for emacs-elpy I'm debugging right now I can't see much input from the failure, it stops hard at: Searching for program: No such file or directory, /bin/sh, while I don't get this in guix environment --container
<apteryx>and of course it's explained in the manual in 7.1.4 Debugging Build Failures
<apteryx>I can do 'rm /bin/sh' in the container environment :-)
<nckx>joshuaBPMan: Happy trombone dot ogg;a=commit;h=cff600f1f65a2164ab25ff2b039cba008776ce62
<nckx>The test expects a bug that's no longer there and fails. Yay!
<nckx>(I think.)
<apteryx>and the culprit is the emacs binary calling /bin/sh at a couple places
<Veera>how to calculate base32 representation of sha256 sum of a file
<Veera>I need it for pkg definition
<Veera>I have downloaded the file with guix download but did not noted it
<apteryx>guix hash
<Veera>I know the location though
<joshuaBPMan>nckx: that's kind of cool. I wonder how you are going to "disable" that check then.
<joshuaBPMan>kudos for narrowing down the failure so soon.
<Veera>apteryx: thanks
<nckx>joshuaBPMan: I am simply going to apply that commit as a patch because I am a lazy boi.
<joshuaBPMan>oh. That works. haha.
<nckx>And this is exactly why I think we shouldn't have an opt-out flag for tests: were are all lazy girlz and boiz and doggoz and if you're first instinct was ‘tests are failing, how do I disable them’ that doesn't bode well for the rest of us.
<nckx>Nothing personal. Quite the opposite.
<nckx>Hm. Patch doesn't fix it. Damn.
<joshuaBPMan>nckx: Yeah. That's probably right.
<joshuaBPMan>nckx: bummer. hahaha. Is it the same error that's causing it to fail? No "which" command found?
<nckx>Sees ‘you're’, die's. I'm going to concentrate for a while 🙂
<nckx>joshuaBPMan: Even with the patch, gpgme suddenly wants which.
<nckx>Anyway, I'll ping you if/when it's fixed.
<apteryx>this must be one of the tree instances of /bin/sh in bin/emacs: emacs-26.3/src/callproc.c:1621: Vshell_file_name = build_string (sh ? sh : "/bin/sh");
<joshuaBPMan>nckx: thanks!
*raghavgururajan 's rule-of-thumb is `#:tests #f`. It's lazy, but hey, it works for time being. 🤷‍♂
<leoprikler>If we didn't have #:tests #f, people would just (delete 'check)
*raghavgururajan is bored working on GNOME. So working on getting Linphone into Guix. 🕴
<raghavgururajan>Yeah, true.
<jonsger>raghavgururajan: linphone doesn't look trivial to me
<raghavgururajan>jongser Yeah, not trivial. Lot of deps. Just got 5 packages to work. There are tons more.
<raghavgururajan>The project has lot of internally-developed libraries. Just like gnome.
<raghavgururajan>And cmake-build-system feels like a whole new reality.
<joshuaBPMan>raghavgururajan: have you tried twinkle? it works well enough for me.
<nckx>raghavgururajan: #:tests? #f isn't a hack since it changes the hash (as it should). An untested package isn't ‘equivalent’ to a tested one. What folks fresh from other distros sometimes ask for is ‘guix build --skip-tests foo’ → /gnu/store/identicalhash-foo/, or a road straight to hell.
***kelsoo is now known as ratz
***ratz is now known as kelsoo
***kelsoo is now known as ratz
***ratz is now known as kelsoo
<alextee[m]>how do i run etc/indent-code
<alextee[m]>it needs an @EMACS@
<joshuaBPMan>font-lock-mode is really confusing!
<alextee[m]>latest master gives me: guix environment: error: failed to load './build-aux/compile-all.scm'
<alextee[m]>also, is there a way to not make it go through all the files inside gnu/packages when building a package from there? can i specify a specific file?
<nckx>alextee[m]: No, Guix loads only what it needs.
<nckx>@EMACS@ is in, ‘make’ creates .el with the emacs in your $PATH (i.e. environment) substituted.
***drakonis1 is now known as drakonis
<alextee[m]>er, what package has aclocal? ./bootstrap needs it
<alextee[m]>i just installed autoconf
<alextee[m]>sending a few packages soon btw & updated some of my patches
<nckx>alextee[m]: automake.
<alextee[m]>nckx: ah thanks!
<nckx>automake & autoconf are an inseperable duo.
<nckx>Did I spell insufferable right.
<alextee[m]>why not make a meta package "autotools"?
<nckx>That's a lot of noise to save some keystrokes.
<mbakke>nckx: the GnuPG update seems to have broken gpgme
<nckx>I know.
<alextee[m]>i still can't run bootstrap btw:
<nckx>alextee[m]: Why aren't you in a guix environment guix?
<nckx>Is your egg broken?
<nckx>Or is Guix the chicken… anyhoo.
<alextee[m]>:o someone added premake5!! i can build a package i couldnt build before
*lfam puts on the scuba tank and dives into locales
<lfam>Anyone who knows about how locales are built in Guix or Debian, help wanted :)
<lfam>Especially Debian
<nckx>lfam: Why Debian?
<lfam>nckx: Their locales package appears to be an order of magnitude smaller than ours (check my recent reply to the locales problems guix-devel discussion)
<lfam>I want to see if we can do it like them. But first I have to figure out how locales are built
<lfam>I don't really know anything about how Debian packages are built
*nckx checks it.
<nckx>Nor I.
<lfam>I got into Guix to avoid learning that
<lfam>Maybe I should just ask the Debian maintainers for help. Some of them are upstream glibc maintainers
<cbaines>lfam, I think Debian might be doing some of the data generation after the package installation
<cbaines>read the description of the locales package:
<jlicht>hey guix!
<lfam>cbaines: Like what kind of data generation?
<lfam>(I don't know anything about locales unfortunately)
<lfam>Even 30 megabytes would be a tremendous improvement for us
<cbaines>I'm not sure, but if you download the package (you can click the small "all" link towards the bottom of the page I linked to), open control.tar.xz, and then some of the scripts like post-inst, it's calling things like locale-gen
<lfam>Currently, we are at 220 MiB
<mehlon>hello and welcome to the Guix!
<mehlon>not to be confused with Nurds!
<lfam>cbaines: Do you know where in the Debian package the actual build commands are?
<cbaines>lfam, build commands for what?
<lfam>I'm poking around the ...debian.tar.xz
<lfam>The commands for building the locales. Like, `make ....`
<chipb>cbaines: pretty sure that's right. I think update-locale gets called in postinst.
<lfam>There is an avalanche of boilerplate in Debian packages
<cbaines>the locales package contains the locale-gen script, that calls localedef
<lfam>The Guix package basically does `make localdata/install-locales`. Is this different from what Debian is doing?
<lfam>I guess Debian just ships the source and then builds upon demand from the user?
<cbaines>looks like it, although there is a locales-all package which contains the data I think
<lfam>I see
<chipb>check out debian/ in the glibc source package.
<lfam>Where do the built locales go on Debian?
<chipb>the built artifacts or the inputs?
<nckx>lfam: It's coming back to me from my pre-Nix/Guix days that ‘run localegen if you want a locale’ is/was a thing.
<lfam>The built artifacts chipb
<lfam>I see what I think are the sources in '/usr/share/i18n'
<nckx>Maybe there are no complete one-go artefacts.
<nckx>Mutable state is one hell of a drug.
<lfam>If we are worried about the size of glibc-locales, we could make it one of those packages that users have to build themselves. But it's not very quick
<lfam>And we are never really concerned about bandwidth, just disk usage. So that wouldn't help
<nckx>So not basically everyone is using locale-definitions in their system .scm already? Huh.
<nckx>I thought that was the way of the future.
<lfam>I mean, we were worried about it being 917 MiB but it's only 220 MiB on disk, so that's not the end of the world
<cbaines>One thing Debian doesn't cope very well with is lots of packages, but Guix copes much better, especially as you can programatically generate packages
<cbaines>So maybe the big glibc-locales package could be split up in to smaller packages, and you'd install a small subset
<nckx>lfam: 220 MiB is really not the worst fall back for users who don't want to bother creating their own.
<lfam>It's a big increase from the size of our glibc-utf8-locales package
<lfam>That package needs to go away regardless
<nckx>Which is random and pointless.
<chipb>eeeh...update-locale itself may not do the generation?
<lfam>I don't know what you mean chipb. I don't know enough about how locales work
<chipb>neither do I, but I think there might be a different tool doing generation. which I guess makes sense because it'd be glibc-specific?
<nckx>lfam: -utf8- is small because it's crappy, it's not fair to compare.
<lfam>nckx: So what does locale-definitions do? Does it like build a parameterized package?
<lfam>No nckx, but I'm trying to be sensitive to anyone who may struggle with the increased disk usage. The transition may be rough for some people
<lfam>I'm still operating under the assumption that all the locales are a gigabyte, which was wrong
<lfam>It's hard to become un-shocked
<chipb>nckx: on the order of 3MB small?
<alextee[m]>ok im done with the patches. if anyone's free to merge them please go ahead o/ a couple of them are just version updates
<nckx>chipb: 14. Where'd you get 3?
<chipb>I only have en_US.UTF-8 installed on this machine, so that might explain why I'm not finding the size file I'm expecting.
<chipb>$ ls -lh /usr/lib/locale/locale-archive
<chipb>-rw-r--r-- 1 root root 2.9M Jul 10 2019 /usr/lib/locale/locale-archive
<nckx>lfam: I don't think it bothers creating an intermediate package per se. It compiles locales & makes them available to the system. You know, magic.
<chipb>is it 14 with more languages?
<nckx>Just a few, though.
<nckx>And utterly arbitrary.
<efraim>lfam: maybe this is relevant? looks like their command to build the locales
<lfam>nckx: Same difference though, right?
<efraim>well, to build the locales, not to make them available on the system
<nckx>Conceptually, yes. I just meant it wouldn't answer your question if you were looking specifically for packages.
<lfam>Regarding our glibc-utf8-locales package, at least one of the locales it contains was added by user request 😂
<nckx>A package would still be nice since not everyone (presumably) has system access, rare as that may be.
<lfam>chipb: What is that locale-archive file?
*chipb shrugs.
<chipb>$ file /usr/lib/locale/locale-archive
<chipb>/usr/lib/locale/locale-archive: locale archive 11 strings
<efraim>apt show locales shows its from the glibc source package
<efraim>there's also a /usr/sbin/update-locales
<chipb>the prerm script for the locales package deletes it.
<chipb>I'm pretty sure it's the "artifacts" from built locales.
<lfam>nckx: What kind of package?
<chipb>but I can't say I'm familiar with them outside that I just use en_US.UTF-8.
<lfam>It makes me uniquely unsuited to work on this problem
<lfam>And I am totally un-uniquely available to work on it full-time for the next month at least
<nckx>lfam: I dunno, you've volunteered. I was thinking of a nice (glibc-locales (list …)) procedure that returns a package.
<lfam>I like the idea nckx. Do you know the status of the effort towards parameterized packages? Can we use that work here?
<nckx>By the way, I *do* sympathise with people who want to keep their system small and relatively (urg) un-bloated. I'm one of those folks. But I don't think we're obligated to provide everyone's dream -minimal package to do so. That's the deal. You want custom, you learn.
<nckx>lfam: I haven't heard anything more about that at all, now that you mention it.
<lfam>I agree nckx. If it's big, it's big. But I don't want to leave any big gains on the table
<lfam>Not chasing 1% reductions here
<chipb>aren't locales somewhat tricky to version when installed in parallel? I seem to remember a GUIX_LOCPATH env variable and a big caveat attached to it?
<nckx>lfam: Where do you get 220 MiB? Is that on core-updates?
<lfam>nckx: `du -sh`
<lfam>On master
<chipb>but that may be more to do with non-guixsd guix.
<nckx>chipb: That's a whole other deal. I don't think splitting them would hurt (or help).
<lfam>It's important to manage transitions from one glibc version to the next, because they break compatibility of built locales
<lfam>They never really planned for a system with multiple versions of libc running at the same time
<jlicht>is guix pull not working for anyone else either?
<chipb>yeah, I hardly blame them. the project started in a much different time.
<lfam>No I don't blame them at all
<seepel>jlicht: Seems to work for me
<lfam>And they did work with us to mitigate the problems. Previously affected programs would just crash
<chipb>yeah, I think I probably have more issues with nss modules. heh.
<lfam>Like what?
<chipb>been a while since I looked. haven't really added my guix env to the new compute farm at work.
<seepel>jlicht: I might have spoken too soon... it failed building the package cache for me
<lfam>There was a rough transition with Guix on foreign distros regarding the name service switch
<lfam>I think it's been a while since we got any reports, though. I think at this point it should only manifest on legacy distros like RHEL
<chipb>been holding out because it'll be a good sight easier when I'm off CentOS/RHEL7 and onto something with user/mount ns so I don't have to build my own /guix in my NFS.
<lfam>The fix was pretty easy, but not obvious
<chipb>the one thing that comes to mind was mysterious hangs in emacs.
<chipb>waiting on a select()
<nckx>seepel, jlicht: There are broken references to qemu-minimal-2.10 in Guix now.
<chipb>it was random enough I couldn't figure out what actually led to it.
<jlicht>nckx: as in, as a feature :P?
<nckx>You asked for it, now it's here!
<nckx>Eh, afl *needs* qemu 2.10 last I checked, mbakke. But that might've been a previous release. Have you verified that?
<chipb>er. I meant C/RHEL6. heh. 7 isn't so bad...
<mbakke>nckx: I haven't, and simply reverted the commit for now.
<nckx>Oh, it's already fixed? Never mind then.
<nckx>Thank you!
<jlicht>thanks as well!
<lfam>mbakke: I can move qemu-minimal-2.10 into the debug package module, unless you've already started working on it
<mbakke>nckx: np, and sorry for the breakage! we could really use that CI bot :-)
<mbakke>sneek: botsnack
<mbakke>lfam: sounds good, I did not plan on making any further changes
<lfam>Okay. I'm going to make it an independent package so it can't be affected by changes to the main qemu package
<mbakke>excellent, it was starting to get tricky not to break it when updating the regular QEMU :-)
<lfam>Good to know
<nckx>lfam: I think that makes more sense. It ‘belongs’ to AFL more than Qemu at this point.
<lfam>It can bit rot in another module
<nckx>*be finished
<mbakke>hmf, I knew I should have delayed the far-reaching libjpeg-turbo and util-linux:lib changes on core-updates until it was 100% guaranteed ready to go, there are difficult merge conflicts with every merge now :/
<lfam>That's the worst
<mbakke>not only that, but there are also hidden merge conflicts that git is unaware of, e.g. if a new package has been added that has libjpeg or util-linux in inputs!
<mbakke>I run git log -G 'libjpeg|util-linux' HEAD..master as second nature when merging these days
<mbakke>hmm, what happened with librsvg
<lfam>Merge conflicts hide serious issues :/
<lfam>Or rather, merge resolutions
<lfam>They don't show up in `git log -p`
<lfam>You can make changes that will be hidden from the default output of the git log in there
<mbakke>lfam: indeed, that's terrible, not sure what could be done to mitigate it
<mbakke>perfect place to hide nasty changes
<lfam>Try to avoid merges whenever possible, favoring rebase, and just be very careful. If I have to do a big merge I create a "before merge" git worktree and compare by hand with `diff`
<lfam>I think there is a way to make Git show the changes, I don't remember now
<lfam>IIRC we lost a CVE patch in a merge once
<mbakke>actually, none of the conflicts this time was due to libjpeg or util-linux, I just expected it since there were five conflicts in the short time since the previous merge :/
<mbakke>lfam: adding a new worktree is clever
<lfam>Worktrees are great, I'm glad I finally figured out how to use them. Like, years after they were invented
<lfam>I didn't see the use case until I really needed it once
<lfam>Until I found myself managing local git remotes
<mbakke>I'm so used to these merges now that I don't really think twice about it... I could not have done them so swiftly if I did not read almost every commit on the master branch and make mental notes "this must be adjusted when merging to branch X".
<mbakke>by swiftly, I mean spending an hour checking just about everything I can think of :-/
<mbakke>the absolutely worst thing is finding a problem after making the commit (and pulling it for good measure), finding a problem, and having to start all over...
<lfam>Urgh, yeah
<alextee[m]>does guix not build release versions of software by default?
<lfam>alextee[m]: What do you mean?
<alextee[m]>it looks like it doesn't pass --buildtype=release on meson packages
<alextee[m]>that adds optimization flags and whatnot
<mbakke>alextee: we use the 'debugoptimized' target, which has compiler optimizations _and_ debug information
<mbakke>essentially equivalent to gcc -O2 -g
<alextee[m]>mbakke: ah i see
<alextee[m]>well, that's sensible i guess
<mbakke>we don't pass any such flags in gnu-build-system though, so many packages are indeed built without optimizations
<mbakke>it would be good to fix that
<mbakke>but I don't have a good idea on what the API would look like
<alextee[m]>well, everything still seems to be fast so doesn't make much different i guess. but yeah better to add -O2 at least
<alextee[m]>mbakke: isn't it just a matter of appending CFLAGS to the environment? i think most distros just do that
<mbakke>alextee: it is, but it should also be possible to override it in gnu-build-system, e.g. with #:cflags or #:build-flags
<alextee[m]>ah ok
<mbakke>or maybe getenv/setenv is sufficient
<mbakke>I'll try to remember it for the next core-updates, which will hopefully also include an update to GCC 9 as the default compiler
<sirgazil>Do you have to modify system configuration files somehow to be able to create virtual machine images with "guix system vm-image"? Because I'm getting this backtrace when I use my system config without change:
<lfam>sirgazil: I think your config.scm has an error
<lfam>sirgazil: You can probably get rid of your file-systems section and use something basic from the examples in the manual
<lfam>And the bootloader too
<lfam>It depends on what you are testing
***jonsger1 is now known as jonsger
<sirgazil>lfam: I'll modify that part because it is not an error (the config works in my real machine).
<sirgazil>lfam: I'm trying to create a VM as similar as possible to my system to see if I can reproduce the .gnome-shell-real leak.
<lfam>I mean, it's an error for building VMs. It looks like it's about finding partitions or filesystems by UUID, and those things will not be avaiable in the VM
<lfam>Your real partitions will not be found in the VM
<lfam>Does that make sense?
*jlicht is happy about finally understanding the cause of a bug only I suffered from
<jlicht>thank you everyone who rubberducked for me :-)
<guix-ci>This is a test message from
<sirgazil>Almost an hour and the VM image hasn't finished building, the spinner doesn't spin, but the caret blinks...
<sirgazil>I think I won't be able to help with this.
***samis is now known as CompanionCube
<daemon77>Hi, I was hoping to get some help starting the guix-daemon
<daemon77>when I run "guix-daemon --build-users-group=guixbuild" it just hangs there and is not doing anything
<daemon77>nothing in /var/guix/log
<lfam>daemon77: That's what it does. It waits for commands from other terminals
<lfam>You should start it however you run daemons on your system. For example, with systemd
<lfam>What OS are you using?
<daemon77>Fedora 31
<daemon77>I can't get the daemon to start
<Formbi>do you get an error message?