IRC channel logs

<old>I guess I will wait next weekend to upgrade then

<podiki[m]>well we need to get that sorted out if it is a failure, I think cuirass is building a lot right now so we can see where we're at

<jpoiret>podiki[m]: we're kinda stuck waiting for substitutes right now

<podiki[m]>I didn't see any obvious recent commit that would affect rust, any idea?

<podiki[m]>but I'm not familiar with what rust depends on

<podiki[m]>I can check in later after it builds a bit and/or build locally (fast machine)

<jpoiret>the staging merge updated some dependencies of rust i'm afraid

<spiderbit>Well I am out, try tomorow again so that I don't have to at least compile firefox

<bjc>did the older kernel work for you? i didn't see it in scrollback

<spiderbit>it wanted to upgrade firefox

<spiderbit>with the reconfigure

<spiderbit>and I have no nerve to compile that, too

<spiderbit>so I C-c it

<bjc>ah ok

<spiderbit>need to go into substitutes

<spiderbit>bjc look at the bugreport on nongnu

<spiderbit>there I will report

<spiderbit>if I don't come back here

<spiderbit> https://gitlab.com/nonguix/nonguix/-/issues/257

<unmatched-paren>ACTION sent dissecting guix part 3 v2 https://issues.guix.gnu.org/62356#3 :)

<the_tubular>Nice unmatched-paren :)

<old>is there a major update right now?

<old>Haven't upgrade for a few weeks

<bjc>staging got merged into master yesterday or the day before

<bjc>and core-updates is also taking a lot of attention

<podiki[m]>is cuirass stuck? I don't see much happening for x86_64 but looks like lots of jobs queued

<podiki[m]> https://ci.guix.gnu.org/build/848231/details helm build stuck, log shows build succeeded but perhaps hung?

<glenda>Hello everyone. Can anyone tell me how to completely purge package? I have Icedove, I want to fully reinstall it, and remove all configurations.

<glenda>Did "guix remove icedove", removed ".thuderbird", installed again, all configuration is saved somehow.

<wdkrnls>Wouldn't the main issue be that configurations may be kept in your home directory?

<glenda>and?

<glenda>I said I removed ".thunderbird".

<wdkrnls>Maybe it is keeping something in /tmp of /dev/shm?

<bjc>what do you mean by "fully reinstall"?

<glenda>Remove everything, including configs.

<wdkrnls>Do these configurations survive a log-off?

<bjc>you could remove the package from your profile, and if that's not good enough, run gc, but that's not going to actually accomplish much

<bjc>what configurations? like your user preferences?

<glenda>I found a way, I erased profiles.

<glenda>I forget about profile manager.

<wdkrnls>I don't know what "profile manager" is. Is this "profile" a thunderbird thing? Or is this some guix utility I am not aware of?

<wdkrnls>I am aware of Guix profiles.

<glenda>thunderbird thing

<glenda>icedove --ProfileManager

<glenda>Same for evilfox, icecat

<wdkrnls>Interesting. Seems like something good to document in the cookbook.

<glenda>weird, for unknown reasons, I can't connect to any smtp server

<bjc>if you're trying from a residential isp in the united states, don't expect to be able to talk to port 25 anywhere

<glenda>No, I can do that, but something wrong with email client, or what.

<glenda>I host my mail server, it works perfectly when using webmail, mail client - no.

<glenda>Any mail service provider - no

<podiki[m]>rust builds fine on core-updates locally, think it is a cuirass issue being stuck on x86_64

<podiki[m]>ah maybe it is after all the i686 builds, see that is going strong

<apteryx>glenda: perhaps run icedove with 'strace -f icedove |& grep $HOME' to see where it's saving its files

<apteryx>should be under ~/.thunderbird though...

<podiki[m]>wine depends on rust-openssl-sys for i686 and that's failing as rust fails on i686

<podiki[m]>I guess via python-cryptography? but we still need to avoid rust in i686 or what's the latest on that?

<podiki[m]>or python-cryptography-rust

<podiki[m]>(on master I'm looking; post staging merge)

<podiki[m]>ditto on core-updates

<podiki[m]>but python-cryptography previously used rust before that was split off as a separate package...wonder what happened to fial now

<apteryx>podiki[m]: yeah that's one of the changes from staging (the update to python-cryptography)

<podiki[m]>i see...not sure why that is bringing in rust for i686 in wine, the dependency is through samba but I don't see a change there

<apteryx>we'll need to revive the antioxydant-build-system effort

<podiki[m]>oh ungrafted now? hrm

<podiki[m]>ah: https://git.savannah.gnu.org/cgit/guix.git/commit/?h=core-updates&id=2e5d79aca239c10074032b19dfa08da6dab7bd20

<podiki[m]>so then disable krb5 tests on i686 and include those native-inputs for 64bit only or x86_64 only?

<podiki[m]>apteryx: the next big target after core-updates then :)

