<dftxbs3e>oh no.. I sent several patches to guix-patches@gnu.org directly by mistake which will create multiple issues.. <lfam>dftxbs3e: It's okay, you can merge the different tickets together <lfam>Send a message to <control@debbugs.gnu.org> that contains "merge bugnumber1 bugnumber2 bugnumber3" <dftxbs3e>lfam, it doesnt get a new bug number then? <dftxbs3e>I can send patches to any of the bugs to append to the merged one? <lfam>It doesn't get a new number, but the group is represented in the web interface <dftxbs3e>lfam, okay! And what do we do about syncthing? <dftxbs3e>Ludo stated what we discussed earlier, but we still don't have the bandwidth to maintain unbundled deps (GNU Guix isnt well equipped to handle micro-dependencies philosophy) <lfam>Maintaining the dependencies wasn't my limitation in the past. The current problem is that syncthing requires newer Go (at least it seems that way) and newer Go doesn't work with our build system <dftxbs3e>lfam, oh.. the patch worked fine for me with current go. <lfam>Right, with bundled dependencies? <lfam>I meant that, it all doesn't work with unbundled dependencies <lfam>When it did work that way, the dependencies were not too much work to update <dftxbs3e>lfam, hmm okay, my problem was writing individual packages for each and every dependency, demotivating and time-consuming work. <lfam>Yes, but once they are written, each syncthing update requires relatively little effort <lfam>I know this because I wrote them ;) <lfam>So now we either bundle them or rewrite the build system <lfam>I'm fine bundling them but ludo pushed back a bit, and I did lack the bandwidth to send the summary he requested <dftxbs3e>lfam, I think we can bundle and defer future work, plus, there's a go importer in the pipe which will ease future work on unbundling again. <lfam>Sorry I didn't act before. It hasn't been a priority since syncthing is working fine for me <pkill9>i wish the importers had the option to add boilerplate, e.g. the use-modules <dftxbs3e>pkill9, also GNU Guix-compliant synopsis and descriptions. <lfam>That's achievable with neural networks <pkill9>rekado: ah nice thanks, I don't stay inside emacs though :P <lfam>The last message requested some higher-level summaries of the situation with syncthing and Go in general. I'm not the only one who can reply <dftxbs3e>lfam, it's also working fine for me, but I feel not very safe running an older version <lfam>I ran out of energy for taking care of go in guix. Maybe I'll get it back but, ultimately, someone needs to do it <dftxbs3e>lfam, what has to be said basically? Maybe I can answer, but mostly clueless about go-build-system here <lfam>I mean, it takes some energy to learn how it works and how go expects things to work and describe what is missing <lfam>I did that for old-style go, before they introduced modules <lfam>There is definitely some enthusiasm, as seen in the work on the importer <dftxbs3e>I wish I could help, I am a complete noob with GNU Guile's Scheme. <lfam>I actually wrote answers to ludo's questions in the past, but I don't remember what thread they are in <lfam>Sometimes one has to do mailing list archaeology <pkill9>why do rust packages have a tonne of dependencies? It reminds me of npm <lfam>When I started with Guix, I had never written scheme or lisp. And when I decided to package syncthing, I didn't know anything about go. <lfam>pkill9: Yeah, it's a bit overwhelming. And there are circular dependencies too <lfam>I should reply to say "i'm giving up for now". It would help move the process along <pkill9>what i want is just lf (ranger equivalent in Go) but with the tree view <lfam>I'm sorry I can't give a more satisfying answer <lfam>The next step will be to use your patch, I think <lfam>I am optimistic about the future of Go in Guix. There are people contributing who really know about it. All that I know I learned just for packaging, and that's left me with a lot of gaps in my knowledge <dftxbs3e>When I am able to write GNU Guile's Scheme proficiently I'll sure be contributing in a better way. <pkill9>a dependency requires a newer version of a package that the main package requires, and rust seems only to want to choose one D: <dongcarl>dftxbs3e: Hi, I'm trying to get the powerpc64le toolchain working on my very custom manifest... I'm building the cross-glibc with xgcc=gcc-7, but I'm still getting the notorious "binary128 floating point type (GCC >= 6.2) is required on powerpc64le." thing... <dongcarl>dftxbs3e: I do value your time, so if I can review one of your patches to guix-patches, I'd be happy to do so :-) <rekado_>pkill9: the CRAN importer supports an %input-style, to either generate unquoted variables or to use specification->package; the latter will work without use-modules. <rekado_>(that’s acceptable for custom channels) <ryanprior>Is there a good book or long-form tutorial about Guile that takes you through most of the useful SRFIs and language constructs? <lfam>You might also ask on #guile ryanprior ***txgvnn is now known as Guest62400
<xelxebar>ryanprior: info guile? It's actually pretty good. <ryanprior>It is if you know what you're looking for, but as a learner I've found it to be very dense. <mhj[m]>Helo guixers, what projects are y'all up to <ryanprior>I've been working on packaging Hugo. It's got a ton of go libraries it depends on, hundreds of em ':D <mhj[m]>That sounds like a monumental task <dftxbs3e>it's not upstream and a bit old but works to get working on powerpc64le <dongcarl>dftxbs3e: Oh cool! I've been looking at wip-ppc64le... And i found that I need that float128 double gcc flag... Anything else in that wip-lle-bout-le1 branch you linked? <dongcarl>dftxbs3e: Ah good okay! I've been looking at those patches. Hope these get merged in master soon! <dftxbs3e>dongcarl, anything else well there's a set of bootstrap binaries and many different little things to make it work I do not remember everything exactly it's been 6 months already <dftxbs3e>marusich, I tried it locally, it's weird, libstdc++ lookup related I suppose <marusich>I am wondering if perahps the cross-compiled gcc 7.5.0 (for powerpc64le-guix-linux-gnu) is broken somehow <dftxbs3e>nothing has changed in that area of GNU Guix since my wip-lle-bout-le1 branch <dftxbs3e>"nothing" - nothing significant I could find <marusich>I am trying to see if I can work around the issue by natively building a gcc 7.5.0 first, and then using that wherever we would normally use the bootstrap (5.5.0 gcc <marusich>just a guess, though, i have no evidence <pkill9>i have an idea, ability to recover deleted generations if they haven't been garbage collectedyet <pkill9>well, garbage-collector roots in general <pkill9>but specifically for deleted generations <pkill9>Why would Signal desktop use electron if it's a security-focused application.. <dftxbs3e>pkill9, I believe requirements and practicality fight each other ***iyzsong-- is now known as iyzsong-w
<pkill9>why do i need to reboot in order for mcron service to use new cronjobs after reconfigure? restarting mcron doesn't do anything <wonko_the_sane>Speaking of Signal does it still make the arbitrary demand of linking to a phone number? And does it still lack any facilities for key management and revocation etc? (I think Signal is great, much respect for Moxie Marlinspike,et al) <ryanprior>Signal has been working on easing the phone number restriction but have not rolled out any option to sign up without a phone number yet. I'm not sure what you mean about key revocation. You can choose to "reset the secure session" with any contact, which negotiates a new key between you two. <ryanprior>There is a fork of Signal that does not require phone numbers, I forget what it's called. <sturm>Anyone know how to enable outgoing network access for virtual machines in Gnome Boxes on Guix System? <wonko_the_sane>ryanprior: thanks. In terms of revocation I've desired the ability to revoke a long term key in certain situations with signal. Also wanted to migrate preserving the same key or rotate to a new long term key within already established encrypted channels rather than needing to rebootstrap meatspace fingerprint verification <ryanprior>They are working on the migration story but they're taking it slow. Meanwhile Keybase has had a great migration story for years, but the Keybase team has been occupied adding encryption features to Zoom. <raghavgururajan> /etc/secondary.scm:124:4: error: sddm-service-type: unbound variable <marusich>I will make a commit and resolve the bug in a little bit after just a little more testing <raghavgururajan>Can anyone help with a snippet for simple-service-type that extends session-environment-service-type to declare custom ENV-VAR. (Like, FOO_CONFIG_PATH = /path/to/bar)??? <raghavgururajan>to put in on my config.scm. I would like to set a custom env-var in my guix-system. <ss2>I sense we will approach another level of abstraction: I'm running a windows programme through wine, that is running through guix, on a foreign system. The host's wine fails to load the windows programme. <leoprikler>raghavgururajan: I think it's '(("FOO_CONFIG_PATH" . "/path/to/bar")) <PotentialUser-10>I see some weird character sequence when i run guix package commands: looks like "]8;;" I've not had problems getting colored output from guix thus far, it only happens when I run for example 'guix package --list-generations' <leoprikler>I don't see any such characters in my 'guix package -l'. Perhaps your terminal is broken? <leoprikler>I don't think it's color though. The output of 'guix package -l' only contains bold and "underlined as link" highlights <PotentialUser-10>ok I'll look for problems with representing those (i use xfce4-terminal 0.6.3) <civodul>PotentialUser-10: these are escape sequences for hyperlinks <civodul>normally terminals either ignore them or turn them into clickable links <civodul>however, there was a bug in old vterm libraries, which is probably what you're seeing here <civodul>(xfce4-terminal in Guix is more recent) ***apteryx is now known as Guest52388
***apteryx_ is now known as apteryx
<PotentialUser-10>xfce4-terminal installed with guix (0.8.10) has the same problems. What terminal do you use? <marusich>Hey, good news! I successfully built GNU Hello using Guix on powerpc64le-linux. Nice. <PotentialUser-10>civodul: same problem with gnome-terminal. The command in question is 'guix package -l' (list generations) <marusich>Let's see what needs to change to get Guix to build. <civodul>PotentialUser-10: i just tried with today's xfce4-terminal and it seems to just ignore hyperlinks here <marusich>I think dftxbs3e already did this months ago, but the difference is now it is using commits in our repo. <marusich>and using the bootstrap binaries we put on alpha <marusich>To build Guix...should I try to just use pre-inst-env to build the relocatable version? <marusich>I had to specify --with-courage to build it manually from source on debian, so I'm skeptical Guix can build Guix without some further adjustment <civodul>if it "officially" supports ppc64le, you can tweak guix.m4 so --with-courage is no longer needed <marusich>it would be nice to have a "binary guix" like the kind you can download from the website, but I'm not sure what the next steps are to get there <civodul>you'll still need to "make update-guix-package" after that <civodul>these are the two steps i guess (assuming everything builds fine), and the third step is "make guix-binary.powerpc4le-linux.tar.xz" <civodul>also... we need ppc64 machines for the build farm :-) <marusich>so the steps would be (1) make changes to guix.m4 etc. so we "officially" support ppc64le, (2) run make update-guix-package (and commit the changes I guess), then (3) make guix-binary.powerpc64le-linux.tar.xz. All of those are required, in that order? <marusich>And there is no way to "sneakily" try to build Guix using Guix before doing any of that, eh? <civodul>you can add "--with-courage" to #:configure-flags of the 'guix' package <marusich>I mean, if I run "./pre-inst-env guix build guix", it's going to use an older version which definitely doesn't have my changes <civodul>right, so you need --with-courage in there <marusich>I would also have to update the origin right? <marusich>I mean, this is just curiosity. I'll do the 3 steps you described, since it doesn't seem like much <civodul>there are two options: (1) add --with-courage to the 'guix' package so you can run ./pre-inst-env guix build guix, or (2) use "make update-guix-package" after you've made --with-courage unnecessary <marusich>I'm sure a few things won't work. At least it's easier/faster to debug build problems now, than to try to debug bootstrap binaries (such slow turnaround time) <civodul>yeah i guess you may encounter build issues <marusich>By the way, is it intended that all gcc versions in (gnu packages gcc) use #:tests? #f? <marusich>I noticed that gcc-final, which inherits from one of those, also disables the tests. I wanted to enable them, but I found that it didn't quite work (maybe a bug?), although many tests did pass. <civodul>it's a choice that was made at the very beginning, but we could/should revisit it <marusich>I was kind of paranoid about my gcc-final not being tested <marusich>OK. I need to go to sleep, but I'm very excited about the progress so far! <marusich>Hopefully others will be interested, too, and the problems building guix and cuirass and other packages will not be too difficult... <marusich>Regarding build machines for the build farm, I'm sure we can get them. If it helps, I'd be willing to set up a VM to crunch through some builds. I think dftxbs3e might also. <cbaines>guile-ssh fails to build on core-updates, which is what I think is preventing the Guix Data Service and Cuirass from processing the branch <cbaines>Unfortunately, I think a different problem was introduced first, then this problem introduced, then the first different problem was fixed, so I didn't have any luck tracking back to when this specific issue was introduced <civodul>cbaines: the "tar.gz" extension on the directory looks fishy, too. <cbaines>yeah, I changed that locally, but it didn't have any effect <civodul>i may have to do with recent patch-and-repack changes <cbaines>I think I checked the file permissions with guile-ssh on master, and they matched <PotentialUser-10>In case it helps someone else, the only guix installed terminal I could find that supports displaying (and clicking!) on hyperlinks output in the result of the 'guix package -l' (list generations) command is *terminology* *civodul tries "guix environment --ad-hoc xfce4-terminal --with-latest=vte -- xfce4-terminal" <civodul>PotentialUser-10: the command above gives the same results: links are ignored <civodul>the escape sequences are swallowed though (as with current master) <civodul>i'm pretty sure i've seen links in GNOME Terminal though <PotentialUser-10>civodul: terminology is the only one where clicking on the link actually worked, and opened thunar for me. I'll stick with that. The xfce4-terminal and gnome-terminal build options probably are missing a configure flag setting, it's above my pay grade. <pkill9>ryanprior: the signal fork is called session, i watched a video last night that mentioned it, heh <civodul>cbaines: we can try reverting cfcead2e515c0dae02127e5a76496463898be6b6 but it's going to take ages <cbaines>civodul, I can try that out locally, I already tried reverting another commit without success <civodul>this one can be reverted just fine, modulo unimportant conflicts in tests/ <civodul>rekado_: does "guix environment -C" works on your cluster with NFS-mounted /gnu/store? <rekado_>it doesn’t work here but fails differently <rekado_>we don’t have /proc/sys/kernel/unprivileged_userns_clone <rekado_>it builds everything and then fails with ‘guix environment: error: clone: 2080505873: Invalid argument’ <rekado_>I’m having a problem with ‘specifications->manifest’; it doesn’t seem to return <rekado_>when I use the exact same list of package names with ‘guix build’ it works fine <rekado_>but with ‘guix package -m manifest.scm’ my CPU gets hot <civodul>rekado_: re EINVAL, that's the usual failure mode for ancient kernels that don't support user namespaces at all <civodul>rekado_: could you share that manifest? <civodul>it may have to do with propagated inputs, just like you saw the other day with inferiores <rekado_>I’ll try to reduce the test case; I’m seeing it with even just one package (‘r-zoo’), but I cannot reproduce it in ‘guix repl’. <rekado_>must have been recompiling / loading Guix modules due to bytecode mismatch <rekado_>this bytecode incompatibility is unfortunate. My system Guix has a slightly different Guile version than the one I got with ‘guix pull’ ***rekado_ is now known as rekado
<piemont>Hello, my Guile initrd is failing to mount my LVM volumes despite messages on the console saying that the volume group had been found. Any tips on how to debug the initrd from the Guile REPL? For instance how can I "ls /dev"? <efraim>I'm getting errors with getaddrinfo in the initrd: In procedure getaddrinfo: Servname not supported for ai_socktype <piemont>NieDzejkob: thanks! Its strange, the vol group is there under /dev/mapper, but attempting to mount any LVM volume fails with "No such device", even if specifying it with "/dev/dm-<num>". Mounting a non-LVM FAT partition works fine though. <piemont>Hmm is there an easy way to get dmesg output in the Guile REPL in the initrd? Or do I have to use ice-9's popen? <apteryx>any idea why guile-ssh is completely broken on core-updates? All the tests fail. Perhaps the openssh version? <rekado>piemont: is the disk containing your shell not available? <civodul>apteryx: cbaines reported it earlier today, and i was wondering whether it's a pack-and-repack regression <civodul>in particular the directory name is broken (ends in ".tar.gz") <rekado>bah, this incompatible bytecode stuff is annoying <rekado>I already pulled and booted into a newly reconfigured system <apteryx>civodul: no that was just a writable problem I think <apteryx>I've pushed a commit addressing this <rekado>and still I get warnings when using pre-inst-env guix <apteryx>pack&unpack wouldn't be able to cause the test suite to fail, I think? <rekado>how can I tell what bytecode version a .go file has? <civodul>apteryx: correct; except for a few exceptions, the test suite doesn't build anything serious <civodul>(one exception is tests/pack.scm, which uses the host's build daemon to reduce costs) <apteryx>prolly the tarball detection code is too simplistic <apteryx>seems a pretty rare occurance; I'll fix it. <sirmacik>is guix import capable of getting golang packages? <apteryx>civodul: ah! the source definition does a checkout, but says the name ends by tar.gz <apteryx>probably just removing that line will fix it <apteryx>that fixes the source file name, but that doesn't fix the tests <piemont>redako: Only the initramfs filesystem is available, my root is an LVM lv. Unfortunately only util-linux-libs are in the initramfs so I cannot run dmesg to find out why the mounting fails <civodul>rekado: it's stored in the ELF by (system vm assembler), but i'm not sure how to extract it <euandreh>How can I set a package description to the content of a file in the tarball? <rekado>I’m in a pure environment, ran ‘make clean-go’, rebootstrapped the build system, reconfigured, confirmed that guile 3.0.5 is used, ran ‘make’, and still ‘./pre-inst-env guix build foo’ says ‘WARNING: loading compiled file /home/rekado/dev/gx/branches/master/guix/ui.go failed…’ <euandreh>I started writing code to re-download the tarball, add the file to the store, etc., but it felt as a bad workaround <euandreh>I couldn't find any examples of this on the repo, also <rekado>the package description should be a plain string <euandreh>rekado: I agree on sticking to plain strings on the Guix repo, but I'm still interested in doing this for a custom channel <benoitj>I have a question around how guix handles .so lookups. I'm using qutebrowser, and it does not see libasound_module_pcm.so* unless I export a LD_LIBRARY_PATH pointing to the modules folder in my .bash_profile. Is this normal? <rekado>and now ‘make’ complains: error: failed to load 'gnu/packages/cran.scm': No such file or directory <rekado>(that’s the only file that I modified) <benoitj>and hello everyone, I just started using guix last week and love it <rekado>benoitj: the binaries embed references to the declared libraries at build time. For everything else that wasn’t available at build time you would need something like LD_LIBRARY_PATH. *rekado wonders if the load path troubles are related to that extra ‘guile’ binary we build <benoitj>rekado: ok thanks. so in this case, either qutebrowser build does not have libasound_modules in it's "inputs" so it did not get these references embedded <benoitj>it could be by design, since not everyone wants sound enabled on qutebrowser <pkill9>benoitj: which backend are you using? qtwebengine? <pkill9>the qtwebengine package has alsa-lib as an input <apteryx>civodul: re guile-ssh, seems only the libgcrypt version moved (from 1.8.5 to 1.8.7), and also guile from 3.0.2 to 3.0.5. <pkill9>maybe it doesn't link to it correctly <rekado>at least the ‘failed to load’ error is because of a syntax error. <pkill9>hmm libasound_module_pcm.so isn't in the alsa-lib package <benoitj>pkill9: still, it fails to load sound unless I add the LD_LIBRARY_PATH <pkill9>i'm just thinking out loud, not denying your experience <apteryx>civodul: I'm guessing it's a change in Guile; the tests expect the 'pass symbol, they get #t instead and fail <benoitj>pkill9: I took it this way :P I'm thinking out loud too :D <benoitj>pkill9: LD_LIBRARY_PATH="$LD_LIBRARY_PATH:.guix-extra-profiles/desktop/desktop/lib/alsa-lib/" <benoitj>without this, qutebrowser complains not finding the modules <daphnis>make complains of missing c compiler; what do i install? i though gcc-toolchain, but that didn't work <sneek>Welcome back daphnis, you have 1 message! <sneek>daphnis, Apteryx_ says: This is at least wrong: (device "/dev/sdX") <pkill9>i would have thought it's in the alsa-plugins package, but i can't find it there <pkill9>unless you omitted anything after pcm <rekado>pkill9: alsa-plugins, not alsa-lib <civodul>apteryx: i don't see any significant change in (srfi srfi-64) ***modula is now known as defaultxr
<rekado>pkill9, benoitj: There are a number of plugins starting with ‘libasound_module_pcm’. Is there a specific plugin it is complaining about? <benoitj>rekado: for sure libasound_module_pcm_pulse.so <rekado>that’s in alsa-plugins:pulseaudio <apteryx>rekado: for the incompatible bytecode stuff, if it's happening your your guix checkout, try running 'make dist', and start from scratch <apteryx>that fixed it for me last time, IIRC. <civodul>rekado: one complication is that the 'guile' executable in Guix could be linked against a different libguile than the 'guile' executable from Guile <civodul>so yeah, you'll need to rebuild that <civodul>when in doubt: make clean && make :-) <roptat>rekado, what helped me was to re-run ./bootstrap and ./configure <Ikosit>Where does the go build-system put the libraries? Bc i only found source code, when i installed e.g. go-github-kr-fs *Ikosit just realised, that the reason for the non-existing libraries, is probably that go links the libraries statically <civodul>apteryx: do we really want to make *source* files writable unconditionally? <civodul>i would not do that unless we have evidence that this is a problem for a number of packages <cbaines>civodul, apteryx on this subject, I've tested reverting cfcead2e515c0dae02127e5a76496463898be6b6, and I get the same error when building guile-ssh <apteryx>civodul: I don't think it'll change a thing except for the handful of packages that needed an aditional phase. <apteryx>civodul: also, it's annoying that --keep-failed builds sources are read-only, for hacking purposes <civodul>dunno i'm more concerned about unexpected consequences <terpri>is there consensus about adapting descriptions from other free package-management systems, e.g. debian's package descriptions? (mid:edefe54dbac4b8b8bbd4d567eb88150068040fb0.camel@telenet.be reminded me of the question) <civodul>also extra i/o (think chromium :-)), dangling symlinks that cause the phase to fail altogether, things like that <piemont>After some more digging, neither "xfs" nor "btrfs" is in /proc/filesystems in my initrd <terpri>i'm not sure if the typical debian description of just a few sentences (e.g. "Firefox ESR is a powerful, extensible web browser with support for modern web application technologies.") is even copyrightable, or if debian specifies a license for them in case they care <apteryx>civodul: I guess we can wait and see? If there's a problem with it we'll find out soon. <civodul>apteryx: but when we find out, we have to go for a full rebuild <civodul>my general approach for these things is to opt for very focused changes, defensive programming, and parameters <terpri>(it's a minor thing compared to just writing a new description but it would be nifty to have an "insert-debian-description" command to autofill the initial synopsis/description for common packages...) <civodul>terpri: "guix import" usually provides something <apteryx>cbaines: the file name thing was just that; the file name <apteryx>now it fails it's test suite for unknown reasons <cbaines>apteryx, really? I'm sure I got the same error in the bootstrap phase, after changing the origin part <terpri>i should remember to use that more often :) <cbaines>I'm just testing again what I see with the change to the origin file-name <cbaines>FOr some reason, my computer is building git though, so this might take a while <apteryx>cbaines: that one error was fixed by the bold change to make everything writable as part of the write phase ;-) <cbaines>apteryx, when I check the file permissions of the guile-ssh source on master, I see it as read only <cbaines>although this is testing with --keep-failed, and hoping that's consistent with what's actually happening during the build# <apteryx>cbaines: the commit that did fixed this is minutes old; 6129ebddbdd306ab60bb657d627db87686d76aa0. <cbaines>So, I'm pretty uncertian about just making files writable, I'd like to find out what changed the build to break it <apteryx>it seems autotools wants to update a copy of the files present in the guile-ssh repo, IIRC <apteryx>so it tries copying its files over but fails because its read-only <apteryx>I didn't investigate carefully, but making the files writable gets us passed this block <cbaines>I've finished building guile-ssh with the changed origin, based on the commit when I merged master in to core-updates <apteryx>all seem to fail with result-kind: pass -> actual-value: #t <apteryx>reverting libgcrypt to 1.8.5 didn't fix that <apteryx>I'm trying with guile 3.0.4 for the kicks but I doubt it's this too <cbaines>Hmm, I'm struggling to read that test output :( <cbaines>It's quite fustrating that even with working around the boostrap phase failing, there's yet more issues <cbaines>flopping around between multiple breaking changes that prevent building the channel itself is not great <cbaines>part of me thinks that if a branch ends up like this, it would be better to declare patch debt bankruptcy, rename the branch to core-updates-broken, and start again from master <apteryx>civodul: weird, no? Something going from Guile 3.0.4 to 3.0.5 caused the guile-ssh test suite to return #t instead of 'pass <piemont>Is it possible to "guix system reconfigure" a guix installation from the livecd or is it required to run "guix system init" and therefore redownload all the packages again? Simple chrooting means guix cannot access the daemon socket. <cbaines>apteryx, that commit is on master... so it can't be individually causing the failure <cbaines>however, when you look at guile-ssh at that commit, it's being built with guile 3.0.2 <cbaines>so where are the changes on core-updates that change the guile used to build guile-ssh <cbaines>looks like that change to 3.0.5 came in with this merge of staging 01f0707207741ce2a5d7509a175464799b08aea6 <piemont>Also I think that the version of GRUB in Guix does not have the boothole security patches applied, or at least I cannot see them in the package definition. ***niklas[m]2 is now known as n1ks[m]
<brown121407>Thank you to whoever built the "guix package --export-manifest" command! It's really useful <bavier[m]>if a package already installs `COPYING` and `LICENSE` files, does it make sense to remove the 'install-license-files phase? <apteryx>cbaines: I'm guessing it has to do with exception handling in Guile <civodul>brown121407: t'was long overdue, glad you like it! :-) <cbaines>I can't see 01f0707207741ce2a5d7509a175464799b08aea6 in the guix-commits mailing list, which is pretty confusing... I wonder if the git hook just failed for some reason? <cbaines>this is also annoying because that means the Guix Data Service effectively just skipped this change <apteryx>in the srfi-64 tests, this gets called (test-runner-fail-count (test-runner-current)) *after* the test-end call. <apteryx>The test-end call must destroy the test-runner object, so that fails. <apteryx>not sure why that was different in Guile 3.0.2, but that seems to be the bug. <civodul>apteryx: Guile commit de5d1a7f99b8e952b115237ebc29633062f99bb9 might be relevant <pkill9>does anyone run guix for a media centre PC, like as an alternative to libreelec? <pkill9>why are file managers not referred to as 'filing cabinets'? lol <bavier[m]>I have guix on an old computer. I have it running Kodi and hooked up to a TV. <rekado>apteryx: yeah, I did a distclean and it seemed to be fine then <rekado>apteryx: there’s a similar problem with guile-commonmark when built with 3.0.5. (The tests pass with 3.0.2.) <apteryx>civodul: yes, I think the change in behavior was caused by this commit you mentioned <PotentialUser-84>Is there a package for Guix that contains the haskell 'stack' command? I'm not sure how to search guix packages for 'command named xyz'. <PotentialUser-84>'guix search' searches by package name and description, not command names <lispmacs[work]>I added a udev rule to my system configuration for (non-root) access to the USBasp microcontroller. Seems like the rule should be available to guix as a whole, but am wondering what the path forward would be on that. Would the rule get added to some udev rules file in guix repository, or would a package need to be created? <lfam>It's about the long-term support of linux <lfam>It's a little window into the mind of the person who manages the program <lfam>That person being Greg Kroah-Hartman, in case you weren't aware :) <pkill9>does anyone find that qutebrowser doesn't play embedded videos on bbc news webpages <pkill9>i'm also curious how qutebrowser works with the webkit backend even though qtwebkit isn't an input <lfam>It uses python-pyqtwebengine aka chromium <pkill9>but I can switch it to webkit backend <lfam>qtwebkit is a (transitive?) dependency of qutebrowser <lfam>`guix graph qutebrowser | grep webkit` <pkill9>guix graph --path qutebrowser qtwebkit <lfam>I don't know if it is accessible though <lfam>Transitive dependencies are not always something that a program can find or use <pkill9>i forgot about guix's sweet function <pkill9>to find the path to a dependency <pkill9>back when i was obsessed with qutebrowser, it was like my dream for it to be in guix, and eventually it came true <pkill9>especially as i was new to guile and it seemed insurmountable to create a package for it <lispmacs[work]>I added a udev rule to my system configuration for (non-root) access to the USBasp microcontroller programmer. Seems like the rule should be available to guix as a whole, but am wondering what the path forward would be on that. Would the rule get added to some udev rules file in guix repository, or would a package need to be created? <apteryx>cbaines: I've made a patch for guile-ssh; will commit shortly <apteryx>cbaines: shoud be fixed with 3299530c43. <lfam>Yes, it's a minor bug :) Reported as #46303 <benoitj>pkill9: bbc news issue is possibly due to widevine <civodul>and if i retry seconds later, i gets 700K/s <lfam>It must be staying in cache... there's like 120GB of page cache <mjw>Or wget being smart "OK, if you want it all into /dev/null I can do that..." :) <civodul>mjw: that's be a smart optimization :-) <Ikosit>Hi, i want to package pulseeffects. Pulseeffects needs some search-paths set at runtime to the limiter, compressor, etc. . So i wonder how it is possible to get the path of the plugins (lsp-plugin, calf,…) in the search-path definition since %build-inputs is only bound in the arguments section of the package definition. My current pd: https://paste.debian.net/1184068 ***sneek_ is now known as sneek
<apteryx>I'm curious; why do "./pre-inst-env guix environment -n -m manifest.scm" vs "guix time-machine -C channels.scm -- environment -n -m manifest.scm" don't produce the same output? <apteryx>where channels.scm contains the exact same commit as the one used in Guix source checkout <mjw>civodul, but seriously, I just tried and here it goes from 14.4 MB/s to 7.3 MB/s but never seems to drop lower. <civodul>apteryx: we'd have to check the specifics <lfam>I usually get very fast downloads but, occasionally, they are measured in KB/s <civodul>it's weird, i got it at 10M, then 4M, 2M <lfam>Is it ... on purpose? To punish clients that are doing something weird? <lfam>(This is a very American question) <mjw>(It isn't particularly faster or slower with -O /dev/null) <civodul>"that guy in France has been downloading linux-libre 20 times in the last hour, enough is enough" <lfam>Yeah, that's what I had in mind :) <lfam>We could try running the "atop" program on ci.guix.gnu.org, and looking for problems <lfam>It's sort of a holistic "system resource monitor" <mjw>"that guy just dumps it in /dev/null... if that is all he is doing, he probably doesn't care how many bits we sent him..." :) <lfam>I'm not that familiar with it yet but I added the package recently after reading about it <apteryx>note, the --dry-run option is not honored in the guix time-machine command <apteryx>civodul: the guix is from one of my worktrees; I've 'source ~/path/to/worktree/pre-inst-env' to have that guix readily available <ngz>Next week project: packaging nu-shell. 276 Rust new packages or updates. Some grunt job ahead. <civodul>ngz: what's up with this new passion for Rust? :-) <lfam>ngz: Do you know if `guix refresh` is supposed to work recursively for rust crates? <lfam>I tried using it last night but it seemed not to. I wasn't sure if this was expected or not <civodul>it's never recursive... unless you pass -r maybe <pkill9>is there a way to give a rust dependency one version of a dependency, and the main package a different version of that other dependency? <lfam>Right, I used it with -r <ngz>civodul: Not really a passion, but with "#:skip-build #f" it's very easy to package Rust stuff. So I am experimenting. <ngz>I didn't try guix refresh, though. <civodul>apteryx: can you try comparing the first "deepest" .drv that differs? <ngz>pkill9: I think so. Everything is ultimately vendored in the same place. <abcdw>My friend building a package and getting a warning on patch-shebang phase: "no binary for interpreter `python' found in $PATH". Which is kinda expected, because python package has only python3 binary, but not python. How to workaround it? <ngz>abcdw: use python-wrapper <lfam>noproto: You're that person who had found some issues, right? <apteryx>civodul: by deepest you mean the first one to appear in the output of the drvs about to be built? <noproto>that's some pretty impressive deduction <lfam>I think I saw your username in another IRC network when was looking for your other handle <apteryx>civodul: perhaps that's expected when working from a non guix-pulled Guix (e.g., from the checkout directly), as it doesn't live in the store. The time-machine command wants to create the /gnu/store/kabcc4kamc1jli6gqksd9iip1jfr6cw3-guix-3299530c4.drv derivation for the Guix commit; the rest must depend on it and thus differ? (thinking out loud). <lfam>It seems that we completed the "ungrafting" branch just in time for some new grafts <lfam>I got a Debian security advisory for openldap <apteryx>civodul: you were right about that unpack change being bold <apteryx>In procedure chmod: No such file or directory <pkill9>ngz: do you have any idea how or where to find out? <pkill9>qutebrowser got adblock style blocking 8 days ago <apteryx>civodul: I'll wrap the make-file-writable call in a false-if-exception handler <civodul>false-if-exception is a sledgehammer <ngz>pkill9: No, I don't. Have you tried? If so, what happens? <civodul>apteryx: i wonder if we could make it so that we don't touch the result of a tarball extraction? <civodul>so we'd make file writables only if "source" is a directory (as in the guile-ssh case) <civodul>no no, as a way to minimize the impact of the change to what we were addressing <apteryx>well, if we just wanted to minimize the impact of the change we could add a make-files-writable phase to guile-ssh. The goal here was to be able to rely on the fact that the unpack phases make files writable, in my view. <pkill9>ngz: well when i changed the inputs rust basically tried to choose only one <civodul>apteryx: in general i think it's safer to not change the resulting of extracting a tarball; build results can be brittle <civodul>for Git checkouts, it's less critical <pkill9>it builds it all statically by default (dunno if you can change it) so it expects only one i think <apteryx>civodul: OK, I'll try your suggestion. <civodul>apteryx: but yes, we could also fix it locally in guile-ssh as a first step, and generalize if it turns out to be more problematic <civodul>(it's also quicker to check since that won't involve a full rebuild) <apteryx>what I find annoying enough to want this behavior change is the read-only files left in /tmp/guix-build-x/ when using --keep-failed. Perhaps that's something to live with... <civodul>when building something built off a checkout? yeah <apteryx>that's what the bug report associated with the commit was about, IIRC. <civodul>it's not necessarily inconsistent since a tarball could extract to read-only files, but yeah, can be annoying <apteryx>sometimes it's writable, sometimes not. For no good reason. <apteryx>so I could move that make-file-writable thing to the else cond branch of the unpack <apteryx>but I still need some guarding against exception, in case of dangling symlinks <hapster>I am trying to update the game "pioneer". Is there a possibility to try it before uploading it? <apteryx>You mention 'false-if-exception' is sledge hammer; any suggestion of something more adequate for this case? To me it seemed adequate: try, but never fail. <civodul>apteryx: make-file-writable cannot be done in pack-and-repack because directories in the store are always read-only <civodul>so it has to be done in the unpack phase <civodul>but you could make it so that it's done only when the source is a directory <civodul>find-files uses lstat by default, so we're good <civodul>then you could just wrap the make-file-writable call itself in false-if-exception <civodul>perhaps that's what you had in mind actually? <dongcarl>Hi all, is there still a reason why the build phase lambdas need to return #t? <lfam>And, the reason will go away soon, IIUC *lfam hunts for old discussion <civodul>apteryx: shouldn't that be in the (file-is-directory? source) branch? <civodul>lfam, dongcarl: we can already drop those #t <dongcarl>civodul: Which commit on core-updates fixes this? <dongcarl>civodul: Very cool! Will give those a read! <apteryx>thanks to you! And sorry for contributing to climate change. *apteryx thinks about bitcoin mining anytime they feel bad about world rebuild energy costs. <civodul>and guess who's at the intersection of world-rebuilds and bitcoin? <lfam>Our world rebuilding energy usage is probably equal to a single bitcoin user downloading and verifying the blockchain from scratch <lfam>At least our work can be re-used :) <dongcarl>Not to get too into this, but a surprisingly large portion of miners use renewables, especially hydroelectric power <vagrantc>non-competative work will always be more efficient than competative work :)( <lfam>It would make sense since it takes a truly unbelievable amount of power <lfam>For what, like 4 transactions per second <lfam>It might be more efficient to go back to bartering <lfam>A lot of aluminum smelters use hydro, too <civodul>but but... i didn't mean to start a debate :-) <lfam>There's no debate here. I'm simply correct :) *dongcarl goes back to coding :-) <lfam>I've been prebuilding linux-libre tarballs on berlin so that Guix users don't have to build them. *vagrantc dreams of the day when linux-libre tarballs are available for aarch64 again :) <vagrantc>i did finally at least get the wip-pinebook-pro branch up to linux-libre 5.10.x <vagrantc>need to trim down that patchset so i feel ok pushing to master... <lfam>If it works for you, I think it's okay to push sooner rather than later <vagrantc>lfam: it's maybe 1400 lines of code, most of which is not upstreamable... <lfam>I wish we had a powerful aarch64 server that you could use for testing <vagrantc>if only i had a few apm mustangs and an overdrive ... oh wait... <vagrantc>just haven't had the time to set them up usefully... <rekado>I’m totally not jaded or bitter, but … maybe we should do that CDN thing again <lfam>Dreams of a rack of Altra 2x80 core servers <vagrantc>although now i can just install debian on them and install guix! ... that actually removes a few annoying steps <vagrantc>rekado: there are problems with delivery? most of the problems i've seen are things just not being built <rekado>vagrantc: whenever someone mentions download speeds here I get that feeling in the pit of my stomach… <rekado>I just want this problem to disappear — or rather to not be *my* problem <rekado>same with bugs with issues.guix.gnu.org *rekado looks like a used match <lfam>I'm sorry to hear you're feeling bad rekado <vagrantc>the nice thing about guix being a small community project is you can really make huge improvements in a short time ... the downside is you're stuck maintaining it sometimes :/ <vagrantc>though, that happens plenty with larger projects too ... <rekado>today was one of those days again… I was day dreaming about my post-computer life; I realized once again that I actually really don’t like computers. <rekado>reality check came when I inspected my wood working results from yesterday night. I don’t think I can switch careers. <vagrantc>i gave a talk about my solar setup a while back which was admittedly mostly focused on the various electronic bits, but i rambled on a lot about the efficiencies of growing some sunchoke plants which provided shade and food and way more solar efficient <lfam>Woodworking is a skill that develops quite slowly, but it does develop. A friend of mine does luxury cabinetry and it took him about 5 years of full-time work to get there <lfam>And, he had done basic woodwork since childhood <lfam>I wouldn't give up on it <rekado>oh, I won’t! But I’ll have to suffer a lot of bad software until I’m really good at it :) <lfam>He spent several years doing "fabrication", which meant retail store displays <pkill9>wish i had developed a skill since childhood <rekado>vagrantc: I have discovered that I’m absolutely in *awe* of plants. They’re the best and so modest. <lfam>pkill9: It's never too late to begin <lfam>You'll just be an old child ;) <rekado>pkill9: some skills come out of hiding in the right set of circumstances (”wax on, wax off“) <dongcarl>Is there a way to build a package in a subdirectory of its unpacked tarball/git repo? <dongcarl>in the context of writing a package definition, that is^ <rekado>dongcarl: what I did was to copy the sources <rekado>it’s not pretty, but at least you can write to the files <dongcarl>rekado: The dumb way is just to `cd` into the subdir in a stage before the build, right? <rekado>yes, you can do that (for unpacked tarballs) <rekado>or you can use with-directory-excursion to limit the effects of the directory change <rekado>but for git checkouts of extra sources in native inputs you can only copy <civodul>rekado: oops sorry for the bad feelings! (i should know better) <lfam>Does anyone know if the Guix Day talks will be recorded? <abcdw>lfam: Do you mean discussions during last Guix Day? <nikita`>at least in a timetravel accident to '98 we'd know about covid and other things ahead of time. <lfam>We'd know about it, but I'm sure we wouldn't actually do a thing <rekado>civodul: oh, it’s not your fault :) 