<raghav-gururajan>Even in FHS, if I talk about a file inside /bin. You will know that we are talking about a binary. *nckx was typing the same thing in a slightly smilier fashion but, yeah, it kind of is. <leoprikler>It would be somewhat more consistent if you were saying something about the physical size or weight of 8GB of data, but putting binary files into /bin is just a convention made up by people. <nckx>link2xt: (Nonexistent) trolls can be banned. In between those extremes, it's open. <leoprikler>in the first place, it's not even limited to binary files <leoprikler>many programs install uncompiled script files into $prefix/bin <link2xt>nckx: k, I sent a patch but didn't see it in HTML archives, guess it is on moderation then <raghav-gururajan>"Standardization can help maximize compatibility, interoperability, safety, repeatability, or quality." <leoprikler>link2xt: you get a message once your post has been accepted <nckx>raghav-gururajan: Your position is ‘standardisation == good’ and that's a very valid position to hold. However, posting Wikipedia links and using ‘standardisation == good’ as an *argument* for that position won't convince anyone. It's ‘x because x’. <nckx>link2xt: The ‘problem’ is that we (Guix) don't moderate the (GNU) bug tracker. So neither of us can do more than wait. <raghav-gururajan>nckx I am not sure how to explain in other words. A use of a standard is found within the deifintion of a standard. <nckx>raghav-gururajan: ‘Standardization can help…’: It can also ruin just as many things. I honestly want to know: how will it help, and what exactly would that standard standardise and how? <leoprikler>From what I can see, there are already just a few profits of using /gnu inside of guix, those being repeatability and quality (the latter only if you count substitutes). <nckx>raghav-gururajan: I could say that the Guix standard is documented by the code (that's not a joke: LISP was created to document algorithms on paper, first, then made executable). <nckx>Anything that wants to be Guix-compatible will have to follow the code, not some standard.md somewhere, anyway. <raghav-gururajan>nckx Ah yes, I was outlining how standards can be useful and need not be static. For a specfic use cause, of course there needs to be details. <leoprikler>Using it beyond Guix does not even guarantee that, because one would have to write guix compatible packages anyway. <leoprikler>So realistically, your standard compliant™ Guix alternative is going to be a glorified importer/channel/whatever else you can cram into a front-end. <nckx>Your compatible package manager in the language of the yea^Wages really will be guix.rs, not commonfunc.rs or r6rfpm.rs or whatever. <leoprikler>plot twist: it's interpreted by guile's ECMAScript front-end <nckx>Available exclusively through npm. *nckx ‘language of the ages: JS’ isn't funny because of the depressing possibility that it might prove true. <nckx>We heard you like running untrusted binaries from the Web so we made the Web an untrusted binary. <nckx>Our opinions are obivously sane and must be seriously considered also give us tax breaks. <leoprikler>A standard™ for bytecode to be sent over the internet to be ran by browsers. <nckx>You can have the malicious bytecode created with a compiler you love. <raghav-gururajan>nckx So I upon reboot, sdcard's file-system was automatically mounted under /home/user/sdcard. The permissions of /home/user/sdcard were root as owner and group. I have changed to username as owner and users as group. Will this be conserved across reboot? <nckx>Well, bootstrapped at least. <nckx>raghav-gururajan: It should. Test. <nckx>We hope you've enjoyed your free news articles for this month. Please give us PCI GPU passthrough permissions to continue reading. <nckx>(Don't worry drakonis! They won't actually ask for permission.) <nckx>Your experience will be seamless™. <nckx>PotentialUser-74 wtf'd right back out of here. Sorry. <cbaines>sneek: later tell civodul: I spotted those issues with the Guix Data Service, I think the problem is related to the handling of duplicate package definitions (same name and version). There's code in the Guix Data Service to deduplicate the definitions, but I think a lint warning for a duplicate is leading to the error shown. <apteryx>excuse my ignorance, but how is the information stored in ~/.guix-profile/manifest useful? Shouldn't it keep a list of just package symbols, as well as their provenance (e.g., which Guix commit they originate from)? <apteryx>OK, the output and version have a use, I can see that <apteryx>as for the propagated inputs and search paths this seems redundant if we know the provenance <nckx>apteryx: Both propagated inputs and search paths of all installed packages are needed to create subsequent versions of the profile, potentially for years to come if you never upgrade (a) certain package(s). There's no alternative than to save them along with the profile. <apteryx>nckx: but all this information is available within and pegged to a Guix commit, no? I mean, it could be simply recomputed (with some processing cost, of course) <apteryx>ah... mixed Guix version provenance (partial upgrades) could be costly (you'd need to run the search possibly multiple Guix inferiors) <apteryx>but still feasible. I'm asking, because I'm toying with the idea of extending search paths so that you could run arbitrary, thunked Scheme to do things we can't imagine you'd need to do today (well, I can imagine a few scenarios already useful: special ordering of the paths, filtering, adding an extra separator which has some semantic for some program, etc.) <apteryx>but having to serialize this (and keep track of its dependencies -- perhaps Gexps should be used?) in a format like what is currently used seems problematic <nckx>‘Simply recomputed’ and ‘some processing’ are at best misleading, but you probably realised that by now 😉 <nckx>It's also beside the point, since it doesn't actually sound feasible. What would you do with this provenance data? <nckx>You care about the code, not the deleted git repo it came from a year ago. <nckx>Serialising locally sounds like the way to do this. <nckx>Why's it problematic? Assuming extension is something we want (I remember reading about your idea but not all the details), perhaps we could find a solution. <nckx>As much as I like first-class functions this would be a very powerful can of worms 🙂 <PotentialUser-52>can I user a radeon rx 580 with guix? I see "modprobe.blacklist=radeon" in the installer's grub entry, and booting without modifications gives the error "error in finalization thread: Bad file descriptor" <nckx>PotentialUser-52: I don't know the answer to your main question (no AMD hardware here), but that blacklist argument is specifically to make the installer work and won't be needed on the final system, and the ‘Bad file descriptor’ is unrelated and harmless (happens to everyone). <nckx>Many recent AMD cards require firmware though. <PotentialUser-52>question about the install: if I choose the graphical install... can I disable substitutes before I start the install? <apteryx>nckx: well, the provenance data would be used to yes, aehem, refetch the repo if it's not locally cached already, rebuild it and use it to recompute the missing data. <nckx>apteryx: But what if it's gone (not unlikely), moved (certainly not unlikely), or never had a provenance to begin with (~/apteryx/teststuff.tmp/guix)? <apteryx>my current use of manifest is bound to package -m 'some-manifest.scm' to install the packages within. As far as I can tell, this also dependes on having Guix at the version noted in the provenance properties to rebuild the packages, no? <nckx>PotentialUser-52: Ah, super! Radeon model numbers mean nothing to me. <nckx>I always install manually so I don't know about the substitutes. <nckx>That's a good point actually. <PotentialUser-52>I'm at the end of the install... I'll try "exit" to see if it added /etc/config.scm <PotentialUser-52>nah, can't get out of the installer. exit/abort just routes back to the start. C-c does nothing. <PotentialUser-52>would be great to edit /etc/config.scm + get a shell before kicking it off :) <PotentialUser-52>in lieu of that.. is there a way to rebuild after the fact with substitutes? or guix challenge everything (assuming that means what I think it means)? <apteryx>nckx: I can manifests + guix archives would be the deal to ensure you can reproduce a profile somewhere else in the future <nckx>apteryx: Yess… but that's user-generated, I don't think you can compare the two. You're telling Guix where to find something that it can't find without your help. OTOH stale ‘provenance’ info (I don't even like using the word here, can you tell :-) in the auto-generated manifest will break guix package -u/-i/… forever. <nckx>I really don't think the two files are even related apart from the unfortunate choice of ‘manifest’ to label them both. <nckx>apteryx: OK, but now you're talking about user manifests. <nckx>That was sent before your last line 🙂 <nckx>The naming certainly doesn't help. <apteryx>nckx: Doesn't 'system' manifest need to keep track of 'inputs' as well? Like... the profile wouldn't be complete without those shared libraries, no? It only seems to care about the propagated-inputs. <apteryx>oh, I guess it already does. It's saving the whole 'bag' to the manifest, I guess. <nckx>Guix keeps track of inputs as part of its regular operation. It doesn't need a manifest at all to compute the closure (all recursive dependencies) of each installed package. <nckx>What Guix can't figure out as soon as the ‘package’ object vanishes (and remember, this could be as soon as ‘guix install’ exits it the unusual but legitimate case of ‘guix install -e’) is which inputs were propagated <nckx>So that does need to be saved ‘out of band’ so to speak. <nckx>I hope that makes some sense. <nckx>This stuff can get confusing. <apteryx>hmm. Now wondering what makes it interesting to 'know' which inputs were propagated rather than just knowing the union of all involved inputs for a manifest? <nckx>PotentialUser-52: There have been some bugs reported in the last few days about Edit not working properly and the flow of the installer looping/otherwise not being great. That won't help you now, but it's something. <nckx>apteryx: That's exactly one of the things I'm too tired to reason about at this hour 😉 <apteryx>hmm... maybe for tracking which dependencies could be removed if I were to remove x package? For the other , non propagated dependencies, perhaps it expects to find the references to other inputs in the binaries themselves (like what 'guix gc' does)? <PotentialUser-52>nckx: no worries. Glad it's being tracked. is "guix challenge" the best way to verify things going forward? is there a way to just rebuild everything in the store? <apteryx>nckx: hehe, thanks for entertaining the conversation so far :-) <nckx>PotentialUser-52: I'm not sure what you mean by ‘rebuild after the fact with substitutes’. Even if you did use substitutes, I guess you could use a ‘guix build --check’ to see if your machine (re)builds the same thing as what you already have. If you're worried about the Thompson attack, well, you probably lost as soon as you downloaded a precompiled ISO 🤷 <nckx>That said, I did install without substitutes from the start for that extra fuzzy feeling of doing a lot more work for dubious benefit. I get it. <nckx>PotentialUser-52: I don't know exactly how you'd invoke or script ‘guix build --check’ to rebuild (and compare and throw away) everything in the store but it's certainly possible. <nckx>Your search-path procedure proposal did intrigue me, but also frightens me with its unboundedness. <nckx>As right as first-class procedures sound at the Scheme level, something about not being purely declarative by the time you write files to disc feels wrong, unguixy, unsafe. <apteryx>nckx: you mean, it'd open manifests as an attack vector? <nckx>PotentialUser-52: I was unclear above: guix build --check build a package from scratch and compares it to the one you have in the store (complaining if they don't match), but it will throw away the newer copy, not move it to the store as my wording might have suggested. <nckx>apteryx: Nothing as dramatic as that (although this has been discussed: we're already at the point where ‘doing the reproducible science‘ with Guix means handing people essentially a programme they must run, with an unauditable web of dependencies). <nckx>Just that it makes it harder to reason about things once you allow that. <nckx>3 hours of sleep and off to work. *apteryx thinks it's much easier to tell someone else ***dongcarl6 is now known as dongcarl
<efraim>sneek: later tell civodul on my pine64 $(guix build guix) took 295 minutes, $(guix build guile3.0-guix) took 370 minutes <efraim>sneek: later tell civodul $(guix build --no-substitutes libreoffice -nd) averaged 19.8 seconds, $(guile3.0-guix build --no-substitutes libreoffice -nd) averaged 19.35 seconds *efraim just tabbed back, totally wasn't sitting and waiting <rekado_>I’m trying to get back into hacking on the GWL and found that whatever store items I mount with call-with-container appear to be missing their symlinks. <bla>Hello; I'm totally new here (first IRC chat and first look at Guix things...) <bla>I try to install Guix on a VM using the ISO install, but I get stuck at the network steep, when Guix Installator tries to reach internet <bla>my network setup has to use a proxy for HTTP/HTTPS, and I'm not sure the Guix installed handles this configuration ? <bla>via the commande line, I have tried to setup the proxy (export http_proxy variables) <bla>at beginning of installation (before exporting the http_proxy var), when I do a "guix pull", I get this error: "failed to connect to git.savannah.gnu.org: Network is unreachable" <bla>after exporting both http_proxy and https_proxy, the "guix download" command then success (following redirection and file successfully downloaded) <efraim>I don't know if there's an easy way to have the daemon inside the VM use a proxy without already having access to the internet, can you proxy the whole VM? <efraim>ah, looks like you got it with http_proxy and https_proxy <bla>but the "guix pull" still doesn't work (same "Network is unreachable" error) <bla>I have also tried to restart the guix-daemon after having exported the http_proxy vars, but the pull still fail <bla>hey efraim, thanks for your answer, I'll have a look if I can setup something like that <bla>other point: wouldn't it be possible for Guix project to provide an ISO that is installable offline ? the current ISO is named "install", but it might need to be called "network install", as network is mandatory, and maybe provide an "install" iso which allowss installation without internet access <efraim>then we'd have to decide what goes on it. The installer is already on the larger side for text-only. We could keep the size down by adding just the sources needed to compile a selected system but even that could be large before deciding what needs to be included and what can be left out. <bla>I have tried to setup the proxy on VMWare side, but still no success <bla>anyway, I'm not sure it's applied to VM traffic, or only to traffic from the VMPlayer itself (looking for its updates) <sneek>civodul, you have 3 messages. <sneek>civodul, cbaines says: I spotted those issues with the Guix Data Service, I think the problem is related to the handling of duplicate package definitions (same name and version). There's code in the Guix Data Service to deduplicate the definitions, but I think a lint warning for a duplicate is leading to the error shown. <sneek>civodul, efraim says: on my pine64 $(guix build guix) took 295 minutes, $(guix build guile3.0-guix) took 370 minutes <sneek>civodul, efraim says: $(guix build --no-substitutes libreoffice -nd) averaged 19.8 seconds, $(guile3.0-guix build --no-substitutes libreoffice -nd) averaged 19.35 seconds <civodul>so compiling is actually slower (which is possible) <efraim>in case it matters, both of them were with a regular guix daemon <civodul>but i'm surprised that "guix build -nd" is not any faster <efraim>I think it was 40 seconds on a cold cache, the first time with guix <efraim>after I ran that a couple of times i got ~20 seconds with guile3.0-guix and then it averaged at 19.35 <civodul>the pine64 is supposed to be much slower than the OverDrive 1000, right? <efraim>same 4 core A53's, but emmc and soldered ram instead of ram sticks and an hdd <jonsger>and I guess the OverDrive has a higher power target then the pine64 <efraim>I still have the original blown power supply here. 35 watts i think, including hdd and fan <efraim>my pine64 is idle right now and pulling about 3.2 watts <jonsger>efraim: it doesnt have a fan, right? <efraim>Or anything plugged into the usb ports <potential-alex>Hello! I'm looking at how to get the imagick extension for PHP working in Guix. I can see two approaches: <potential-alex>1) compile it statically into PHP, but that would require somehow also downloading the imagick source files at php build time. I know it's not possible to add this during the build system — but do we have a way to specify multiple sources? Or otherwise, I suppose, we could make an upstream that combines PHP and imagick? It all feels a bit… not rig <potential-alex>2) add the extension using phpize & ./configure and friends. This seems doable, but requires that the extension is afterwards added to php.ini. Seems like that would be a service task? perhaps as a parameter to php-fpm service? <potential-alex>Does anyone have experience with PHP or a hunch on what the best approach here might be? <NieDzejkob>does guix generate php.ini by itself when you add the php-fpm service? <NieDzejkob>I'd add an "extensions" field to php-fpm-configuration that would take a list of packages <potential-alex>It does not — but it does generate a php-fpm configuration file, which afaik, can be used to add php.ini overrides. Should work there, I reckon. <potential-alex>Yea, I think you might be right with the "extensions field" approach. That'll probably be where I go. <jonsger>but apart from that we should think how we wanna package php and it's modules <alextee>what's the git frontend called again? the one that lets you pick individual lines to commit <potential-alex>jonsger: Isn't the problem with image-magick that it does not come bundled with php though? I think the others do, right? <jonsger>potential-alex: ah this could be possible. <potential-alex>jonsger: But yes, sounds like we need to think about PHP infrastructure! Gto hear there are a bunch of us thinking about PHP. Fairly sure Julien Lepiller would also have opinions on this… <jonsger>potential-alex: are you around at the Guix Days and/or FOSDEM? <potential-alex>I will unfortunately miss the Guix Days (out of the country before FOSDEM), but hope to be there for FOSDEM. *jonsger wants to edit libreplanet wiki, but FSF login is broken :( <civodul>bandali, brettgilio: do you happen to know who to contact for the cas.fsf.org issue? ↑ <bandali>civodul, jonsger, yeah, the fsf sysadmins would be the right people <bandali>feel free to write to them at sysadmin@gnu.org <bandali>i’ll also bring this up in their irc channel <civodul>maybe we should wait for feedback on their IRC channel first? <bandali>i was able to log into the LP wiki through cas.fsf.org just fine <tru_tru>beginner question: is it possible to install a non-root owned guix in a NFS shared space? ie /var/guix rw on a server and ro for the clients? <tru_tru>thx, I am not very keen on having a root process on the build node <civodul>tru_tru: yeah, unfortunately it's unavoidable with the Linux kernel, unless unpriv. user namespaces are enabled <civodul>so you're interested in the "guix-hpc" channel? <tru_tru>I am curious to find what is available <tru_tru>mostly for life science related/deep learning related software: cryoem <tru_tru>relion/imod/... and TF/pytorch and friends <jonsger>civodul: what are you doing there with the installer? <str1ngs>tru_tru: I have got guix to run in rootless name space using unshare and proot. <str1ngs>but as civodul mentions it require user name spaces <str1ngs>I don't actually use unshare and proot. I use go languate to make syscalls <NieDzejkob>I'm trying to find all packages that use cmake-build-system and provide .la (libtool) files. I managed to cobble together a shell pipeline and a guile script (https://paste.debian.net/1127133/) to search my /gnu/store, but that only includes packages I have installed, which turns out to not be enough. I also managed to use fold-packages to find all packages that use cmake-build-system (there's 620 of them). How could I get the list of files in a package <NieDzejkob>in Guile? I'll probably need to download the substitutes for the packages, but I'd rather avoid downloading the dependencies too... <NieDzejkob>Oh, and I'm doing that because I want to figure out why googletest doesn't install its libgtest.la, even though the sources contain a template, and one of the scripts refers to the file <bavier>NieDzejkob: I'm not sure, but I think the template la file may be old cruft <bavier>NieDzejkob: I wonder if cmake is supposed to pick the template up automatically and install it? <NieDzejkob>(I'm trying to get the tests for MEGAcmd working, but if I fail, I can just do #:tests? #f, I guess) <bricewge>civodul While you're into the installer I got two crashes but was too lazy to keep the coredumps. One happened when deleting a free space in the partitioner .The other was by unplugging the HDD which made opening the partitioner crashed. <lfam>Our QEMU package seems to be missing the man pages... *nckx , always paranoid about not getting listmail: responderS, lfam? <lfam>I don't know what you mean, nckx <nckx>‘But I agree with the other responders’ in a thread where I don't see anyone but me responding. <nckx>You mean that wasn't a clear question? I'm schocked, I say, shocked. <lfam>You are the other responder :) But I replied directly to the person asking the question <lfam>I just wanted to communicate that my advice shouldn't contradict yours <nckx>Right. It was a stupid detail, but I'm always on edge for the next SPF snafu. <ArneBab_>Is there an easy way to package an npm package? I seriously need tern available from my emacs … <NieDzejkob>ArneBab_: take a look at gnu/packages/node-xyz.scm in the guix repo <ArneBab_>is there an importer (ideally recursive)? <ArneBab_>I don’t know how many packages I’ll have to create to get tern working … <Parra>I'm using guix pack for packaging a software, but I need to export the environment variables used by those programs, there is some command for it? <Parra>ArneBab_: it is difficult, I packaged some thought but they are self contained. In any case if you check node install, the global directory has npm installed with all dependencies recursively installed too, so there must be a way <Parra>I packaged node-addon-api and cherow <Parra>I can share the code if you are interested ***catonano_ is now known as catonano
<leoprikler>Parra: export environment variables in which way? If you need some variable to launch them correctly, wrap-program or wrap-script are probably what you want. <leoprikler>If you want to access the environment variables inside a running process, then you'll have to use whichever facilities the program provides. If it has none, you'll have to break it first to get some ROP going or whatever. <nckx>mbakke: I've already answered the remove-store-ref question upthread, it's needlessly ugly for a simple text file. Curious which advantages you think it would it have? *nckx restarting their SMTP server atm. <mbakke>nckx: oh, ok; I just have a healthy aversion for complicated regexps... <mbakke>then my only nit-pick is that I would prefer (%store-directory) to be let-bound, instead of called within the context of substitute* :-) <Parra>leoprikler: I just want to know what environment variables are defining some packages that I'm exporting as a tar.gz with guix pack <nckx>Oh, is it that complicated? Hm. I thought it was quite simple for its accuracy over, say, (~a/)([a-z]*)-. That's simpler but less obvious to me. De gustibus et regexibus, I'm sure. <nckx>mbakke: Interesting. Why? Future? <vagrantc>make dist fails with help2man not being detected <leoprikler>Parra: I have no idea what you just meant with that. Are you perhaps interested in the search-paths, that come with profiles? <pkill9>does anyone run guix on a raspberry pi out of curiosity? <vagrantc>guix environment guix --ad-hoc imagemagick help2man ... ./bootstrap && ./configure --localstatedir=/var && make dist ... am i missing something? <Parra>for example, I know Python defines PYTHONPATH to the correct paths in /gnu/store, how can I obtain the whole list? <leoprikler>By iterating over the closure and getting the seach-paths of each package. <Parra>because basically what I'm doing now is to export a portable tarball with guix pack, but when decompressing and using python, it cannot locate packages properly <Parra>leoprikler: there isn't a bashrc equivalent in guix? <leoprikler>there is a profile equivalent, which is what you'd want <pkill9>i propose simple tools that transform a system configuration and reconfigure, i.e. like 'apt-get reconfigure sddm' or whatever the command is <Parra>me neither, I couldn't nothing about it in guix pack doc <leoprikler>search for a file called <hash>-profile inside your packed /gnu/store <nckx>leoprikler: Guix packs include a completely real -profile/etc/profile you can source. <leoprikler>There should be one, though, as nckx points out. <nckx>Either you look for a /gnu/store/*-profile/etc/profile in the tarball as leoprikler suggests, or if you want something more robust you can probably use -S /etc=etc which will create a ./etc link to that file in the tarball. <nckx>Oh, I'm not familiar with that option, that might do it. <Parra>but there is a need of env vars too <Parra>not just the links to binaries <mbakke>nckx: mostly out of "good practice", in case %store-directory throws an exception or similar. Better to resolve such must-be-strings up front. <nckx>Parra: IDGI, -S just creates the link, you still need to source ./etc/profile. <nckx>-S /etc=etc just gives you a well-known location to source, like you already do for /bin. <Parra>nckx: exactly, that's what I realized <Parra>by source you mean the list of env vars? <Parra>Include the “local state directory”, /var/guix, in the resulting pack, and notably the /var/guix/profiles/per-user/root/name profile—by default name is guix-profile, which corresponds to ~root/.guix-profile. <nckx>mbakke: A somewhat circular answer but I don't doubt you. Does it create a prettier backtrace? Anyway, will do when/if I push it. <Parra>not sure if the profile is what I need <nckx>Parra: Eh, I don't even understand that help message. Maybe it's because I treat packs as simple tarballs I can munge at will and don't go through the proper ‘abstractions’. 🤷 <NieDzejkob>pkill9: Why? What's the usecase? Are you really changing your global packages that often? <mbakke>nckx: probably, although I only started religiously following this practice while hacking on guile-git and was uncomfortable calling out to a procedure in the context of a libgit2 C function :P <pkill9>NieDzejkob: nah, it's just convenience, it wasnt a serious proposal <pkill9>i would make it a third party tool anyway ***apteryx_ is now known as apteryx
<nckx>mbakke: Sometimes it's important to listen to your gut. Thanks! *apteryx tiring of typing /nick apteryx... why does my weechat relay seems to cause my nick to revert to apteryx_ all the time? <NieDzejkob>pkill9: why make it third-party? If you submit a patch for a useful utility for guix, it has a fair chance of getting merged <apteryx>ah, seems when it reconnects due to dynamic IP renewal in the middle of the night it fails to reuse the same nick: irc: nickname "apteryx" is already in use, trying nickname "apteryx_" <pkill9>NieDzejkob: it's more stuff to maintain, but yea <janneke>i probably should have gotten suspicious when guix-1.0.1-13 was not available as a binary substitute for aarch64? it's stuck at 94% now for me <pkill9>now i think about it, it would be fairly simple to do, just inherit the os config and make a change <vagrantc>janneke: happens all the time ... aarch64 is often very behind <janneke>vagrantc: any hints for a more favourite commit to pull to, so that i might just get a substitute? <vagrantc>janneke: it's been a couple weeks since i last tried <pkill9>is it possible to use guile to query the current system configuration wigh guile go, for example get the services? or the packages? <nckx>pkill9: Strange, 1 of my Arch build nodes is currently building guile3.0-guix and gdb, the other is completely idle. <nckx>pkill9: I meant janneke, your nicks are so much alike. <nckx>Oh, guile3.0-guix isn't the default yet. <janneke>nckx: ;-) could be i just picked a bad commit to pull to <ArneBab_>NieDzejkob: thank you! Do I understand it correctly that this effectively means "no recursive download yet"? <vagrantc>janneke: alternately, the test could strip out the current version, and we get a hopefully more stable hash? <janneke>interesting, that 1% took about half an hour; just as much as the first 94% <vagrantc>janneke: although if 0.23 is going to change, maybe that isn't so realistic *janneke keeps hopping channels with vagrantc <janneke>96% -- my system init may just succeed after all... <vagrantc>janneke: i've been thinking of making a linux-libre-arm64-generic like the linux-libre-arm-generic package ... which might require less fiddling every release to make sure it works on a wide variety of platforms <vagrantc>there may be a number of kernel config changes needed to get pinebook pro working with mainline linux-libre <janneke>vagrantc: that would be nice -- main reason for me to get this pinebook pro to get at least somewhat knowledgeable about arm and possibly help or at least complain :-/ <janneke>yes, i'm trying /proc/config.gz now, using 4.4.190 which they ship <vagrantc>they probably also include plenty of patches <vagrantc>pinebook-pro isn't even in linux-next upstream yet... <vagrantc>so they must add some device-tree patches at least <civodul>jonsger: trying to automated testing of the installer UI <raghav-gururajan>dconf-CRITICAL **: 21:42:10.207: unable to create directory '/homeless-shelter/.cache/dconf': Permission denied. dconf will not work properly. <nckx>raghav-gururajan: (setenv "HOME" (getcwd)) before running the test suite. <jackhill>raghav-gururajan: were you experiencing GNOME stuttering? <drakonis1>is there any fix cooking up to prevent the power settings tab from hanging gnome settings? <jackhill>raghav-gururajan: ok. I don't think I was when you firt reported it, but a couple of times this week my whole desktop froze. Sometimes it would come back, but at least once it did not. <jackhill>drakonis1: I don't know. I didn't even know that was a problem (I guess I don't adjust my power settings very often). Is there a bug for it? <jackhill>drakonis1: I do know that a fix for power permissions was added recently. <drakonis1>i have to disable suspending and automatic locking when doing tasks <drakonis1>and laptop backlight got fixed to not require permissions to change it, right? <drakonis1>gonna toss guix on my laptop soon and that sounds super inconvenient <jackhill>I use Guix+GNOME on my x201t thinkpad and haven't had issues with changing the backlight. <civodul>nckx: re guile3.0-guix (and "guix pull" etc.), the blocker at this point is Guile 3 on ARMv7 <jackhill>civodul: are you testing the installer by communicating with it over a socket? <jonsger>civodul: do you have access to ARMv7 hardware? <drakonis1>can't guile 3 be set as the default for all non ARMv7 systems? <civodul>jonsger: i tested on an OverDrive (AArch64) <civodul>drakonis1: another option is to disable JIT for now on ARMv7 <jackhill>civodul: cool, I thought I remember reading that :) I wonder how practicle it would be to use the same technice to manage automated installs <Parra>nckx: it seems there is another problem, there are two folders of python with same version but different hash <jonsger>janneke: it's start using guix time-machine :P <Parra>how is it possible to have two pythons of same version but different hash? I don't know how this happened XD <mbakke>Parra: you only have two in your store? :) <Parra>mbakke: but I need only one, how can I remove the other? <mbakke>Parra: 'guix gc' should do the trick, assuming no profiles are referring to the other one <Parra>mbakke: the problem is that it is being packaged into a tarball with guix pack <mbakke>Parra: right. try with --no-grafts <Parra>should I run gc before guix pack? or maybe there is a dependency that is forcing to install that duplicated python <Parra>I'm reading the doc but I'm not sure if I understand it <mbakke>Parra: yes, 'guix pack --no-grafts your-package' -- does it make a difference? ***drakonis1 is now known as drakonis
<guixy>I'm trying to build a guix image for bananapi m2u. <guixy>Since the work has already been done for the installer, I thought I would try that first. It didn't turn out very well. <guixy>Has anyone here had success with the guix system on a bananapi m2u? 