<apteryx>that seems reasonable to me; or you could test if the old (and CVE-affected) 3.5.? would work for that purpose

<apteryx>(as a hidden packages, only used for tests)

<podiki[m]>parsing samba's configure and tests looks a bit involved

<podiki[m]>hm...wine would be used to often run old stuff that is likely security issue anyway, but I don't know if that's a good idea still (not an expert here at all)

<podiki[m]>rust is currently only x86_64?

<apteryx>aarch64 too I think

<apteryx>if it's only used for tests, it doesn't really matter for security

<apteryx>but it'd be hard to avoid other uses elsewhere if it's packaged, so I'd rather we don't

<podiki[m]>well wine does depend on samba directly

<podiki[m]>I meant that python-cryptography is used by samba for tests, at least based on the comment in the definiion

<apteryx>right; samba is not supposed to pull cryptography further for run time

<apteryx>it's a build time only dependency, so for this usage security doesn't matter (since it won't be used at run time)

<podiki[m]>right, so just disabling those tests and native-inputs for where we don't have rust is probably the best bet

<podiki[m]>apteryx: are you familiar with samba at all? I see tests? is #f since they take a long time, so are the native-inputs for tests just for completeness really?

<Guest19>if I have a second drive and want it to be mounted on boot in a dir of the home user, can I just do mountpoint "/home/user/dir"?

<podiki[m]>i don't see why not, as long as the mountpoint exists, is empty

<podiki[m]>probably need to declare the dependency for that to happen after the mountpoint itself has been mounted, see https://guix.gnu.org/en/manual/devel/en/html_node/File-Systems.html

<Guest19>okay good, well I thought maybe it is mounted as root, because my idea is to be mounted but accessible by user since it is just media

<podiki[m]>root has to do the mounting usually yes, but permissions should still be fine for the contents (at least thinking of linux filesystems)

<Guest19>okay perfect, thanks

<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> https://manpages.ubuntu.com/manpages/bionic/man1/pdfunite.1.html

<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

<rdrg109>mentioned poppler*

<Guest19>you can just do guix install <package> (a bit faster to type)

<podiki[m]>even better, guix shell <package> to just try it out, or guix shell <package> -- command <args> etc.

<podiki[m]> https://guix.gnu.org/en/manual/devel/en/html_node/Invoking-guix-shell.html

<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)

<podiki[m]>I guess just (inputs (append (list ...) (if ...))) sorta thing

<podiki[m]>if anyone is in a rush to fix samba, this is basically it, some minor style to clean up maybe? https://paste.debian.net/1277499/

<podiki[m]>(on core-updates and I think master?)

<podiki[m]> https://paste.debian.net/1277500/ this one rather

