<apteryx>podiki[m]: I'm not sure; a good test is 'guix gc -R samba | grep python-cryptography'
<apteryx>if it keeps no reference, it's unused at run time
<podiki[m]>you could also mount somewhere like /mnt and symlink for the user
<Guest19>Do you know if it is possible to specify for grub (not efi) a target as uuid instead of /dev/sdb?
<apteryx>ah, run the 'guix gc' on the store samba prefix rather, I think
<podiki[m]>well openldap is failing to build first so... :)
<podiki[m]>provide-libldap_r phase fails, removing that then patch-sasl-path fails
<podiki[m]>oh maybe this is a merge error? patch-sasl-path was removed previously
<Guest19>building /gnu/store/3awm22k82gfzjsz9cjdxy7av860sxfrb-module-import-compiled.drv... is it normal that this takes long?
<podiki[m]>depends on what you mean by "long" and your system I suppose, but I would give it time
<podiki[m]>fixed openldap by removing those 2 phases, the sasl one I'm pretty sure was accidentally restored in a master->core-updates merge in January, not sure about the provide-ldap_r one not working now
<podiki[m]>apteryx: for samba the tests (at least some) are via the "--enable-selftest" configure argument, or at least that checks for python-cryptography at configure
<Guest19>well, i just added that mountpoint and changed the target for grub since my hdd number changed. normally a system reconfigure is done in under 5 minutes, now it is still running after 30 min+
<rdrg109>[Q] Which programs do you use for merging a set of pdfs? In
<Guest19>though if you use it, make sure to have out.pdf as last or it will overwrite your last pdf
<rdrg109>Guest19: Thanks. I was wondering in which Guix package, that binary was located in. The website you shared mentioned, and that lead me to the poppler package. => $ guix package -i poppler <= did the job
<podiki[m]>trying to make python-cryptography only a native-input in samba for x86_64 and aarch64, but failing to figure out what to put when the if is false....(in old input style it is '() of course)
<mrvdb>the increasing dependency on rust is killing guix for powerpc64le, many packages can't be used anymore, or upgraded. mrustc, which is used to build rust, fails to build on powerpc64. the list of packages I can't use from guix anymore is increasing rapidly to the point where guix isn't a viable package manager anymore on ppc64le.
<mrvdb>I mean: "guix install: error: package email@example.com does not support powerpc64le-linux" is quite embarrassing imho....
<roptat>I'm a bit late, but I'm joining the fun with core-updates :)
<roptat>I'm already having an issue building openldap, which is very early in the dependency graph...
<roptat>looks like it was updated, and #$output was left behind while the gexp was dropped
<bjc>roptat: i've got a fix for it on debbugs. jpoiret has a slightly different one
<andreas-e>Hello! Good news, I just sent out an email to guix-devel about the state of things, and openldap was important on the list.
<andreas-e>I mean, I am happy about the good news that you have a fix!
<bjc>should i be informing the ml about patches i have? i've been tagging them as ‘core-updates’ in the title in debbugs
<bjc>i have two others sitting there. i hope to have a couple more ready today, as well
<andreas-e>Something is strange there: we have the variables openldap at 2.6.3 and openldap-for-linphone at 2.6.4. But both have the same name, so a user would anyway install the latter by the command line.
<andreas-e>Do we expect breakage? It might be worth the try to update to only one version since we need to rebuild all dependents anyway.
<bjc>that is weird. i didn't notice that. i wonder how many people really install openldap by hand these days, though
<andreas-e>bjc: I do not know. We could also get into the habit of looking at the issue tracker... Informing guix-devel could be helpful, there is not so much traffic there now that it would be disturbing. Or mention it here; I read through yesterday's logs and did not find openldap mentioned.
<bjc>definitely the problems most of us are having are with the variable named ‘openldap’, not the linphone one
<andreas-e>Yes, because this variable is referenced as input to other packages.
<bjc>ah, jpoiret and i discussed it for a few minutes, but it can definitely be easy to miss
<andreas-e>bjc, jpoiret: I think it would be good to use two commits, one for the fix and one for whitespace and indentation. Casually looking at both fixes it is very difficult to see what they do besides changing indentation. (If you want to change indentation at all, which is a bit a matter of taste.)
<bjc>the main thing is the introduction of a gexp and the removal of the _r.la file
<andreas-e>I saw the dropped phase. So it is gexps and not white space. Still I think it would be easier to review in two commits.
<bjc>ah, i didn't have the phase drop. i didn't see the response until now
<andreas-e>Your patch goes further than jpoiret's by dropping the phase, if I understand correctly. Did you try to build a few dependents?
<bjc>i have only been building the dependents that pulled in openldap in the first place. jpoiret suggests keeping the phase. i believe that's the only substantive change between our patches
<bjc>i'm not attached to losing the phase, it just seemed like a good time to get rid of some cruft. jpoiret said he thought it was better to keep it because it's too late in the core-update merge process to safely remove it
<andreas-e>I think we should also try to take John Kehayas's comment into account.
<bjc>there's a follow-up to #62859, though, that has *another* phase removal, arguing that the ‘patch-sasl-path’ phase was erroneously merged in
<jlicht>hey guix! What's the best thing I can do to still contribute to the core-updates party?
<andreas-e>I explained it (modulo my own limited understanding) in my email. My cancelling and restarting jobs apparently marked builds as failed when we are just waiting for an input to be built. I am not sure whether this will sort out itself, or whether I will have to restart again later. Anyway, everything dependent on openldap should get a fresh chance now.
<andreas-e>jlicht: Whatever you feel like doing! The one thing that needs doing is getting wget build on i686. One idea I had is to try building a tarball created from their latest git and see whether this passes its tests (--with-source). If yes, we could try to find the needed commit. If not, I am out of ideas...
<andreas-e>roptat: 3039 dependent packages. CI has not yet started them, it is still evaluating.
<roptat>I'm trying to build my home config, which has most of my packages :)
<roptat>but, it has some java packages, and I'm now building icedtea 9
<andreas-e>I can try to build it manually on berlin, but it is likely you will finish faster nevertheless.
<roptat>don't worry about me, it'll build eventually
<bjc>andreas-e: just saw your report email. if it helps: ghc built for me overnight without issue
<andreas-e>Should we get rid of it immediately? Strangely it does not just inherit, but replaces a phase by an identical one (unless I overlooked something) and adds an input (that we could also add). I wonder if in the end we could not end up with the same derivation for inkscape than for the current inkscape/stable.
<bjc>TristanCottam[m]: nothing stands out as a problem to me
<roptat>that worked, should I push immediately, or should it go through the ML?
<andreas-e>The latest git version of wget builds on i686!!!
<andreas-e>I would say, push. We cannot break a broken package more. If you want to be extra sure, you could try to build a depending package or two or three. Sometimes it is better to not update to the latest version, for instance, but only the one that builds without breaking the dependents.
<andreas-e>Anyway, with Python I think we are solving NP-complete problems by hand every day...
<roptat>haha, I'll build a few dependents, it's less than 300 anyway
<andreas-e>I think I could use git bisect on wget to find out the commit that is working. There have been only 24 since the last release. Something for later, I will profit from the sun in the garden first.
<apteryx>andreas-e: enjoy! thanks for shepherding the work on cu :-)
<yasht>Is there a way to install Guix with LUKS with unencrypted boot on EFI systems?
<ngz>Whenever I try to run "guix time-machine --branch=core-updates -- weather -m .config/guix/manifests/base.scm", I get the following error: "substitute: In procedure write_wait_fd: unimplemented". What am I doing wrong?
<bjc>i'll just send the docutils version patch, then. i should have done this is a series of commits anyway
<roptat>actually, I don't think we have jquery, but we have a few packages that already bundles it, so it might be fine
<bjc>it's fine, i can add another patch later. honestly, doing both in one patch was silly. i only did it that way because my first attempt was hoping the problem would go away with a more recent rtd-theme
<jpoiret>apart from zig I don't think my own packages are running into build issues
<roptat>the patch could not work, I think you applied it on top of a change to the version
<bjc>ugh. ok. that's what i get for trying to use ‘git add --patch’ on the fly
<agnem>Has anyone had issues with M-x guix-all-packages timing out? Also, M-x guix-packages-by-name doesn't seem to show packages from custom channels, anyone know how to fix that?
<bjc>oh, the patch i provided only worked for 1.2.0. i'll fix it
<bjc>roptat: i've updated #62885 with a fixed patch
<PotentialUser-74>Please. Could someone help me understand licensing? I'm wondering which license should a package have if the software being package uses MIT License. I've looked through the guix available licenses on (guix/licenses.scm) but couldn't find it
<PotentialUser-74>The thing is that they are not providing the .ttf files so the easy way is to grab the font from a w11 ISO. I guess distributing the ttf even if the emojis are open source would be an infringement. Is this something we can add to guix or nonguix channels?
<PotentialUser-74>I imagine that one could create a guix package which made use of tools for converting svs to ttf and as long as the ttf is being built it will be okay for guix to package it. Is this assumption right?
<Guest19>how can i mound a hdd without root? basically I want to work with it as a user. currently i have on config.scm added a second filesystem but that mounts it as root
<bjc>non-usb drives tend to come with root-only permissions attached, so you'd need to update with udev for your particular drive. with that done you should be able to either automount it with autofs or use fuse to mount it
<andreas-e>jlicht: Back from enjoying my weeds! Did you get any further? Otherwise I will start bisecting myself.
<Guest19>bjc: Its just a simple sata connection. is fuse/autofs documented in guix? Since I have no clue to use it on guix
<bjc>fuse might be, i haven't checked. autofs isn't, but arch's wiki was helpful for me
<bjc>for udev, there's a ‘udev-rules-service’ in guix for creating the rules you'll need
<andreas-e>For wget the situation is more complicated than it looks. They bundle glib, and one of the commits their authors suggest to me updates the bundled version. So we cannot use the git commit as a patch (it just encodes the commit hash of the gnulib subproject). I will see!
<jlicht>andreas-e: So, it seems the "Fix HSTS" patch + gnulib update does the trick, but the gnulib part makes it kind of annoying. We do have a gnulib-checkout procedure floating around somewhere...
<andreas-e>jlicht: I am confused. I can compile wget for i686 with the tarball created by "make dist" with each and every commit from 1.21.3 to HEAD. In particular, also with 1.21.3. But the content of the "make dist" tarball and the downloaded one have a unified diff of 50000 lines! It may simply be because I used a different autoconf for bootstrapping.
<jlicht>andreas-e: once you've initialized the gnulib submodule (based on HEAD), I think it stays around at that version. So perhaps the only required change is the gnulib update, in that case? Still seems weird...
<andreas-e>No, I did a "git submodule update" to downgrade it. I have tons of differences in build-aux/* files and the like. Maybe I will try to just replace the configure file.
<andreas-e>It is terrible! Maybe the ghc people could see whether it is possible to cut out some versions during bootstrapping. Efraim apparently dropped one already.
<jlicht>andreas-e: you are right. Somehow the previously generated autoconf/automake files no longer work /w i686? Confusing
<andreas-e>I will try to run "autoreconf" in a phase. We have examples in the repo.
<andreas-e>jlicht: This is totally crazy. After adding "autoreconf -vfi" (which pulls in lots of dependencies) on the release tarball of wget, the tests fail in exactly the same way as before.
<Guest15>Hi, can someone please confirm that this bug on Guix System is reproducible? Backup ~/.mozilla/icecat , go to about:preferences#privacy to IceCat-specific privacy settings and activate "Detect Captive Portal". Close IceCat and try to open it again. Does it segfault? If yes, you can repair it by restoring the icecat directory.
<jlicht>andreas-e: can confirm. At least we're reproducibly haunted :)
<Guest15>bjc: okay, thanks for trying out. then i will add a serious tag to the issue, it isn't getting any attention..
<andreas-e>jlicht: I also tried to pass the 2MB diff between the two directories as a diff, but then (I suppose) file time differences cause things to break since it tries to autoreconf or something along the lines.
<andreas-e>jlicht: I think it is much more subtle: When I bootstrap the wget git repo on the v1.21.3 tag, then I get a tarball that fails.
<andreas-e>When I ./bootstrap on HEAD, then downgrade to the v1.21.3 tag and its associated gnulib commit, with "make dist" I get a tarball that works. Probably because this gnulib checkout messes with the files of the build system...
<jlicht>so it's not the autotools, it's the effect of the older gnulib on the autotools-generated files?
<andreas-e>One needs the new gnulib before running "./bootstrap". Then I think the gnulib/ subdirectory does not play a role any more. So it is not something we can easily mimick without a lot of contortions.
<andreas-e>I will try to prepare a tarball that works. The best solution would be if they made a new release.
<jpoiret>andreas-e, jlicht: is wget used in bootstrapping?
<jpoiret>Otherwise using git-fetch could be considered instead
<andreas-e>jpoiret: I think it is too complicated. One would also have to fetch the gnulib submodule.
<jlicht>andreas-e: we do seem to have a 'gnulib-checkout' procedure
<andreas-e>Interesting. Indeed something like done in guile-gnutls could work. git checkout wget, then remove the gnulib subdirectory and link it to the gnulib checkout in the store instead.
<andreas-e>But it is quite some effort for a project that does release tarballs.
<podiki[m]>question on invoke, it doesn't like an empty string as one of the arguments? I wanted a conditional argument but wasn't sure how to handle the false case (should be nothing added)
<rekado>podiki[m]: use apply with an argument list
<rekado>and to build the argument list you can use splicing
<podiki[m]>okay, figured that was an option but was hoping there was something obvious I was missing
<podiki[m]>this will be for samba, I think it is the same issue on master and core-updates but haven't checked if the patch is exactly the same (should be)