<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>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. <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 <lfam>Veera: Do you need help finding these keys yourself? <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. <Veera>lfam: thanks. I think I should get all keys for all guix project members. <nckx>Isn't that the point of the keyring? Shouldn't we just add Hartmut's key? <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. <Veera>eh: now this key is not there F556FD94FB8F8B8779E36832CBD0CD5138C19AFC <Veera>I downloaded all keys of all guix project members <Veera>commits are d68de95 to 9ae3e79 <lfam>Veera: That key was added only a couple days ago <Veera>e4b5bdf7993590fefeb7182ae71beec4a9f69e3f <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 <jonsger>lfam: you already have AV1 videos to play? <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>Incredible image quality with poor latency and bandwidth <lfam>And big improvements to live streaming too <lfam>Even broadcast TV will improve a lot <nckx>Support for my 2012 ThinkPad. <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 ***wxie1 is now known as wxie
<apteryx>bricewge: eh, thanks for following up on that eudev issue! <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. *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. <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>That man page section '-z, --compress' is a master class in confusing documentation <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 <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>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>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>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 <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 ***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 <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. <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 <Veera>lfam: so by default is it running in guix; then I don't need to invoke it. is it? <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 <lfam>STARTUP/SHUTDOWN FILES section <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 <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" <jakobrs>I ended up installing guix manually, but it was a lot easier than I expected ***apteryx_ is now known as apteryx
<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. <bricewge>guix-vits: It's easy you can do it by yourself: guix refresh -l python2-pyte <guix-vits>not in w3m; JS-capable one is on V-screen#3 (1366x766) <guix-vits>"PrivateBin is a minimalist..." -- they've a good sense of humor. <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. <raghavgururajan>guix-vits I see. But then why our cmake-build-system gives that error? <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. <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: 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 <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? <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 :-) <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 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 ...) ? <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 <mbakke>raghavgururajan: then you might be able to pass "-DBcUnit_DIR=" (assoc-ref %build-inputs "bcunit") in #:configure-flags. <mbakke>raghavgururajan: you'll need to use string-append for the bcunit flag <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>Wrong type (expecting string): (string-append "-DBcUnit_DIR=" (assoc-ref %build-inputs "bcunit")) <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 ...)) <mbakke>as cbaines mentioned, quoted lists won't evaluate code inside the list, but (list ...) will <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. <mbakke>guix-vits: by using the quasiquote, you can unquote inside the list with comma. I.e. `(,(string-append ...)). <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>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>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... <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? <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>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 <nckx>brendyyn: Are you on current master? There was a recent bugfix to the Guile wrapper. <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>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 <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? :-/ <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. <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. <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? <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, invidio.us stopped playing sound for some reason... <NieDzejkob>mbakke: adding the new versions is not world-rebuilding, but making them the default is. *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>hmm im not sure ive applied it correctly tho <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
<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 <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 :| <raingloom>gio: davs://nc.elte.hu/remote.php/dav/files/my-username: HTTP Error: TLS/SSL support not available; install glib-networking <mbakke>brendyyn: does 'guix offload test' work? <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://nc.elte.hu/remote.php/dav/files/my-username/ <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? <raingloom>i did that with an --ad-hoc env, didn't change anything <str1ngs>raingloom: and with a new terminal same effect? <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/libgiognutls.so . should not fail <raingloom>str1ngs: it has libgiognomeproxy.so and libgiognutls.so <str1ngs>raingloom: can you check $GIO_EXTRA_MODULES again make sure it has that path in it <str1ngs>it should have /home/raingloom/.guix-profile/lib/gio/module yes <raingloom>yup. i hoped the sftp errors and invisible gvfs were the end of the bugs ;_; <raingloom>hmmm (#:configure-flags '("-Dlibproxy_support=false"))) <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. <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>raingloom: what is the full gio command you are using? <str1ngs>raingloom: check glib-networking is actually in system packages <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 <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 :) <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>Is there a way to disable make check during updates? ***dddddd_ is now known as dddddd
<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. <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. <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>The test expects a bug that's no longer there and fails. Yay! <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 <joshuaBPMan>nckx: that's kind of cool. I wonder how you are going to "disable" that check then. <nckx>joshuaBPMan: I am simply going to apply that commit as a patch because I am a lazy boi. <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: 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"); *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. 🕴 <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. <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]>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 .el.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]>sending a few packages soon btw & updated some of my patches <nckx>automake & autoconf are an inseperable duo. <nckx>Did I spell insufferable right. <nckx>That's a lot of noise to save some keystrokes. <mbakke>nckx: the GnuPG update seems to have broken gpgme <nckx>alextee[m]: Why aren't you in a guix environment guix? <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>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 <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 <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 <lfam>cbaines: Do you know where in the Debian package the actual build commands are? <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 <chipb>check out debian/debhelper.in/locales.postinst 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? <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>$ 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? <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 <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. <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. <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. <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. <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>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 :-) <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 <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 :/ <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 <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... <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 <mbakke>alextee: we use the 'debugoptimized' target, which has compiler optimizations _and_ debug information <mbakke>essentially equivalent to gcc -O2 -g <mbakke>we don't pass any such flags in gnu-build-system though, so many packages are indeed built without optimizations <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 <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>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 *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 monitor.guix.gnu.org. <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 <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