<podiki[m]>the last bits are whether to use a let in whole package (if that works for %current-system) and clean up the configure (invoke doesn't like being given "" it seems?)

<podiki[m]>night guix!

<jgart[m]> https://drewdevault.com/2023/04/11/2023-04-11-The-FSF-is-dying.html

<efraim>hello guix!

<MysteriousSilver>shalom

<msavoritias>hey. I am trying to add the adb thing in my system config from here: https://guix.gnu.org/en/manual/devel/en/guix.html#Base-Services

<msavoritias>it says to use cons in the services to add it. but it doesnt seem to work with my current structure of services

<msavoritias>here is my current one https://paste.debian.net/1277504/

<msavoritias>it uses append instead of cons. and it uses modify-services and list

<msavoritias>should I switch from append to cons? currently the error is: https://paste.debian.net/1277505/

<jonsger>ACTION doesn't understand what `git pull --rebase` did...

<jpoiret>msavoritias: you can add it to the list in the second argument of append

<msavoritias>add cons inside the list or just udev-rules directly?

<msavoritias>if I add it like it says in the manual I am getting unbound variable error: https://paste.debian.net/1277510/

<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 emacs-next@29.0.60-1.f1f571e does not support powerpc64le-linux" is quite embarrassing imho....

<jpoiret>mrvdb: how do other distros do it?

<jpoiret>i guess debian hasn't moved to the rust librsvgs yet?

<mrvdb>jpoiret: i'm not sure, the distro just provides a working rust (without the restriction of reproduceablity for guix, this is easier I guess) Perhaps using some other bootstrap than mrustc?

<jpoiret>right, it's just mrustc that doesn't work properly

<roptat>hi guix!

<xd1le>o/

<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>Indeed!

<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

<bjc>right

<bjc>i'm about to start another build after finishing ghc overnight, so i'll integrate it and see what happens

<andreas-e>I am also trying to do the big update (contradicting my own email). This openldap-for-linphone is quite confusing. Just try a "./pre-inst-env guix refresh -l openldap"...

<bjc>the linphone one was added earlier this month, it seems, in 626d9215589

<bjc>i'd guess it was a copy-and-paste error no one noticed due to its age and not a lot of leaf installs of openldap

<bjc>i'm going to close my ticket and pull in josselin's instead. it seems like they're functionally identical except for the phase drop

<andreas-e>Please wait, I was rather going to submit your patch after some testing...

<bjc>ok

<bjc>i'll just remove the ‘patch-sasl-path’ phase and start my build again, then

<andreas-e>Just pushed with the update to 2.6.4 and openldap-for-linphone removed. I built heimdal and realmd and hope for the best now.

<bjc>👍

<andreas-e>Let the build farm do its magic. If I was too optimistic, we can still revert the second commit. Thanks for the fixes, bjc and jpoiret!

<jpoiret>thanks!

<jpoiret>just saw the discussion, sorry

<jpoiret>CI has lots of failed builds, for reasons i can't figure out

<roptat>there's quite a lot of openldap dependents, I think?

<roptat>(gnupg is an example)

<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

<roptat>oh, there are two inkscape-1.2.1

<roptat>there's inkscape and inkascape/stable

<roptat>I wonder why this is needed

<roptat>oh, I didn't see the comment, nevermind

<TristanCottam[m]>Hi guys! Is there a rule of thumb (whether for Guile in general or specific to Guix) as to when to use let vs nested defines?

<bjc>personally, i find it hard to read logic more than a couple levels deep in a ‘let’ form, so i'll use ‘define’ for those

<TristanCottam[m]>Or even rather defineing at the top level? Should this only be done for variables used in multiple procedures?

<TristanCottam[m]>bjc: Can you clarify "those"?

<bjc>those being any form with more than two or three levels of nesting

<bjc>branches with ‘if’ or ‘cond’, too. i find them difficult to read inside a let form most of the time

<TristanCottam[m]>So you make the choice arbitrarily, according to the situation? Is this popular opinion?

<bjc>i think most matters of style are fairly arbitrary and driven by taste, honestly

<bjc>a few things are encoded in style guides, but the vast majority are not

<TristanCottam[m]>Oh, would you have any time for a quick look at what I have so far for my Minetest service, by any chance?

<bjc>sure

<TristanCottam[m]> https://codeberg.org/tristan-cottam/guix-channel/src/branch/main/cottam/services/minetest.scm

<andreas-e>roptat: 2000 packages are really not that many nowadays. I think it would make sense to drop one of the inkscapes eventually.

<roptat>I agree, especially when it was meant to be updated on core-updates, that we are not going to use anymore anyway

<andreas-e>We have a few other places with duplicate packages. It probably causes more confusion than being helpful.

<unmatched-paren>afternoon, guix :)

<TristanCottam[m]>unmatched-paren: Hello hello!

<andreas-e>roptat: For instance, here we are again: "./pre-inst-env guix refresh -l inkscape" -> No dependents other than itself: inkscape@1.2.1

<TristanCottam[m]>If anyone else minds having a look at my WIP Minetest service, it'd be much appreciated!

<roptat>hi unmatched-paren :)

<andreas-e>./pre-inst-env guix refresh -l -e '(@@ (gnu packages inkscape) inkscape/stable)': 2601 dependent packages.

<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

<TristanCottam[m]>Woohoo!

<TristanCottam[m]>Thanks for your time!

<bjc>i'm just some schmuck on the internet, though ;)

<TristanCottam[m]>But a helpful one nonetheless!

<andreas-e>roptat: If you feel like looking at ocaml, ocaml4.07-re is a package to start with.

<roptat>maybe it's time to get rid of ocaml4.07-*?

<roptat>:)

<andreas-e>Maybe also. I remember we discussed it on the mailing list, and unison can be built with a newer version (possibly after an update, I do not remember).

<roptat>ok, second failure of the day: python-m2r

<roptat>unison is already built with ocaml 4.09

<roptat>python-m2r has a newer version, I'll try

<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?

<jpoiret>yasht: yes

<jpoiret>just add an unencrypted boot partition

<roptat>mh, now sphinx-rtd-theme, a dependent of m2r is failing, also because of docutils being updated

<bjc>i have a patch for that

