<dissent>hey guix, figured out how to use startx. was fairly easy actually. is using xorg-configuration in the sysconfig dependent on a display manager? <jgart>Or, is there some other way to not use a dm with xorg? <dissent>jgart: thanks currently studying these configs but managed using xinit in a different way. <jgart>dissent, cool! How'd ya do it? <jgart>dissent, cool! Are you autostarting X? <dissent>jgart: no cause sometimes i just need the tty. so just run the script/start the server by pressing x :D <jgart>what do you have `x` aliased to? <jgart>I've mostly been using Guix System on the server. Looking to get a spare laptop to start hacking my Guix System desktop dream world <KE0VVT>jgart: You mean, to test it as a desktop before you migrate your production desktop to Guix? <jgart>although I like having three solid package managers to work with <dissent>jgart: in arch i had alias x=startx, in guix though I have x as the script that was provide in the mailing list above. <dissent>dang also with xorg configured it seems I can't even run herd locally. <dissent>this juice might not be worth the squeeze haha. <char>hello guix. I want to build a package from a guix.scm, but I recently changed the source, and guix is continuing to use the old source. Is guix gc the solution here? <jgart>I might move over to Carbs Linux from Void Linux once I investigate it further and get GNU/Guix working on it. I like the idea of having a distro where the majority of the base packages are statically linked. Then, having Guix beside that :) <jgart>char, maybe try changing the hash and forcing it to fail <jgart>then try building with the correct hash again <drakonis>that gentoo and arch post has some very silly takes <M6piz7wk[m]>i looked through manual for 2 min and didn't find an answer <M6piz7wk[m]>how do i install packages for users using config.scm <drakonis>M6piz7wk[m]: you dont? but you can use guix home for that <jgart> I agree that gentoo is complicated <M6piz7wk[m]>what would sane person do to figure out how to use guix home to do that then <drakonis>probably but why do you alawys have to take the hardest path to solve a problem? <M6piz7wk[m]>drakonis: because gentoo devs lack basic experience with computer science to realize that there are more efficient methods to fix an issue <M6piz7wk[m]>at least use exherbo for comparison.. it's like gentoo, but much better implemented <jgart>guix is the fanny pack I take with me while I distro hop <drakonis>nah, exherbo is still as complicated at gentoo <M6piz7wk[m]>i am supposed to look through 248K lines of code to find my answer to how to deploy packages for users? *M6piz7wk[m] found home.scm <jgart>I just need an atomic distro manager for migrating any given distro in place <jgart>dissent, what are you referring to? <M6piz7wk[m]>is there a way to user-mount a luks on /home/username in the login manager phase *M6piz7wk[m] has encrypted homes and wants to mount them on login <jgart>system configs/services for doas, pipewire, and more *M6piz7wk[m] wonders if he can write a thing that takes over w$ and replaces it with guix <apteryx>podiki[m]: librsvg, perhaps through gtk <apteryx>oh, no I think it's handled at that level for non x86 <podiki[m]>apteryx: seemed to be polkit via (a bunch of packages like mozjs via...something else) <podiki[m]>so I think once the polkit/duktape is sorted that should fix it...? but I'm not sure <podiki[m]>apteryx: hopefully we'll find out soon enough, once polkit/duktape is sorted and all is rebuilt <dissent>jgart: haha "ripgrep"... that was a suggestion to the person above who was asking how to sift through 280k lines of code. and thanks for the github link. *M6piz7wk[m] approves rustlang's ripgrep <dissent>jgart: that level of configuration is insane. <jgart>dissent, this is config insanity for everyone/everything <apteryx>M6piz7wk[m]: ripgrep is not copyleft-protected though (and so is most of rust stuff it seems) <M6piz7wk[m]>apteryx: rustlang things follow technoliberal ideology over FSF's forcing of open-source :p <oriansj>M6piz7wk[m]: free software not open source <oriansj>and no guns where involved so not sure how one could call what they do force <M6piz7wk[m]><oriansj> "6piz7wk: free software not..." <- i meant that GPLv3 forces open-source where most things in rustlang doesn't while both approaches comply with 4 freedoms <jgart>licenses are complicated like gentoo <M6piz7wk[m]>gentoo is not complicated.. it's over complicated :P *jgart pushes a repo containing code released under Unlicense <apteryx>M6piz7wk[m]: 'forces' is a bad choice of word in my view; rather, I'd say that it is more strict about ensuring the original intent of someone putting the code under copyleft, so that user freedoms are preserved. It works harder toward protecting users freedoms. <ns12>Does Guix have a release schedule? <samplet>ns12: Not really. There’s been some discussion about trying to release every six months, but nothing concrete yet. <ns12>What is the purpose of Guix releases and version numbers when everyone is expected to do `guix pull` anyway? Why not release every day from the master branch? <podiki[m]>I believe release is when a core-updates branch gets merged into master, which has a lot of upgrades (or at least is similarly timed with releases) <podiki[m]>otherwise is rolling, updates whenever you do guix pull <podiki[m]>but big upgrades of core packages aren't until a core-updates merge <ns12>Karthik[m]: Yes, the Guix System ISO, and the Guix package manager binary. <apteryx>ns12: releases are supposed to be more thoroughly tested, including the installer image and installation script; and fixing the test suite if it needs to. *apteryx reconfigures system on core-updates-frozen <jgart>would it be possible to perform set operations on profile generations (union, intersection, difference, complement)? <jgart>apteryx, did you use time-machine to do that? <apteryx>nope, I've been running on core-updates-frozen for a few days regularly doing 'guix pull --branch=core-updates-frozen'; testing my various profiles <apteryx>hmm, I could reconfigure successfully but there were some problem at login (dbus timeout or something) <apteryx>seems to be org.freedesktop.login1 that fails <jgart>apteryx, could you share the config you built that system from to the 52051 email thread? <jgart>I'd be interested in seeing it <jgart>could be helpful for others in reproducing the bug too maybe <sneek>Welcome back civodul, you have 1 message! <civodul>looks like we could use also use these two callbacks to improve progress reporting too <civodul>speed seems comparable to yesterday :-/ <civodul>db.sqlite is at 19G, perhaps there's something we should do? <cbaines>civodul, do you know what the GC is currently doing? I'm guessing it's connected to the guix-daemon process that's donig lots of I/O <attila_lendvai>i'm packaging GPaste, a gnome clipboard manager. any hint for this? "install: cannot create regular file '/gnu/store/00bkkmzybyfmbhhv0nw7r49m72339lyf-dbus-1.12.16/share/dbus-1/services/org.gnome.GPaste.service': Permission denied" <vivien>attila_lendvai, I see that gpaste wants to modify the dbus service <attila_lendvai>it wants to install a service file. probably it needs to be told to put it somewhere else... but where? <vivien>You should use what upstream supports ^^ <vivien>attila_lendvai, you can use a different directory by passing --with-dbusservicesdir=dir <attila_lendvai>vivien, thanks, that's half the solution. but what dir am i suppoed to give it? grep'ing for this didn't bring any examples *attila_lendvai has found some interesting matches <vivien>I don’t really know, but if you pass (list (string-append (assoc-ref %outputs "out") "/share/dbus-1/services")) it should work <vivien>sorry add "--with-dbusservicesdir=" in the string-append call <vivien>By work, I mean you should be able to install it <attila_lendvai>vivien, yay! thank you, it has built. now on to testing if it actually works. <civodul>cbaines: the GC is currently doing the sweep phase, mostly spending time browsing the database <civodul>you can see that by stracing the guix-daemon process <civodul>the one returned by "guix processes |recsel -e 'ClientCommand ~ "gc"' -P SessionPID" *civodul merges master in core-updates-frozen ***tom42 is now known as tom
***tom is now known as tom42
<M6piz7wk[m]>I am about to flood the channel with incompetent people that have no idea what they are doing and will most likely just be help vampires~ ***to-hu1 is now known as to-hu
<jlicht>civodul: Some years back you gave an interview/guest appearance on a podcast, mostly about guix; one of the podcast hosts was a guix community member as well; do you remember where to find this interview, or am I misrembering things? <vivien>Anyway, if you rewrite that blog 1984-style I won’t be bothered :) <jlicht>civodul: yeah, that was it! Thank you <mjw>off-by-one seems good enough for me :) congrats-1 ! <vivien>So, do we still pretend we’re releasing 1.4.0 today? ^^ <jpoiret>(i won't need to apply them on top of all my checkouts) <jpoiret>vivien: i'm seeing some movement in the NEWS file still :) <vivien>True, it’s hidden behind a boring merge commit <atw>today I learned that openjdk and openjdk:jdk both install a java command, and that they're different (the latter includes more modules) <rekado_>vivien: the plan was to merge c-u-f, not to release — or was it? <vivien>Even if there’s a release, we need some alphas and betas <atw>and it includes more stuff in the bin directory in general. I got confused because I installed both, and the less featureful java command from openjdk:out was used. <jpoiret>currently writing a big spam post to #gnome-shell on their irc server, to finally get some help :) here's to hoping we'll find out something *vivien grabs popcorn and goes to GNOME’s #gnome-shell ***sneek_ is now known as sneek
<vivien>jpoiret, it’s desperately silent :( <jpoiret>aha, I'm not expecting any answers that soon though, it's a pretty involved thing <vivien>Are you still trying to understand the missing icons? <jpoiret>everything I tried to test worked, so I'm kinda stumped <civodul>now we could also celebrate the anniversary of the first commit, that of 1.0, or any other milestone <jpoiret>jgart: thanks for this blogpost, currently watching "FOSDEM 18 - How to make package managers cry" :) <roptat>given enough time, everyday will be an anniversary :) <jpoiret>I'm firmly in the "celebrate every commit" camp <civodul>vivien: the blog post you mention must have been added retroactively <vivien>Oh so the date doesn’t even matter ^^ <civodul>maybe not actually, seems to have been imported from Savannah's old news section <vivien>Should we also celebrate CI successes? <vivien>I subscribed to cuirass’ RSS for a few hours, and then I realized it was too large for me to handle <vivien>But it will tell you when things get fixed <civodul>the risk is that if we all wait for a notification, nothing actually gets fixed :-) <vivien>Right, it requires a solid determination to keep doing things while guix is compiling derivations <vivien>I fell for that, I even disabled substitutes and now I’m paying the price <civodul>anyway, i had hoped we'd be able to merge core-updates-frozen by now <civodul>there was talk about polkit-duktape on non-x86_64 <vivien>I don’t exactly know what it’s about <vivien>I know there’s some involvement with Rust <pseudonymous>how can I complete remove a profile? The install process (guix package -m my-manifest.scm -p /path/to/profile) failed because a directory already existed at the profile. Then I removed that (and <profile>.new), re-ran the command and it seemed OK. But the program I installed (emacs) crashes on start. I want to remove the profile entirely and re-try from scratch. <vivien>pseudonymous, I’m sorry for saying this, but that may be a case where rebooting (or at least, log out / log in) could help you. <vivien>(sorry because I don’t know much about the problem and only present a trivial thing to try) <pseudonymous>vivien: np :) I'm not using Guix as a full distro but as a package manager. <roptat>isn't emacs one of these packages that assume they're in ~/.guix-profile? <jpoiret>you can rm the guix profile directory normally. Removing the store directories is unneeded, as you should be getting the exact same emacs package <efraim>civodul: I can take a look at the go cross-compilation patch, but I'm on vacation through the end of the week so I can't promise much right now :) <pseudonymous>roptat: really ? I thought it point was that I could put packages in whatever profile and be fine ..? <jpoiret>pseudonymous: the thing is, many programs need to be patched to cooperate with Guix. <jpoiret>and sometimes those patches are not perfect unfortunately <pseudonymous>But I can see I have two odd symbolic links, emacs-1-link and emacs-2-link (I named the profile emacs), pointing to separate store directories. I've read that I shouldn't run around deling store directories manually, but `guix gc` doesn't seem to remove them, even after `guix package --profile=.... -r emacs` was run. <jpoiret>you might want guix package --delete-generations[=PAT] <pseudonymous>jpoiret: PAT? I tried `guix package --profile=~/.guix-profiles/emacs --delete-generations=emacs-pgtk-native-comp` but that just says "Invalid synax: emacs-pgtk-native-comp". On a related note, I get the sense that I managed to hose the system somehow.. can I nuke and pave ? <jpoiret>--delete-generations is meant to remove a whole profile generation, not a package <jpoiret>you can look them up using `guix package -p profile --list-generations` <pseudonymous>Hm, not really informative output from the command, it just says "Generation 2 <date> (current)" but I cannot see how to delete anything. `guix package -p ... --delete-generations` does nothing and whatever arg I attempt (`--delete-generations=current`) just fails. <pseudonymous>jpoiret: providing `delete-generations-2` I get told "warning: not removing generation 2, which is current" providing `delete-generations=1` gives "error: no matching generation" <jpoiret>can you rm the /var/guix/profiles/per-user/youruser/emacs-profile? <jpoiret>i agree that there's poor support for completely removing a profile, but this should work <pseudonymous>jpoiret: those I can probably remove (if not, sudo), but they call mention `current`, I gather that's the default profile ? The issue I have is with the `emacs` profile(s) which seem to have been made. Namely `emacs-1-link` and `emacs-2-link` which both point to different directories in `/gnu/store/<>-profile` (their dirs end with `-profile`) <jpoiret>where are those emacs-1-link, emacs-2-link files? <pseudonymous>jpoiret: they're in ~/.guix-profiles`, a custom dir I made and pointed to with an env-var, GUIX_PROFILES_DIR, somewhat inspired by the cookbook entry on managing profiles. So what started this mess was me running `guix package -m manifest.scm -p ~/.guix-profiles/emacs` where the emacs dir existed as an empty dir with a single manifest scm file. guix did _NOT_ like that and errored out. I had to remove the dir manually, and some <pseudonymous>symlinks to re-run the command and see it complete. But then I got all these symlinks littering. <jpoiret>mhmmm, my bad, I thought they would be in /var/guix/profiles/.... You can remove all these symlinks, it should be ok <pseudonymous>So now, I hope to nuke whatever came of that and start afresh. And ideally, I would hope that I can remove the profiles I made and gc away all the packages from that. So that I could try installing emacs from scratch. <pseudonymous>Hm, removing the symlinks and running `guix gc` did mention removing some (now stale) symlinks pointing TO said symlinks. But `tree /gnu/store|grep emacs` still reveals lots of files from the installed copy of emacs and `gnu gc` doesn't seem interested in removing more stuff <jpoiret>pseudonymous: well, gc'ing these isn't really useful, you'll get the exact same store location and contents when reinstalling emacs <pseudonymous>jpoiret: in some ways I'm just not able to understand why I cannot remove stuff which right now is supposedly not used by anything. I know guix has some binary packages, but in this case, I'm installing emacs from a different channel for which there's no binary, compiled package. To me, it seems anxiety-inducing that I cannot seem to get back to a "clean" state. Even if I've misunderstood something. If I never wanted to install emacs <pseudonymous>ever again it seems strange to carry it around on the disk. <jpoiret>you can explicitely use `guix gc -D /gnu/store/xxxxx-path` to tell the gc to delete a specific path <civodul>for some reason the latest core-updates-frozen evaluation at ci.guix failed <vivien>civodul, I could pull after your merge <apteryx>also, what is the meaining of "None" in channel changes? restarted by hand? <pseudonymous>Hm, thoroughly confusing, guix insisted a package (through a different channel) did not exist until I sourced ~/.config/guix/current, and that's in spite of channel definitions being in ~/.config/guix/channels.scm, i.e. not in a profile-specific folder. Don't know what I'm doing wrong here. But it seems like tinkering with profiles opens a pandoras box of sharp edges. <jpoiret>pseudonymous: that's because channel definitions are actually read as part of `guix pull`, that installs a new version of guix with the other channels merged in. <apteryx>civodul: re polkit-duktape; I tried the syntax hack, but it doesn't seem to have worked either? it's probably something silly <jpoiret>by the way civodul, i think libva still needs to be upgraded on core-updates-frozen for hwdec to work (can someone try vainfo with the current version?) <apteryx>roptat: no, it isn't (emacs doesn't assume anything like that since Guix 1.0 or somewhere around that time) <pseudonymous>OK, so in *theory* should be able to compile and run emacs in an isolated profile. <jpoiret>there's no "compilation in isolated profile" <apteryx>pseudonymous: no need for compilation, but yes, that possible now: guix shell -C emacs emacs-magit -- emacs --batch --eval '(print (magit-version))'; try it <pseudonymous>but profiles are separate environments of sorts ? In spite of whatever voodoo is used to share packages across profiles.. Right ? From an end-user perspective, if I cram emacs and some related packages into a profile, I can do whatever in another profile without screwing up anything in my emacs profile, right ? <jpoiret>what change caused a rebuild on c-u-f between yesterday and now? <vivien>jpoiret, civodul merged master into c-u-f a few hours ago <apteryx>jpoiret: also, libgit2 but i took care to rebuild most heavy dependencies on berlin manually yesterday <apteryx>hmm, not sure it impacted them actually <jpoiret>oh, great! that's why most of them were substituted <apteryx>perhaps they were due to the rust dependency trap that goes completely hidden in 'guix refresh -l' <apteryx>(because rust inputs are often passed as an argument, they are not picked up by the tooling) <apteryx>efraim: were you working on a way to normalize this ^ ? <vivien>Do we have problems in guix where the core issue is not the rust build system? <zimoun>How can I fetch the build log from Cuirass? I would like to investigate the failure of julia on core-updates-frozen. <vivien>zimoun, there’s no log if a dependency failed, I think <zimoun>civodul, do you have still locally the build log of the Julia failure? <zimoun>vivien, thanks. I mean, I want var/log/guix/drvs/blabla corresponding to Julia <apteryx>didn't someone have problems login in on c-u-f ? <roptat>the previous only failed with "cannot build missing derivation" which is a cuirass error <jpoiret>ayo guess what. I've isolated the problem <jpoiret>wait until i confirm 100% that it's actually that (and i have a fix ready) <civodul>zimoun: er, nope, i don't think i still have it <zimoun>roptat, yes but “guix weather julia” with the HEAD of core-updates-frozen tells me the substitute is not available. <apteryx>is there a reason the julia test suite takes forever? <jpoiret>what env variables do shepherd services see? <jpoiret>like, do they see the env variables of the current system profile? <zimoun>apteryx, because part of the test suite is sequencial on only 1 core. <civodul>can people try "make as-derivation" on core-updates-frozen, or "guix time-machine --branch=core-updates-frozen -- describe"? <roptat>zimoun, probably it's just not built yet <apteryx>civodul: straight from make: ice-9/eval.scm:293:34: error: %warn-target-field-deprecation: unbound variable <jpoiret>apteryx: you need to remove all .go files <bdju>if anyone feels like polishing up and submitting a package, I worked on a recipe for vimpc a few months ago but never submitted it. installed/ran fine. here: http://ix.io/2WUn <jpoiret>re: anyone know if (and how) shepherd services have env variables set from the system profile <vivien>jpoiret, file-system-service-type in (gnu packages base) uses environment variables in its start command <M6piz7wk[m]>is there a record of new people migrading on guix per day <zimoun>roptat, yeah probably. But I wanted to see if julia-1-6.3 had failed previously on Berlin and check the log. It locally failed for civodul and for me for previous commits. Anyway. :-) <jlicht>civodul: I get what one would expect for guix b15e543 <jlicht>as output for the time-machine command <vivien>Oh, the pypi->guix-package, no wheel test fails with the guix package in core-updates-frozen now <jpoiret>is it okay if linux-libre-headers is not in sync with linux-libre? <vivien>jpoiret, it’s already the case for people booting with linux-libre LTS <jpoiret>yeah i'll have to build 5.14.21 to test my change to gdm <odd>hello. how do I use nouveau driver in gnu guix? <odd>im on gnome, if that matters <apteryx>odd: it's builtin the linux-libre kernel + mesa in Guix System <pseudonymous>jpoiret: following the steps relevant to locales did indeed remove the first error in the output, but emacs ultimately still crashed. :( Thanks though <roptat>pseudonymous, could it be due to $XDG_* not being set correctly? <jpoiret>you may also try the emacs-next-pgtk from guix itself (it has native comp iirc) <civodul>zimoun: you can click on the ID on that page to view the build history for Julia <civodul>vivien: you mean the 'guix' package fails to build because of test failures? <civodul>or maybe you're already looking into it <vivien>civodul, I saw that guix had a substitute so I shrugged <pseudonymous>roptat: not sure what that means ? I opened a new terminal and sourced ~/.guix-profile/etc/profile (It's my understanding this file is generated and contains all env vars I should need). I also followed jpoiret's suggestion and tried installing 'emacs-next-pgtk', same outcome (http://paste.debian.net/1220547/) <jpoiret>mhmmm, that looks like a bona fide bug then <roptat>pseudonymous, you'll need to source the variables from your custom profile too (source ~/.guix-profiles/emacs/etc/profile) <apteryx>civodul: make as-derivation worked on b15e543d303ea58fdc0f0541c708389f9d513e3d <roptat>pseudonymous, what's $XDG_DATA_DIRS for you? <M6piz7wk[m]>6 ppl converted on guix in a day where are my virtual headpats~ <vivien>The problem with your method is they will realize they won’t get get hit by knives if they just stop using guix, so they won’t stay. <pseudonymous>roptat: I ended up first reinstalling the 3rd-party emacs package into the "default" profile (~/.guix-profile -> /var/guix/profiles/per-user/pseud/guix-profile). Then I removed that to install the emacs-next-pgtk package due to some package conflicts. But I've only sourced `~/.guix-profile/etc/profile` atm. <roptat>pseudonymous, ok, then sounds good. Still, what's $XDG_DATA_DIRS? <pseudonymous>roptat: and XDG_DATA_DIRS is probably not set - there's no dirs mentioned which would be part of GUIX. (all system-wide dirs from my native ubuntu install) <roptat>I think this error is because emacs/one of its libraries fails to look a schema somewhere in an XDG_DATA_DIR <jpoiret>emacs launches properly for me without XDG_DATA_DIRS <pseudonymous>roptat: oh, I did that. it was `XDG_DATA_DIRS=/usr/local/share/:/usr/share/:/var/lib/snapd/desktop`, I came across a random discussion suggesting to extend XDG_DATA_DIRS with ${GUIX_PROFILE}/share, so I tried setting that, still crashes (I checked, $GUIX_PROFILE/share is a directory with contents.) <jlicht>problem with a lot of the XDG_* vars is not having them set to anything is to be interpreted in a specific way as well <jlicht>some distros have it set to the default value -> guix extends it properly. If it's unset though, (I had some distros do this to, correctly) guix will set its own thing <apteryx>pseudonymous: did you try using the "emacs" package? <apteryx>perhaps you have 3rd party packages installed from ELPA or such? they may cause issues <pseudonymous>apteryx: very good point to check for. Just tried `emacs -q` (double-checked with man page), still crashes. So at least the init file and such shouldn't be the issue. <zimoun>civodul, thanks. It means julia-1.6.3 has been built only once and it succeeded. Hum? Ok, why not. <roptat>fwiw, I just managed to install emacs-next-pgtk on a foreign distro, it doesn't crash <roptat>XDG_DATA_DIRS is set to ~/.guix-profile/share and system locations <apteryx>pseudonymous: could you run: guix shell -C emacs emacs-magit -- emacs --batch --eval '(print (magit-version))' <apteryx>just to confirm it's something in your environment rather than from your guix itself that's at cause? <pseudonymous>So. opening hordes of terminal tabs to avoid operating in a polluted environment. Only `emacs` (27.2, normal release) has booted. Each time, I open a new tab, source the .guix-profile/etc/profile file and install whichever package I've wanted to test. Before opening a new tab, I also remove the package. So each time, it should be a clean slate. <jlicht>pseudonymous: afaik, opening new tabs does not make a login shell, so I doubt that's a fun way to experiment. guix shell should work better, and does not require new tabs eacht time ;-) <jpoiret>looks like you don't have the latest guix <jlicht>I missed that you don't have guix shell <apteryx>pseudonymous: perhaps try 'guix pull' first <roptat>pseudonymous, you'll need to run "guix pull" and check that "which guix" and "type guix" are ~/.config/guix/current/bin/guix <pseudonymous>jlicht: Well, you say that, but so far. It seems like a lot of things aren't quite working as they should. If things were fully isolated, what I built yesterday on one PC should build and start here. More to the point though, I open tabs to ensure I'm only operating with the most recent contents of the /etc/profile file <civodul>vivien: thanks for the log; i don't get why it failed though <pseudonymous>roptat: did another pull. `type guix -> /usr/local/bin/guix`, installed today via the install script, reported as v 1.3.0 <civodul>zimoun: ah, so there must be a non-deterministic issue <roptat>pseudonymous, is ~/.config/guix/current/bin first in your $PATH? <roptat>did you log out and in again after install? <roptat>(oh, and did you even run guix pull once?) <apteryx>pseudonymous: after the 'guix pull', try logging out and back in or starting a fresh terminal emulator <pseudonymous>roptat: yea, I pulled a few times today. 3 or so. Wrt PATH, nope, I haven't set up the vars in my ~/.zshenv -- partly because all the profile documentation thoroughly confused me. Anyway, in each terminal tab I play with guix in, I start by 'source ~/.guix-profile/etc/profile' which prepends /gnu/store/<hash>-profile/bin to my path <apteryx>It should be from ~/.config/guix/current/bin <jlicht>pseudonymous: one is the guix profile, managed by guix pull, the other is your user profile <roptat>they are different profiles: ~/.config... is the one you get from "guix pull", ~/.guix-profile is the one you get from "guix install" <pseudonymous>soooo.... never source from ~/.guix-profile, always from ~/.config/guix/current ...? <roptat>pseudonymous, no source from both <M6piz7wk[m]>where is the source code for the guix website that slogan is too powerful <roptat>pseudonymous, that's what we set already in /etc/profile.d/guix.sh during install <pseudonymous>Is there some user-experience oriented manual ? I've hunted around the cookbook, but reading the "stable" manual cover-to-cover is an unrealistic expectation and.. I really don't get half of what I'm doing here. I have literally _zero_ idea why both must be read in or in what order. <roptat>pseudonymous, the thing is you shouldn't even have to source from them manually... <pseudonymous>roptat: well then I have no idea how profiles work at all. <M6piz7wk[m]>mfwmyfacewhen: in short you download the iso and `dd if=path/to/iso of=/dev/your-usb-flash-disk status=progres oflag=sync` and then boot it ^-^ <jlicht>if you want to use _extra_ profiles, you do have to source them. The two specific profiles we have been talking about should be taken care of by guix.sh indeed <jpoiret>pseudonymous: i think the Package Management part is a mandatory read <jackhill>Hi, I'm having a little trouble understanding the new swap-space stuff. Say I have a swap file on a btrfs filesystem. What do I put in the dependencies file? It isn't given a name in the file-systems record. <jpoiret>jackhill: you should put a file-system or mapped-device inside the dependencies list <M6piz7wk[m]>yesh~ also you might need the forsaken channel if the machine doesn't run without non-free packages <jpoiret>here, you should have (dependencies (list (the-btrfs-fs))) *M6piz7wk[m] runs to hide so that people doesn't club him to death for saying the n word <M6piz7wk[m]>mfwmyfacewhen[m]: also there is a guix-install.sh that will install guix on your current linux distro <roptat>mfwmyfacewhen[m], you don't have to install the whole OS, if you want to test guix, you can install it as a package manager on any distro you might be running right now <pseudonymous>^ well, in *theory* anyway. The manual really would stand to benefit with an "install & configure on a foreign distro" chapter. <M6piz7wk[m]>well i got your like 9 people overwhelming the channel with questions about how to install guix <jlicht>M6piz7wk[m]: it's kind of respectless to ignore policy and guidelines from 2 communities :/ <roptat>pseudonymous, btw which distro are you using? <jpoiret>yes, although you should re-use the same file-system record as in your (file-systems ...) <roptat>pseudonymous, thanks, I guess we'll have to try and see if there's anything special about ubuntu <roptat>or maybe you got confused by a step and we should improve the manual... <jpoiret>tbh, I was too lazy to factor it out into its own define, so I have the following <jackhill>jpoiret: I guess I'm stuck on figuring out what the-btrfs-fs should be? I guess I'm confused because in my file-systems record I put in in literally like that. I guess I should bind it to a name at the top level? <jlicht>pseudonymous: just for the record, did you 1) reboot and/or 2) log out+log in again? <M6piz7wk[m]>jlicht: they said the same thing to jesus and look where it got us <jpoiret>i could also bind it, but let's just use scheme and guix records :) <jlicht>M6piz7wk[m]: I'm not saying anything to make you feel bad, I'm sharing how you come across to me with some of your behaviour. No value judgement, just something you _might_ want to think of in a rare moment of silence :P <karrq>I'm very much a newbie to guix :) A friend told me to try it (and learn it) because I expressed my desire to have a workflow where each project lives in it's own container that has all the dependencies and tools used during development, so that my main system isn't "polluted" with all the different softwares <rekado_>civodul: all tasks that I considered blockers are now complete (e.g. PYTHONPATH vs GUIX_PYTHONPATH, pigx builds, reconfigure worked, profile upgraded successfully) <roptat>karrq, I think you're in the right place :) *rekado_ runs make as-derivation on laptop <karrq>roptat: awesome! glad to know I can achieve that with guix! I already started installing guix on my system, but had to move to a VM instead fo learn a bit since the setup I want is kinda complex... <pseudonymous>jlicht: I did. That is, I did in between initially installing Guix (8 hours ago or so) and the last two hours or so where I've been spamming this channel :) I did also do `guix pull` before that reboot. FWIW. <jpoiret>I might have a fix for the gdm icons, so apart from libva I think everything's ok on core-updates-frozen for me too! <roptat>karrq, although, it's not really container, but still different profiles you can load and unload (similar to how you can enter and leave a pyenv I think) <roptat>karrq, for this workflow, I'd install guix as a package manager, you can do that on any distro, you don't need the full OS <karrq>roptat yeah the mechanism is fine, what I want is to have these dependencies isolated, and even better if they work wonderfully with TRAMP <pseudonymous>roptat: I ended up making 3 changes to ~/.zshenv to accommodate guix ( http://paste.debian.net/1220559/ ). So, sourcing the .guix-profile profile, prefixing PATH and INFOPATH with references to ~/.config/guix/current. Should I also stick a `source $HOME/.config/guix/current` in there ? and if so, before or after the first ? <jpoiret>I haven't tried, but i think it's going to be tricky making TRAMP work properly with them. Patches welcome of course :) <jlicht>pseudonymous: you do have a /etc/profile.d/guix.sh? If so, just source that one (or do the zsh-equivalent of what happens there) <karrq>jpoiret: so it doesn't work as nicely? what is the issue you were having? <jackhill>jpoiret: what the libva issue? I might be able to test as I sometimes use it, but not every day. <jackhill>(core-updates-frozen is slowly taking over all of my computers ☺) <karrq>roptat: I guess I can installate guix in a "foreign distro" but I also wanted to have a playground to try guix without "polluting" my arch with guix since I don't know enough about it yet! <zimoun>roptat, you should be an Evil emacs user ;-) (Evil is vim bindngs). TRAMP allows to use ’ssh’ and friend transparently. <jpoiret>jackhill: can you just try vainfo with a wayland compositor on c-u-f? <jpoiret>it should error out, because libva needs to be upgraded <jpoiret>the patch is ready but will rebuild a lot though <sifat06>Does guix works on a foreign distro with wayland? <jpoiret>it should, as long as you don't have mismatching wayland protocol versions <jpoiret>if both guix and the distro are properly updated it should work fine <karrq>I'll spare everybody the details, but in short I want to install guix in a (btrfs) subvolume, as technically I already have arch in a subvolume aswell. The problem I'm also facing is that I don't want to use GRUB and currently my bootloader is rEFInd <sifat06>I've recently installed guix on Fedora 35 via install script and installed some packages from there. But when I try to launch any application from wayland, I get this error: <sifat06>(geany:17678): GLib-GIO-ERROR **: 21:25:53.098: Settings schema 'org.gnome.settings-daemon.plugins.xsettings' does not contain a key named 'antialiasing' <jackhill>jpoiret: indeed it does. Actually in the past I've only ever used it with X <jpoiret>karrq: guix-the-os won't work with rEFInd iirc <karrq>(also forgot to mention my btrfs partition is encrypted, that's the actual problem) <jlicht>pseudonymous: yeah; you could even try to source it from an existing shell and see what 'which guix' does; it should be the guix pull'd one <karrq>jpoiret: hmm I don't see why it wouldn't in a normal scenario: you point to loader the same path that is used in grub's config so /gnu/store/base32-system/bzImage and do similarly for the initrd <jpoiret>sifat06: can you try running `XDG_DATA_DIRS=~/.guix-profile/share geany`? <karrq>the actual issue in my case is that refind doesn't handle LUKS partitions (at least not by default, and couldn't find a setting or plugin that had support) so refind can't navigate the btrfs partition like grub does, since grub does decrypt the partition at boot, and it's ubrearably slow for bigger partitions ofc <pseudonymous>jlicht: in an abundance of over-caution, I entered a bash shell, sourced it and now I see `which emacs` being ~/.guix-profile/bin/emacs and `which guix` being `~/.config/guix/current/bin/guix`. That said, emacs still blows up <jpoiret>karrq: the thing is, both the kernel and initrd are stored in the path, and never copied to something like /boot. The `guix system` command automatically generates the proper menu entries for GRUB, which point to the store entries <karrq>yep that's what I figured too.. <jpoiret>also, doesn't rEFInd require an EFISTUB kernel? i'm not sure we have that compiled in, but i might be wrong <jlicht>pseudonymous: one step at a time ;). In the 'working' terminal, what does `guix shell -C emacs emacs-magit -- emacs --batch --eval '(print (magit-version))'` do? <karrq>jpoiret: not sure about that EFISTUB actually <jpoiret>pseudonymous: can you try also running `XDG_DATA_DIRS=~/.guix-profile/share emacs`? <jpoiret>karrq: i'm pretty sure about that, rEFInd isn't a boot loader per se, just some EFI firmware <karrq>so in my system i actually have a separate unencrypted /boot partition (for arch) where my arch linux loader and initrd are located, and yeah, guix doesn't put anything there... so I came here to also ask if there is any way, similar to a pacman hook, to copy the linux kernel loader and initrd to another location after the package is upgraded/installed etc <pseudonymous>jlicht: "3.3.0". It installed a bunch of packages, magic and emacs 27.2 among them. Is this shell thing a throw-away a la what I read about environments...? <jpoiret>oh, but you could just chainload into the Guix-managed GRUB for sure, i'm sorry if that's what you meant <jpoiret>i think that'd be the cleanest solution, if you can spare GRUB some cpu cycles <karrq>jpoiret: yeah I guess? but GRUB still lives inside the encrypted btrfs partition, which refind can't open... <karrq>also you are right: "rEFInd is a UEFI boot manager capable of launching EFISTUB kernels" <jlicht>pseudonymous: guix shell is the shiny replacement for guix environment; basically, throwaway profiles (with caching) <jpoiret>no, GRUB will be installed to your efi partition <jlicht>so extremely useful for debugging and experimentation :-)! Could you still try jpoire_t's suggestion? <jpoiret>this i'm not so sure sifat06, i don't really use gnome and friends <karrq>jpoiret: right, only the config is in the encrypted btrfs... but yeah I don't want that :S 1) i don't want to use grub and 2) grub is slow for the decryption <M6piz7wk[m]>sifat06: see `guix search gnome themes` it outputs few packages with goodies <jpoiret>I agree with you on that point. I'd love to work on having EFIstub options in guix, but for now we're working on the 1.4 release <karrq>I guess I'll keep playing in the VM, figure out how to do many things: 1) compile the kernel with `CONFIG_EFI_STUB=y` since that's EFISTUB support (talking non-libre, not sure about libre) 2) move the initrd and loader image to another location <karrq>I'll have to figure how to make my own kernel package anyways since I need some custom patches for my laptop <jpoiret>it should be the same for libre i think. As to how to move the initrd and kernel, it's going to be a bit of a pain i think <karrq>I even thought I could be reusing the loader from my arch kernel and just switch out the initrd for guix's, but that's probably a recipe for disaster <jpoiret>especially if you're not acquainted with the guix codebase *M6piz7wk[m] hides don't club me for saying the n word <karrq>jpoiret: I don't know if you noticed but I'm pretty much digging my grave and putting flowers all around to get this to work ahha <karrq>jpoired: vmlinuz-linux from the arch install <jpoiret>yes i can see that :) but, other scenario could be: you end up submitting patches to guix to support this out of the box <pseudonymous>So. (so far). Installed emacs-next-pgtk, entered a bash shell, sourced /etc/profile.d/guix.sh, `emacs` -> crash, `XDG_DATA_DIRS=~/.guix-profile/share emacs` .. works! <jpoiret>vmlinuz-linux is simply your kernel. You shouldn't mismatch kernels and initrds, especially from different oses *rekado_ is not in the mood for these antics <karrq>jpoiret: yeah that's what I mean with "recipe for disaster"... so I will need to make my own kernel package for the laptop patches <pseudonymous>And sourcing /etc/profile.d/guix.sh from a zsh shell works as well, provided the XDG_DATA_DIRS var is set.. Oddly, plain `emacs` (the 27.2 package) worked without the env-var or /etc/profile.d/guix.sh sourcing. But it all works. <M6piz7wk[m]>> * <@rekado_:libera.chat> is not in the mood for these antics <jpoiret>pseudonymous: i think that's because with the pgtk branch, you get all the cool "features" (crashes) of gtk and friends <jpoiret>no shade though, that's what i'm using too <M6piz7wk[m]>how else am i supposed to manage your hate against me <apteryx>M6piz7wk[m]: please stop your false accusations <jpoiret>M6piz7wk[m]: please stop, this is getting annoying for everyone here. Keep the discussion on-topic <karrq> jpoiret: yeah I'll be open to contribs after I understand more of guile etc etc, but is there no "pacman hook" or equivalent right now? I mean the whole os is programmable so I thought there was <jpoiret>well, since the whole os is easily programmable, you can just add your own hooks to guix! <jpoiret>personally, I run a patched guix with the patches that haven't made their way into upstream yet, you could do whatever you want <crodges>hello everyone. I'm configuring nginx, in particular, nginx-location-configuration uri. I need to pass a regex to it, precisely ~* ^(\/_matrix|\/_synapse\/client) I translated that to guile (posix) as (make-regexp "~\* ^(\\\\/_matrix|\\\\/_synapse\\\\/client)") and imported (ice-9 regex). But the only thing I get is error: #<regexp 7f89af7c3a00>: invalid G-expression input. How should I pass a gexp to it? <vivien>crodges, I’m not sure you need to convert regexps <vivien>Doesn’t it work if you keep it a string literal? <vivien>(don’t forget to double the \\ since it’s a string literal) <karrq>vivien: it's something found in pacman in arch linux, basically it's scripts run before and after package installs so you can, for example, have all your kernel modules rebuild when the kernel is upgraded, or regenerate the initramfs <karrq>jpoiret: I see, do you have them hosted somewhere publicly? also, as another question regarding the "containerized" workspaces, guix doesn't handle anything that's not in it's package system, right? I'm not sure if it will have everything I need... <vivien>Guix is more functional in the sense that these kinds of side effects aren’t exactly the way to go <jpoiret>I just send them upstream! as for missing software, you could possibly learn how to package it in guix. Often, it's pretty easy to do <karrq>jpoiret: yeah that's what I also thought, gonna have to make packages I suppose :) what's the support for *-bin packages? where you don't build from source I mean <sam_>(I think you could just grab a binary, right?) <rekado_>karrq: it’s possible in some cases by patching the binary <jpoiret>we don't support them upstream, and you'd need to do some rpath patching <sam_>ah, i hadn't thought about that part with guix <karrq>vivien: yeah I'm all pretty new to this, but with hooks it would allow for these side effects that might be more useful in an foreign distro install <jpoiret>don't support as in: guix is source only <rekado_>one thing that will almost invariably be necessary is to patch the linker/loader with patchelf <rekado_>but if that’s all you need to do you’re lucky. It’s usually much easier to build from source. <vivien>karrq, on a foreign distro, guix is only used by unprivileged users, so the usefulness of running system-wide scripts is diminished. <karrq>rekado_: I'm a bit lost honestly... I'm talking about packages that I don't have access to source or simply I don't want to spend the time configuring to be built from source and just grab a binary for my architecture from somewhere else <attila_lendvai>is there a way to build a package with debug symbols? or how else can i get source code into gdb? <rekado_>karrq: I’m just stating that as a general rule it is much easier to build from source than to patch a binary that was built with numerous assumptions that are not explicit and likely won’t be satisfied by Guix. <crodges>vivien: I tried just now like (uri "~\\* ^(\\\\/_matrix|\\\\/_synapse\\\\/client)") without regex function and guix throws an exception when trying to start nginx (I added a extra \ on ~\\*, is that what you mean?) <karrq>vivien: well they don't necessarily have to be system-wide tho, I was just making an example *attila_lendvai has found the relevant part of the manual <fcw>roptat: Regarding TRAMP: Vim's netrw has the same functionality. <rekado_>the linker/loader is one thing that can be worked around, but then you may have to “wire up” all those shared objects that the binary expects to be in “well-known” locations (that don’t exist on Guix). <vivien>crodges, that would be "~* ^(\\/_matrix|\\/_synapse\\/client" <vivien>(if you want ~* ^(\/_matrix|\/_synapse\/client) <karrq>rekado_: oh, I'm very new and I wasn't aware of this issue...where can I read more of these problems? The manuals look a bit sparse, at least for guixSD... for example I personally can't find any documentation for the linux function (as in `(linux linux-libre)` in the os definition) <rekado_>I’ve been through this with an AppImage, which is one of the better starting positions — it’s still a lot of work as all of the tooling Guix provides is for the source->binary step and nothing exists for massaging binaries. <rekado_>karrq: it’s not a function, it’s just a field name <rekado_>“linux” would be a key, “linux-libre” the value (a package object) <karrq>yeah didn't know what to name it <jpoiret>karrq: that's in the "operating-system Reference" part of the manual <rekado_>if you had, for example, a package value named “my-custom-linux” that builds Linux with different options, then you could do (linux my-custom-linux) after importing the Guile module containing the definition of “my-custom-linux”. <sneek>Welcome back nckx, you have 1 message! <sneek>nckx, lfam says: I'm looking at turning CONFIG_GCC_PLUGINS on for the kernel 5.10 package, like we discussed. I was able to do this for 5.15, 5.14, 5.13, 5.12, and 5.11. But the option is not offered with 5.10... Even using `make defconfig` in a 5.10 source tree with the Guix toolchain, this option does not appear <rekado_>karrq: there’s also a blog post on customizing Linux, which exercises all of the mechanisms you would need to learn about. <rekado_>(pretty sure the Cookbook also includes a copy of this article) <karrq>but I meant I don't know what is that I'm passing it, in this case you said the package object... like, what defines a package valid for the "linux" field? at least from the guix manual I wasn't able to find much information :( <karrq>I usually program in rust, and so I'm more used to types. In this case I don't know the "type" of the linux field <rekado_>karrq: “linux-libre” is no different from “emacs” — it’s just a value of the <package> type. <rekado_>you won’t be able to pass (linux emacs), of course, but that’s unrelated to types <jpoiret>aha, you'll have to get used to the scripting nature of Scheme. Very powerful, but lets you do whatever you want even if it's stupid <crodges>vivien: nginx started like that, thanks! I think I got confused with escaping after reading "backslash escapes" in the guile manual <karrq>jpoiret: yeah I'm not totally unfamiliar with scheme and lisps in general :) <jpoiret>damn, I shouldn't have pulled the latest c-u-f changes, I've been building linux-libre related things for the past 2 hours <vivien>The thing is, guix records are "special" in that they are non-hygienic (they define stuff you don’t know about). <vivien>jpoiret, yes, you can use fields defined previously <vivien>(but also, previously defined fields override your local variables) <ngz>Humm, guix pull --branch=core-update-frozen is failing for me. <singpolyma>vivien: that doesn't seem unhygienic, it's scoped to the declaration. Seems more like a let* etc <ngz>With something like: (exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (icu4c-69)) (value #f)) <zimoun>ngz: core-updateS-frozen missing ’S’. I do not know if it is that. <ngz>Yes, I meant core-updates-frozen <vivien>ngz, that’s usually when a channel you use isn’t ready for core-updates-frozen <jpoiret>vivien: but that's part of the macro though, you wouldn't say that lambda* is un-hygienic, right? :) <zimoun>apteryx, yeah but the libgit2 update probably breaks another test of Julia. <rekado_>ngz: can you tell us what you did to get this error? <zimoun>why is it updated? The branch is not “frozen“? <apteryx>zimoun: as you wrote somewhere the julia test suite seems to have lots of nondeterministic failures <jpoiret>ngz: that's because of some other channel <jpoiret>you should use their core-updates branch <apteryx>zimoun: I had a failure yesterday but after it passed... I'd put the blame on julia's tests, not libgit2 <zimoun>apteryx, this one is not ;-) «could not load library "/gnu/store/…-libgit2-1.3.0/lib/libgit2.so.1.1"» <apteryx>not sure why I thought I had it passing then <apteryx>FWIW I updated libgit2 as part of updating a broken python package; and noticed it wanted a newer release. I then ensured the 300 something dependencies of libgit2 could be built (or so I thought). <ngz>jpoiret, vivien: Interesting. That was not obvious. I simply kept default channel, and I can indeed build core-updates-frozen. Thanks. Now I'm checking if my packages are safe. <jpoiret>vivien: hygiene is just about "capturing the local bindings" of the macro invocation, which isn't really the case here <jpoiret>ngz: that other channel has a "core-updates" branch if you still want to use it with c-u-f <zimoun>apteryx, yeah I am sure a good reason was behind. :-) <ngz>I don't use actually use it yet, it was here for testing purpose only. ***unmatched-parent is now known as unmatched-paren
<unmatched-paren>my latest guix system reconfigure failed with a message about swap space... has there been some breaking change? i'm not proficient enough in scheme to understand the suggested workaround <jgart>unmatched-paren, what's the suggested workaround? <nckx>vivien: That is a definition of ‘hygienic’ I hadn't heard before. <nckx>Oh, jpoiret already discussed it further, never mind. <unmatched-paren>'List elements of the field 'swap-devices' should now use the <swap-space> record, as the old method is deprecated. See "(guix) operating-system Reference" for more details.' that's the warning, and then there's an error: 'In procedure swap-space-priority: Wrong type argument: #<<uuid> type: dce bv: #vu8(158 90 78 241 109 93 72 183 187 255 210 110 197 157 188 11)>'. Not sure what a 'record' <unmatched-paren>are they related? neither happened before and they're both about swap <nckx>An object with named fields. E.g. packages and operating-systems and file-systems and many more things are Guix records. <nckx>unmatched-paren: Did you adapt the new syntax? <jpoiret>the error is weird though, maybe i didn't test my code enough teehee <nckx>(package (field1 "something") (field2 #t) (field3 …)) <jpoiret>NB: these are guix records, which are kind of an extension of scheme records <nckx>But as vivien pointed out Guix uses its own flavour of record. However, the basics are the same. They differ only in details. <unmatched-paren>nckx: i get that there's a new syntax, but i'm just not sure what it is <nckx>It should be documented in the manual that came with your latest guix. <nckx>If not, that's a mistake. <jpoiret>oh lord, i just noticed i forgot something in that patch <nckx>That's OK jpoiret. Ping me here with your patch & I'll push the fix right away. <jpoiret>if you use the new syntax it should work properly <nckx>The new syntax is a great improvement, but ideally the old one shouldn't splat. <unmatched-paren>can i make `info` use vi keybindings like `man`? the clunky (imo) emacs C-things are throwing me off a bit *nckx uses emacs but still doesn't like info. <rekado_>civodul: make as-derivation worked fine on my laptop <nckx>From memory, that looks correct. <jgart>would be useful if swap-space specified some types as comments <jgart>like package record and others <nckx>s/as comments/in the documentation/ <nckx>Users should not have to read the code like this. <jgart>It's not clear to me that swap-space-target takes another scheme object or just a string <nckx>I'm looking at the (unrendered, so I might overlook something) manual and I agree, jgart. <jgart>The old API took a string or list of strings? <nckx>Never mind, I was wrong: either a UUID, a @code{file-system-label} or <nckx>I don't actually think these ; string - style comments are a good idea. They just get out of sync. <nckx>And are tedious to update. <nckx>Do records support them? <jgart>I forgot if records support them <jpoiret>I learned that you can put docstrings on macros, but getting them programmatically in scheme is very annoying <jpoiret>i mean, do you read them differently from comments? <nckx>jgart apparently looks up the code of things they use, which is great, but not common, and while it's something we should encourage, I don't think ‘because the docs are lacking’ is a right reason. <jgart>janet supports them as the main way to look up documentation <nckx>I know you two are in love but forgot what it was. <jgart>I think it's a good practice <jgart>I prefer to just see some docs in a repl than open an info manual <nckx>I agree they are much better than comments. <nckx>In the situations in which they are. <unmatched-paren>'extraneous field initializers (swap-space)'... has the positioning of the field changed or something? <jgart>I definitely prefer docstrings to comments <bdju> https://waifupaste.moe/raw/pfb got a gajim build failure. `ImportError: Failed to import test module: gajim_mocks` `ModuleNotFoundError: No module named 'gajim.gui.emoji_data'` <nckx>unmatched-paren: That sounds like you wrote (swap-space …) on its own. <jpoiret>uhm, it should be swap-devices, did i write swap-space somewhere in the docs? <nckx>unmatched-paren: The field is not called swap-space but swap-devices. It takes a list of swap-space records. <nckx>(swap-devices (list (swap-space …) [(swap-space …) …])) <nckx>Barring typos either in the current implementation or my brain. <jgart>how easy would that be at a repl? <unmatched-paren>jgart: i'll keep ,h in mind for the next time something goes wrong :) <jpoiret>,help describes commands, ,describe looks up docstrings <jpoiret>and last time i checked, ,describe doesn't try to look up macro docstrings, which is a shame <jgart>it's also a shame that everything doesn't have docstrings in guile that can support them <ngz>Ah :( Asymptote fails for me on c-u-f with "guix package: erreur : entrée corrompue en restaurant l'archive depuis socket"... <jgart>there's many functions that are in the public API that are missing docstrings <nckx>jpoiret: Pushed as d48b404cf577cbfcd29b294e193a4db0c3e580b1. I'd be much obliged if you could close the bug for me. <jgart>and even if they are trivial for some person they might not be trivial for a beginner, for example <jgart>janet still has docstrings for things like first, second etc... to be consistent <nckx>There is no reason not to have them in Guile. Triviality doesn't convice. <jgart>does not make sense to return false <jgart>I think the repl feedback there should be better <jgart>I started working on some docstrings in guile on a branch but haven't submitted them yet <jpoiret>closing is just ccing XXXX-done@debbugs.gnu.org right? <jgart>can someone close a bug without commit access? <ngz>Ewww "Testing Ghostscript...dvips: ! Couldn't find header file: l3backend-dvips.pro" <ngz>Unrecoverable error =/ <ngz>Hmmm, something's fishy in texilive… <unmatched-paren>what's term-auto? every time i guix system reconfigure, shepherd reports that it couldn't be started <drakonis>you're not the first person to ask, maybe we need to put a sign in the wall <jgart>drakonis, or cookbook or manual entry <jgart>Is anyone interested in attending guix docs maintenance meetup? <jgart>roptat had suggested hosting one <roptat>end of december is probably not the best time :p <jgart>This Saturday is the guix packaging meetup though that I usually host <jgart>I'll have to consider that for next month <jgart>Even this month is complicated because of Thanksgiving <jgart>What time of the month would be good for people to attend a docs meetup? <jgart>If anyone is interested in organizing that with me I can list you on the form or you can also just attend <jgart>It will just be the usual meetup but at libreplanet 2022 in april <jgart>libreplanet 2022 is online :) <jgart>Maybe that can be a docs meetup ha <jgart>cool! Would you like me to list you? I'd just need to put a name and email. Name can be your username or however you prefer <jgart>If you're not able to for whatever reason later it wouldn't be a problem either <jgart>I'm going to try to invite a few people for that event. I think the session would be about 90 minutes. <jgart>which is about what we do usually anyways <lfam>jgart: It would be really cool to host some kind of Guix meeting around Libreplanet. Or any other US-based event <lfam>I've long wished for that <lfam>I suppose this would be online only... in the future an in-person meeting would be doubly valuable <lfam>What value should I use to rewrite a header include "/usr/include/linux/magic.h"? <lfam>Would I use <linux/magic.h>? <sneek>Welcome back unmatched-parent, you have 1 message! <jgart>This is kind of what that is. We're going to meet and work on some packages and onboard new people. It won't be like fosdem in the sense that I won't be giving a presentation on Guix. I'm hosting workshop on packaging/maintenance. We'll pick something to work on and spend some time working on it together in the session <jgart>lfam, are you interested in joining us at LibrePlanet 2022 for the packaging meet? <lfam>In principle yes... I can't really plan that far ahead yet <lfam>I recently moved and I'm still figuring out my work situation <jgart>I could use some guix veterans in the meetup/workshop :) <jgart>We might break up into groups if the communication medium allows for it <lfam>I agree it would be valuable to have a range of experience <jgart>drakonis, There's one this Saturday at 2PM ET <jgart>I'll announce on guix-devel shortly <vivien>I’d like to reconfigure my system (on master) and reboot, but when I reconfigure, I get grub errors <jgart>This Saturday is not the LibrePlanet one but it's just another one. I do one every month <vivien>** Warning ** : Boot001a is not UEFI Spec compliant (lowercase hex in name) <vivien>** Warning ** : please recreate these using efibootmgr to remove this warning. <vivien>Could not prepare Boot variable: No space left on device <nckx>The warnings are not related. <vivien>I don’t understand the "no space left on device", df -h shows I still have 1.9 GB of free space on /boot/efi <nckx>vivien: Everyone always runs df /boot or df /boot/efi when they get that error :) <nckx>As it says, you're out of space for boot variables. This happens… surprisingly often? I think it's due to buggy firmware. You can list boot variables with efibootmgr, and delete ones that look bogus/unnecessary with -B. <jpoiret>isn't that more something about efivars instead? <nckx>efivars is the virtual file system that exposes these things. <nckx>I doubt it emulates or exposes available space though. *nckx doesn't have UEFI anymore. <vivien>Mmh I see a lot of things, but nothing guix related <jpoiret>ok so I have a more or less not ideal patch that does fix gdm icons. I'll send it because I don't know how we could do it better anyways (see the current situation for XCURSOR_PATH in gnu/services/xorg.scm for gdm-shepherd-service) <nckx>There should be a Guix entry (or, that's what grub-install is trying to create). Don't delete that one. <nckx>If there isn't one, well, no chance of that happening. <jgart>roptat, lfam, drakonis I'll start preparing a list of good candidate tasks, be it packaging, updating, docs, etc... that we can work on together at LibrePlanet 2022 online <vivien>When trying to delete one, I get: Could not delete variable: No space left on device <vivien>I do guix shell efibootmgr -- efibootmgr -B -b 0003 <nckx>Reminder that computers hate you and want to kill us all, they just lack little hands to pull the trigger. <nckx>I think the -b is superfluous. <jgart>If anyone else is interested in joining just reach out here or email me <nckx>But it might be harmless and then I can't say how to continue. <jgart>You can find my email if you search in the commit logs <vivien>If I omit "-b" (guix shell efibootmgr -- efibootmgr -B 0003) I get: You must specify an entry to delete (see the -b option). <nckx>Every time I had this error, it was annoying as hell to get rid of. <nckx>vivien: I eventually managed to remove entries like (fictional) ‘IBM Enterprise Super Boot Manager’, ‘Floppy’ (on a laptop without one), ‘CD-ROM’ (on a laptop without one), ‘HDD 2’ (etc.), … ***unmatched-parent is now known as unmatched-paren
<nckx>And they will kill us all. <nckx>They just have the patience of those without organs. <jgart>the scary thing is the computers that are dogs <nckx>‘Dogs.’ Feckin headless hell-hounds. <unmatched-paren>the scary thing is that there are devices that can compute the value of 49382299 * 82918 in milliseconds at all, really <jgart>proprietary software dogs with an open face ready for the government to insert a propietary weapon into <nckx>vivien: Are there dump* files in /sys/firmware/efi/efivars/ ? *nckx has kicked unmatched-paren from #guix. <vivien>nckx, yes, a few dump-type0-n-... <nckx>I am like 97% certain that's safe. <nckx>(More, but standard disclaimer still applies.) <vivien>I have already reached acceptance that I’ll have to reinstall the system tonight <nckx>It does not care one whiff about what you do or don't install. *dstolfa needs a reinstall every 6 months or so because he installs a ton of garbage which then breaks on updates <nckx>Let slip the dogs of joy! <vivien>I’ll see if the swap file works :) <nckx>lfam: Have you tried explicitly LDFLAGS=-Wl,-rpath=<somethings>? ***Myrcies is now known as myrcy
<roptat>this seems to be the issue: /gnu/store/4xx9v8qvc3n9pqml3qp4ss2nan6f3b6f-libgit2-1.3.0/lib/libgit2.so.1.1: cannot open shared object file: No such file or directory <zimoun>indeed, something is wrong libgit2-1.3.0 thus libgit2-1.1.0 should be added. <roptat>right, I have libgit2.so.1.3, but not 1.1 <zimoun>roptat: yes, apteryx updated libgit2 with e0e23164202ad9328ffeadde5e900857cb008124 and something breaks. <rekado_>I haven’t reinstalled in many years. <rekado_>builds of the r-updates branch are stuck <zimoun>rekado_: yeah the build farm seems having hard time :-) <unmatched-paren>there are some rust packages that depend on the existence of a `cc` binary... is there something like `alternatives` for guix? <apteryx>zimoun: was that dlopen call already patched? <zimoun>apteryx: julia has a phase add-after 'unpack 'prepare-deps which tweask LD_LIBRARY_PATH <unmatched-paren>i guess i could link ~/.guix-profile/bin/gcc to ~/bin/cc (~/bin is in my PATH) <civodul>zimoun: as a modest contribution, i re-added libgit 1.1 on c-u-f so you can check whether that makes Julia happy <lilyp>unmatched-paren: you can do so slightly better with gexps: <lilyp>see `info "(guix)The Store Monad"' for a detailed explanation <apteryx>I guess passing it libgit2-1.1 is the correct solution to this problem <zimoun>apteryx, thanks for checking upstream. I missed this. <lfam>I'm used to packages needing $out/lib added to their runpaths. But not for every dependency to be added <lfam>It's weird that this stopped working <unmatched-paren>was there ever any progress on upgrading rust to 1.56.1? if not i might try since i have some experience with rust. i hope it won't take five years to build... <jpoiret>@whoever works on gtk/glib: shouldn't we wrap all programs that use gdk-pixbuf with a GDK_PIXBUF_MODULE_FILE pointing to the package's own loader cache? the current profile hook seems pretty lackluster imo, unless there's some good reason for it to be that way <nckx>jpoiret: I meant to be helpful in a hurry but only managed the hurry. That link was supposed to point 2 lines higher as in ‘yes, and more, watch out’. <apteryx>jpoiret: GDK_PIXBUF_MODULE_FILE takes only a single value, which for our wrapper would currently mean "exact" <apteryx>so it wouldn't allow people to add more gdk loaders to their environment to be dynamically selected at runtime <apteryx>(if it was exactly wrapped that way) <apteryx>I mentionned here before that it could be nice to have a way to set a default, but overridable single value with our wrapper <jpoiret>but you could technically still use each package's own loader cache, right? <jpoiret>i'm saying that because in gnome-shell's case, it might be possible for it to be used by the system services while not being brought in the system profile <jpoiret>so there's a possibility that there are no gdk-pixbuf loaders in the profile, and you can't use that <apteryx>there's an imperfect search path for that purpose; imperfect because being a single valued variable, the first encountered match will be used. Also imperfect due to bug #22138. <zimoun>apteryx, yeah on my machine it is ~2h. And on Berlin, the last build took almost 3h. <apteryx>they seem to run their tests with the args: 'bin/julia', 'rr_capture.jl', '6449', '99f655894b', 'bin/julia', '-e', 'include(joinpath(Sys.BINDIR, Base.DATAROOTDIR, "julia", "test", "choosetests.jl" <zimoun>apteryx: yeah, that something to investigate. Thanks for the pointer. <jpoiret>alright, just sent the patch for the GDM icons :) <lfam>Huh. So, Audacity 2.4.2 creates an ELF binary with a RUNPATH. Whereas Audacity 3.0.2's ELF instead contains an RPATH <lfam>I guess that one takes precedence <lfam>And in practice, they are not the same thing to Guix's validate-runpath phase, since it doesn't appear to look in RPATH <jonsger>does someone know why the CUPS webfrontend at localhost:631/admin is so extremly slow? <jpoiret>oh my bad, I thought it detailed the difference between RUNPATH and RPATH, but i remembered wrong it seems <lfam>It's annoying that `guix build --no-grafts foo --log-file` almost never works anymore <lfam>I get a log file about substitutions, nothing related to building <jonsger>its 120s (not ms) for the initial GET request ^^ <apteryx>it could be because of manually building things off berlin, perhaps? <lfam>We should stop doing that regardless but it's so convenient <lfam>It would be great to have another fast server that we can use to test expensive builds <apteryx>lfam: I've reported something like this in #51728 <lfam>Indeed, I participated :) <lfam>I think the discussion got side-tracked... the security objections could easily be overcome <lfam>For example, give each user their own KVM virtual machine <lfam>Good enough security considering the use case <lfam>Although, I would prefer to log in directly than to offload <lfam>But, anything would would <lfam>In practice, the status quo is worse <lilyp>lfam: guix does not check rpath? <lfam>I think it checks RUNPATH <lfam>Which is different from RPATH in an ELF <lilyp>I think it checks whichever is given <zimoun>apteryx, civodul: all seems fixed about Julia. A last check tomorrow moring with fresh eyes and I send patches. <zimoun>apteryx: I will give a look if the test suite can run faster :-) <apteryx>zimoun: now testing with JULIA_CPU_THREADS <lfam>lilyp: Are you sure? The docstring of validate-runpath only mentions RUNPATH <lilyp>Hmm, there's definitely some black magic going on there <lilyp>it appears it's only checking RUNPATH, but adding stuff with -Wl,-rpath makes it visible to the check <lfam>It may be that -Wl,-rpath affects RUNPATH, despite its name. I don't know <jlicht>python-scikit-learn seems to be segfaulting on c.u.f. *lfam Tries to understand validate-needed-in-runpath in (guix build gremlin) <lilyp>that's the most likely cause, yeah <lilyp>I think there is some documentation on the GNU ld side worth looking into <lfam>I could also misunderstand... I've never looked at this code <jpoiret>validate-needed-in-runpath definitely checks the RUNPATH, not the RPATH last time I checked <jpoiret>maybe ld's -rpath does affect RUNPATH instead of RPATH <lfam>I guess that RPATH is considered to be "the wrong thing" to use <lfam>But they couldn't afford to change -rpath <jpoiret>yes, it overrides LD_LIBRARY_PATH, whereas RUNPATH doesn't *vivien still wonders what the details for the gdm icons issue are <jpoiret>I could send a follow-up mail if you want some explanation <vivien>Maybe you did explain it earlier but I had some trouble rebooting <lfam>jpoiret: No, I don't need an explanation <lfam>I guess it's okay to skip validate-runpath for these new versions of Audacity, at least for now <ngz>When trying to build Asymptote on c-u-f, I get the following error during check phase: "Testing Ghostscript...dvips: ! Couldn't find header file: l3backend-dvips.pro". Does that ring a bell somehow? Are we missing out a LaTeX package? <jpoiret>the gist of it is: icons are loaded through gdk-pixbuf. This library has a notion of loaders for various formats, which are themselves shared libraries loaded at runtime by gdk-pixbuf. SVG is one format supported through librsvg, which then provides a dynamic loader to gdk-pixbuf. In order to see those loaders, gdk-pixbuf usually looks into <jpoiret>/lib/gdk-pixbuf-***/****/loaders.cache, but because we're on Guix, we need to set that to something else. That's where GDK_PIXBUF_MODULE_FILE comes in, specifying the proper loaders.cache file. It's usually handled through a search-path, but since gdm is launched through shepherd, you need to pass it the variable "by hand" (no profiles are <vivien>ngz, I had a very similar issue with the unison manual *unmatched-paren is still being tormented by a horrendous python dependency chain because of a package that demands to use an exact version of python-httpx <jpoiret>better yet: the gdm GUI is not actually handled by GDM, but rather by gnome-shell itself, so we need to pass the variable to that session launched by GDM (yes GDM launches its own GUI through the same mechanism as any other session), thus the patch to pass it th env var <ngz>vivien: Oh, I hadn't realized latex-l3backend was in the repository. <ngz>vivien: Ok, I'm going to add this, thanks <jpoiret>and finally remove gnome from my system <roptat>hm? what happened? why am I building icedtea on master? <apteryx>jpoiret: thanks for explaning the adventure (and resolving the issue) :-) <apteryx>zimoun: bah, JULIA_CPU_THREADS doesn't seem to help, although the code suggest it should <apteryx>I still see (1) as the number of workers in the test suite (for every test) <jpoiret>i'll be moving on to more productive things (that issue had been bugging me way too much, I wanted to resolve it before 1.4) <M6piz7wk[m]>Is there a way for emacs to submit multiple patches at once through email? Like if i need to submit 8 rust things to build 1 rust thing but keeping them separate merge requests? *M6piz7wk[m] is doing time management <zimoun>apteryx, thanks for checking. Well, the way the tests are invoked appears to me promising. :-) <lfam>M6piz7wk[m]: If those 8 things are needed for the 1 thing, then they should be submitted together, right? <lfam>It's a single submission? <M6piz7wk[m]>i did single submission and ppl told me to submit that as one package per request so trying to figure out how to do that wihout too much effort <lfam>Can you share a link to that discussion? <jpoiret>if you have one commit per package, you can just `git format-patch` (or use W c in magit) to create one patch per commit, and then send them using `git send-email` <jpoiret>read both manuals beforehand though, as they have a bunch of possible options *M6piz7wk[m] goes to figure out the SMTP then <jpoiret>i suggest using msmtp as a good sendmail-like program <lfam>It's not really about "one patch per package". Looking at your cargo-make.patch file, there are changes to a lot of packages, but I think they are all cosmetic? <lfam>Oh, later I see all the other changes <M6piz7wk[m]>oh right i forgot to link the discussion here.. ehh was told to do that here <lfam>When you are adding new packages, in general, each new packages should be made in its own commit / patch <lfam>However, if all the new packages are part of the same project, then you should send individual patches to the same bug tracker ticket, so that people can review them as a whole <M6piz7wk[m]>just needed to know if emacs does that painlessly so that i can figure out the smtp for git sent-mail to make that more comfortable env <lfam>Otherwise, your work will get lost and nobody will be able to review it effectively <lfam>It's a question for Emacs users <lfam>However, it is painless if you've committed your changes accordingly. Like, one commit per "logical change" <jpoiret>you should send your patches using git send-email imo. You can format the patches easily using magit though, with W c in the magit buffer *M6piz7wk[m] didn't know how to explain the way guix does that in #emacs x.x <lfam>Then you can do, for example, `git send-email --to $NUMBER@debbugs.gnu.org --thread=shallow origin/master` <vivien>M6piz7wk[m], I usually send one mail with all patches as attachments <ns12>M6piz7wk[m]: Isn't the Guix development process similar to the one used by Emacs? <lfam>It's not required to format your work in this way, but it will increase the change that somebody reviews it <lfam>vivien's method works too <M6piz7wk[m]>vivien: i was more thinking using one branch per package and then sending all of them into a separate thing as i assume that my packages will need fixing prior to merge <lfam>What I do is one branch per-project. <lfam>So, if I want to add package foo, and it depends on some other new packages, all those changes are on the same branch <lfam>That's working with Git, not against it :) <lfam>If you split your project across multiple branches, Git won't help you manage your project <apteryx>civodul: have you used offloading since the libgit2 upgrade? I get machine hostname resolution failure, I wonder if some behavior of libgit2 changed ***zava1 is now known as zava
*M6piz7wk[m] is too used to working with gitea to just push all branches and then press few buttons in the webUI to submit the changes >.< <vivien>civodul, apteryx, when I do offloading, I get: guix build: erreur : integer expected from stream <vivien>Oh sorry silly mistake on my part, that’s on master <apteryx>is your host now running core-updates-frozen? <vivien>I’m running core-updates-frozen on this machine, but still master on my server. I’m trying to reconfigure to c-u-f though :) <podiki[m]>what do you mean? flatpak works on guix (e.g. get those pesky js element applications) <podiki[m]>I'm seeing a potential libsoup error on trying to download updates, though pretty sure it worked very recently <apteryx>zimoun: that's silly: @env JULIA_CPU_THREADS=1 $(MAKE) $(QUIET_MAKE) -C $(BUILDROOT)/test all JULIA_BUILD_MODE=$(JULIA_BUILD_MODE) <apteryx>that's why setting that var doesn't work <jpoiret>because it's not guaranteed that the system profile has any gdk-pixbuf loaders in it (it's often the case because of network-manager being pulled in via profile-service-type) <jpoiret>and we generate loaders.cache per package as well <samplet>Huh. That makes some sense. I’m surprised at how complicated it all is. :S <jpoiret>what i'm not happy with is that we should rather be wrapping gnome-shell itself with the needed env variables <jpoiret>the fact that loaders can be configured at runtime is kind of useless on guix to be honest. If a user wants to add a custom loader, they can just rewrite the gnome-shell package for example <zimoun>apteryx, in the meantime, do we patch Makefile by a snippet in ’origin’? <apteryx>I'm patching it in a phase called 'enable-parallel-tests, where I also set JULIA_CPU_THREADS following (parallel-job-count) <ryanprior[m]>Anybody looked recently at using Guix to produce Flatpak-installable software? <ryanprior[m]>I have a growing feeling that will be one of the most impactful ways we can make Guix software accessible to more people. Flatpak is growing a large user base that cuts across distros and platforms. <apteryx>jpoiret: perhaps it's OK to wrap a few key programs with the GDK_PIXBUF_MODULE_FILE; if they are problematic <jpoiret>I was on the fence about it. I'm open to that solution too, it could even be the better one in the long run <apteryx>my motivation adding this was fixing problems encountered at the profile level when there was (problematic) propagation of both gdk-pixbuf and (feu) gdk-pixbuf+svg <apteryx>for that we still need a profile hook <podiki[m]>ryanprior: there was recent discussion about making appimage as an export, on the mailing list (devel I think) <ryanprior[m]>I saw that, I don't know how much appimage and flatpak have in common but maybe I should learn. <apteryx>jpoiret: ideally though, we'd have an overridable GDK_PIXBUF_MODULE_FILE variable, to allow people to tinker if they want to <jpoiret>what are the uses for end-users though? I'm more inclined to say "if you want a new loader in eg gnome-shell, just rewrite gnome-shell to have that loader as a dep and it'll be brought into its own loaders.cache" right? <apteryx>we can't predict in advance; it could be for debugging something. It's similar to having a working LD_LIBRARY_PATH <jackhill>podiki[m]: I'm also seeing "cannot fetch over http" errors with flatpak on core-updates-frozen. Don't know that I've fetched stuff since switcing and instead used to allready downloaded applications. <jpoiret>i guess. Well, i think that patch will do for now <civodul>apteryx: re offloading, you mean libgit2 or libssh? <samplet>jpoiret: At first I was like “there’s gotta be a better way!” but now I’m starting to feel like the patch is the best we can do for now. :) <civodul>libgit2 isn't used for offloading i believe <civodul>lately i've been using GUIX_DAEMON_SOCKET=ssh:// more frequently than offloading <civodul>vivien: re your offloading error, did you check "guix offload test"? <vivien>civodul, offloading works, but substitution does not <jackhill>ryanprior[m]: what little I know is that flatpak and appimage share some goals, namely user-scoped installers desktop applications. I think the methods they use for doing it are different. Flatpak uses some ostree/layered filesystem tricks from CoreOS and Fedora Silverblue. Appimage packages everything up into a single file. Flatpak does some sandboxing/permissions which is pretty neat. I think it would be <jackhill>neat to produce both formats from Guix and perhaps borrow the flatpak permission to be able to sandbox guix-installed apps. <zimoun>civodul, thanks but I did nothing. apteryx does. :-) <vivien>Some substitutes make that error, some do not <ryanprior[m]>Flatpak's "portals" concept seems like a nice abstraction for managed connections between sandboxes, if we could support that in Guix containers that would be sweet. <ryanprior[m]>And I'd love to create something like a whole Flatpak remote with desktop software built from Guix but installable by anybody with the Flatpak runtime. (Including Guix itself??) <podiki[m]>jackhill: are the errors "This version of ostree was built without libsoup or libcurl, and cannot fetch over HTTP"? <jackhill>ryanprior[m]: yep, both things would be great! <podiki[m]>I get the error when doing a "flatpak --user update", fairly certain I've done that on c-u-f before though <jackhill>c-u-f f42bc604547d9ee8e35fcd66d5db7786954cfac3 <podiki[m]>okay same error, tried building with a new libostree just in case, same error <podiki[m]>I wonder if it is because libostree is libsoup3 and flatpak is not :/ <ngz>vivien: Unfortunately, adding texlive-latex-l3backend to native inputs didn't help =/ <vivien>ngz, you need to add a texlive-updmap.cfg <vivien>containing your texlive packages <ngz>It is already there. <vivien>For unison, I needed texlive-dvips-l3backend <vivien>civodul, for instance, substituting /gnu/store/9588499q260ghan2p1aa63af3z7kfd7h-bash-completion-2.8 fails <vivien>But I don’t know which .drv it comes from <jackhill>so it almost seems like libostree doesn't even support libsoup-3 and not just a conflict with what flatpak expects. <jackhill>Do you want to try changing it our shall I? <ngz>vivien: Ok, apparently, my c-u-f was not up-to-date. Trying again. Thanks. <podiki[m]>jackhill: oh, nice catch, probably needs libsoup-minimal-2 also <podiki[m]>I think you are right, the configure is for 2.4 <podiki[m]>I guess since it has options for no libsoup in the code, this is not a failure <jackhill>right, I guess all users of libostree don't need network access <podiki[m]>should be a very quick change, check (rebuild flatpak, see configure in libostree, try flatpak update) for a patch <podiki[m]>i'm trying to quickly check the build but won't be able to submit a patch for a couple of hours, so if you have the chance now I say go for it <jackhill>I'm about to take a dinner break, so won't be able to get to it for a little while either <podiki[m]>jackhill: good spot in the log, and more to the point it'll show "HTTP backend" as none, but with libsoup-minimal-2 shows libsoup there <podiki[m]>confirmed that does it, flatpak can then update 