<roptat>but this time, updating it requires a new package, sphinxcontrib-jquery, which might just be bundling jquery, I don't think we can have that

<roptat>oh great!

<bjc>two actually. the simple one just changes the docutils min ver, the other updates rtd-theme to 1.2 from 1.0, and also updates the docutils min version

<bjc>the 1.2 patch includes the jquery plugin as well

<roptat>did you also fix m2r?

<bjc>would that be better than just updating the docutils requirement? i haven't sent them to debbugs yet

<bjc>i don't remember doing anything for m2r

<roptat>ok

<roptat>I'd need to check what's in the jquery plugin

<bjc>i'll send up the 1.2 rtd-theme patch w/ jquery, i guess

<roptat>yeah, it bundles jquery, I think that's a no go

<bjc>you want it to use the jquery package instead?

<roptat>oh we have a package for jquery!

<roptat>yes, it should use it instead

<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

<jpoiret>I should try building gnome again though

<bjc>roptat: patch is in #62885

<jlicht>andreas-e: I think the latest git commit works /w wget on i686, currently bisecting to find the particular change that did the trick

<podiki[m]>morning guix!

<podiki[m]>I'll be away until later today, but if anyone is needing to fix samba on i686, mostly complete patch and some notes: https://logs.guix.gnu.org/guix/2023-04-16.log#081538

<jlicht>andreas-e: oh oops, I'm way behind you and your garden-sun-enjoying ways :D

<podiki[m]>builds on i686 by avoiding rust (needed for wine) and x86_64 for me

<jlicht>b

<jlicht>oops, wrong window

<podiki[m]>good luck hacking today everyone, I'll be back to help out

<apteryx>I keep getting time out retrieving berlin subsitutes; is it just me?

<apteryx>guix substitute: error: connect*: Connection timed out

<apteryx>also, 'guix publish' on berlin uses 10.3 GiB of resident memory

<roptat>bjc, that didn't work, because sphinx-rtd-theme has docutils<0.18, not 0.19

<roptat>hm, no, there's something else

<roptat>does an error like "error: reference to ‘data’ is ambiguous" from gcc ring a bell to anyone?

<apteryx>I've restarted it, now it's already at 3.7 GiB and I still get timeouts. Hm.

<bjc>roptat: that patch allows 0.19 to be used, and got sphinx-rtd-theme building. i don't know about the “ambiguous data” message, though

<roptat>that's not related to sphinx

<bjc>ok

<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

<ellysone[m]>PotentialUser-74: it's the expat license

<PotentialUser-74>okay. I was wondering if they were equivalent

<ellysone[m]>see https://www.gnu.org/licenses/license-list.en.html

<PotentialUser-74>Yeah. I was reading that one

<PotentialUser-74>thanks for clarifying

<ellysone[m]>I believe

<ellysone[m]>we have licensecheck

<ellysone[m]>a tool that you can instlal

<ellysone[m]>if you're unsure

<PotentialUser-74>oh. Didn't know about that

<PotentialUser-74>Another question I have. Microsoft made this open source under MIT: https://github.com/microsoft/fluentui-emoji

<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>a combination of udev and fuse/autofs maybe

<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!

<zeropoint>could anybody give some suggestions on how best to make this work? https://paste.debian.net/plain/1277534

<zeropoint>I get an 'Unbound variable: disable-automute' error message when I attempt to start it

<zeropoint>Are you not able to use functions inside the shepherd start slot? Do I have to create a script and store it in the store before calling it?

<bjc>shepherd is a completely separate process, so it has no idea what that symbol is

<Guest19>bjc alright, i will try it out. thanks for the suggestions

<bjc>so you'll either need to put it some place shepherd can find it with a ‘use-modules’ or just embed it directly in the lambda. the latter is what i would do

<zeropoint>that makes sense, great will try. thanks

<jlicht>andreas-e: yeah, I think I have it boiled down to 3 commits, but checking now ;-)

<andreas-e>Me too! We will see who is first ;-)

<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>That does not work at all.

<roptat>ghc is taking a very long time to build...

<roptat>and it's not just one version ^^'

<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 :)

<bjc>Guest15: yeah, that causes a segfault for me

<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>Something like this...

<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)

<podiki[m]>thanks rekado!

<ngz>Badges in <https://qa.guix.gnu.org/patches> are all grey.

<ngz>(or is it gray?)

<bjc>i thought ghc took forever, but webkitgtk is giving it a run for its money

<nom[m]1>anyone managed to make kvantum work?, I set the override and all, but QT apps won't detect the changes

<nom[m]1>apparently they don't detect kvantum as a valid override