<derivates>install-license-files phaseguix system: error: cannot close compress log file (BZip2 error=-6) <derivates>im trying to system init, but I get that error ***lukedashjr is now known as luke-jr
<MysteriousSilver>Hi! Where are the .desktop files stored for packages installed using Guix on a non-guix system? My DE doesn't detect them. <pkill9>MysteriousSilver: same as in a guix system, /var/guix/profiles/per-user/<user>/guix-profile/share/applications or ~/.guix-profile/share/applications <pkill9>the latter is a symlink to the former <pkill9>you probably need to add one of those paths to XDG_DATA_DIRS environment variable <pkill9>well, ~/.guix-profile is a symlink to /var/guix/profiles/per-user/<user>/guix-profile <pkill9>i mean, add the share directory to XDG_DATA_DIRS <vagrantc>which should be handled in ~/.guix-profile/etc/profile ... no ? <colemickens>Hi I'm a NixOS guy but I've been loving seeing guix in the news more and can't wait to spend more time switching one of my systems to guix system. <colemickens>love seeing blog posts, beefy release notes, etc bringing more people in <lfam>After selecting it from the UEFI "device picker" it fails with "Invalid Magic Number" and "You need to load the kernel first" <lfam>I think the combination of these two issues (the former completely blocks building the installer on aarch64) suggests that this path hasn't been trod yet <lfam>I'm gonna try `guix system init` directly on the running Debian <lfam>I don't really have any idea how to write the bootloader section of config.scm though <lfam>colemickens: Thanks for the words of encouragement :) <iskarian>So... whenever I compile something manually with gcc-toolchain, it seems to put ~/.guix-profile/lib in the RUNPATH. Is this expected? It seems awfully weird <apteryx>is there no apache/apache service yet in Guix? <jgart[m]>Hi colemickens, I'm glad to see you here and your interest in guix! <drakonis>there is a lot to learn from how guix does things ***iyzsong-- is now known as iyzsong-w
<nckx>raghavgururajan: <05:00 safety check> I keep weird hours but not that weird. :) <nckx>apteryx: ‘httpd’, as I'm sure you discovered. <zzappie>So yesterday i was figuring out why a service was crushing in a marionette vm <zzappie>I think you all famililliar with obscure (raise-exception _ #:continuable? _) message. Its kinda local meme for me -- every time i see it i say to my self "_! of clourse!" <zzappie>so I tried marionette-screen-text this thing does optical character recognition on vm's VGA <zzappie>and here It was! rgs: (\"#{Bnon-cont inuable}\")\n-\n\n <tissevert>there's a space between «cont» and «inuable» in the string you pasted. I wondered if you found that funny or if it was simply an OCR glitch that had nothing to do with the matter ^^ <zzappie>Ah its a glitch but I laughed because it is like the worst traceback ever :) I barely recognized a message that doesnt give me any info and only because I've seen it so many times <tissevert>so you know what this about ? because, yeah, it's not really helpful like you said : ) <zzappie>well as I understand this means that tere was an excetption but variables are dropped by gc already hence _. Im not sure btw <cbaines>colemickens, I'm unsure, could you explain what purely evaluated means? <colemickens>cbaines: in nix stable, NIX_PATH and environment variables and the exact state of ~/.config/nixpkgs/* affects the outcome of nix builds. in nixUnstable evaluations are pure by default and have none of those impurities leaking in affecting build outcomes <cbaines>colemickens, OK, I don't think the concept exactly maps to Guix, but generally you have to be explicit about introducing changes (impurities), so I think the rough answer might be, yes <leoprikler>There are a few environment variables, that can affect Guix, but they are rarely used. <leoprikler>For instance, you can choose to prepend packages and extensions. <leoprikler>If you are afraid of them leaking, simply set those variables to an empty value. <leoprikler>And of course, the most important factor is the PATH variable, which defines which guix command to use :P ***pocketroid_ is now known as pocketroid
<sneek>PotentialUser-75, you have 1 message! <sneek>PotentialUser-75, mdevos says: guix install name@version or guix install -e '(@ (the channel module) the-package)', <cbaines>PotentialUser-75, maybe use something like gparted <cbaines>expanding patitions can be tricky though, depending on the position of other partitions <PotentialUser-75>Gparted says its read only and needs to be unmounted... but I cant unmount root <cbaines>right, this is one way in which it can be tricky <cbaines>one approach is to boot a live system, and make the partition change from there <Formbi>I'm trying to run pdflatex and it says «Sorry, I can't find the format `pdflatex.fmt'; will try `pdflatex.fmt'.» <PurpleSym>Will changes to guix/download.scm trigger a world rebuild? The belnet mirror URL for Gnome is wrong. <cbaines>PurpleSym, it might affect derivations, but maybe not outputs, since the change might just be in the fixed output derivations <cbaines>the easiest way to find out for sure is probably to make the change, and check the outputs of a few packages <cbaines>how can I convince the guix-daemon that it can delete any output in the store? <cbaines>I've tried deleting all of the gc roots, as far as I'm aware, but it still thinks things are alive <cbaines>I think I've deleted them all, but either I've missed some, or that's not enough for some reason <cbaines>I have no gc roots, so I don't think that's relevant <cbaines>from looking at the code, it's the liveness check that I'm coming up against <cbaines>or at least I think it is, since guix gc --list-busy outputs some things <sertified>Hello, does anyone have an issue with read-only file system when using Jupyter? <cbaines>sertified, do you know if the read-only file system in question is read only because it's broken, or because it's not meant to be written to, or just not meant to be read only? <meo>gentoo's keychain is not in guix, is there a reason other than no one packaged it? <leoprikler>In particular the question is "Does jupyter try to write to /gnu/store when it shouldn't, or does it try to work to some file it should have access to?" <meo>leoprikler: it's an useful tool, and it's GPL, is there something in guix repos that I should use instead? <leoprikler>How is Gentoo's keychain a "tool", isn't it just a set of PGP keys? <meo>leoprikler: no, it's a script to manage ssh-agent <meo>It's quite a popular tool and I was surprised that it's not in guix packages, so I thought there may be a reason for that. If not, I'll package it <leoprikler>I'm not quite sure what it accomplishes, but I think most of that is normally done by your ssh-agent (e.g. Seahorse), no? <leoprikler>Other than that, of course it'd be fine to package. <meo>it's a convenience wrapper, it makes my life much easier because I use yubikey piv to authenticate everywhere <leoprikler>I'm not sure if having a global ssh-agent process jills well with Guix, but the rest of it should be usable once packaged for Guix. <meo>I dont think it has a global one, agents are strictly per user and I believe multiple agents are supported <meo>oh, I just rtfm'd.. I see what youre saying <leoprikler>Ahh, sure, but it says on the info page, that it also makes it possible to only have a global one, so that's that <leoprikler>just preempting that if that was your use case, it probably needs special care <meo>I've never actually used it as a system service, I'll have to look at it closely <meo>that was never the plan :P <meo>actually I probably need to update yubikey-piv-tool first <leoprikler>there are already some yubikey tools packaged, perhaps you can use one of those? <meo>leoprikler: ssh needs libykcs11 from yubico-piv-tool which is too old <meo>leoprikler: so my fips authentication doesn't work out of the box, the yubico package in guix needs to be updated, I'll do it <jlicht>sertified: what problem do you have? Is it with the ipykernel, by any chance? <yuqio>Hello, I have a question about guix environment. Is it possible to automatically set environment variables when running `guix environment`? My current workflow is to run `guix environment -m manifest.scm` and then `source .env` (where the .env file contains the environment variables) and ideally I would like to skip the second command. <leoprikler>yuqio: if you're using pure environments you can pass them on with -E, otherwise no <leoprikler>That being said, direnv exists and is used by some Guix folks <yuqio>That seems to solve my problem of having to type `source .env` each time. Thanks for pointing it out <sertified>cbaines: it's not meant to be read-only, i'm not entirely sure why, it could come from a dependency upgrade <sertified>The exact error is: OSError: [Errno 30] Read-only file system: '/home/user/.guix-profile/etc/jupyter/migrated' <cbaines>sertified, I think that particular location is meant to be read only, as it's effectively within /gnu/store <rekado>a user pointed out this error too <rekado>there’s an environment variable that can be set here <rekado>could you try setting jupyter_config to some writable location? <sertified>The file /home/user/.guix-profile/etc/jupyter is just a symbolic link to /gnu/store/[hash]-python-widgetsnbextension-3.5.1/etc/jupyter, but "migrated" does not exist <PurpleSym>sertified: The variable is called JUPYTER_CONFIG_DIR. What’s the command you’re trying to run? <PurpleSym>Do you happen to have the jupyter package in your environment? <PurpleSym>(`guix environment --ad-hoc python-notebook jupyter -- jupyter notebook` fails for me with the same error, but without jupyter it works) <sertified>Yes, if I run $ guix package -I jupyter, I have jupyter-1.0.0 <PurpleSym>Does it work if you remove it? Afaik it should not be necessary. <sertified>Removing jupyter also removes ~/.guix-profile/bin/jupyter, so running jupyter notebook fails <PurpleSym>Ah, okay, I see. You can instead install python-notebook. <rekado>PurpleSym: should we remove the jupyter package then? Deprecate it in favor of python-notebook? <PurpleSym>rekado: Yeah, I feel it’s not necessary and confusing. But this particular issue seems to be coming from python-ipywidgets. <roptat>mh... a comment on phoronix is citing "Deprecating support for the Linux kernel" as a reason not to try guix... did we go too far with this joke? :D <roptat>should we prepend "April fools joke" to the title or something?... <leoprikler>We didn't go far enough, Hurd is still not mandatory. <roptat>well, I guess if they didn't go as far as reading the very first paragraph, we can't do anything for them <tissevert>are one of you people actually running the Hurd ? how usable has it become these days ? (I'm genuinely curious) <cbaines>I did manage to build some things, but there's plenty more work to do <sertified>PurpleSym: Still have the same error, with JUPYTER_CONFIG_DIR=/gnu/store/[hash]-python-widgetsnbextension-3.5.1/etc/jupyter <sertified>Both with $ guix package -i python-notebook, and with $ guix environment --ad-hoc python-notebook -- jupyter notebook <cbaines>sertified, I don't know much about Jupyter, but it seems like it's expecting to write to it's config directory, which isn't unreasonable <cbaines>so the config directory you specify probably needs to not be read only <meo>isn't error 30 supposed to happen on literal filesystem level? is this in a container somewhere? <meo>ah no, i'm wrong, never mind <pineapples>I read a short mailing thread regarding the bug that prevents Linux-libre from loading non-free firmware, and about the endorsement of Debian-based PureOS, by FSF. This got me thinking about GNU Guix System potentially adopting the Debian kernel, which can load those firmwares. Realistically-speaking, would this hurt any of the four freedoms of GNU Guix System users? I'm asking because I somewhat <pineapples>disappointed after my yesterday's unsucessful attempt to use Linux-libre on my system :-( <PurpleSym>sertified: My current intuition would be to patch jupyter-core, so it comes with etc/jupyter/migrated, which apparently prevents migration. <roptat>yeah, I guess they just didn't bother reading it <civodul>we could add "joke" to the title, but at some point, it becomes really hard to improve if we assume people won't read :-) <roptat>I mean, many people form an opinion just by reading a title, even though they are sometimes (often?) misleading <roptat>hey, next year, around mars or april :p <PurpleSym>sertified: I pushed a fix as commit 16ad755f94597cc47725a030ef1a65f94d4155c8. <jlicht>sertified: I always export JUPYTER_CONFIG_DIR=<some-dir> to do things with jupyter notebooks. Perhaps that might work for you as well <irfus>hi #guix. I wrote an updated definition for mesa and added it to a local channel. Reconfiguring the system correctly builds and installs it too. <irfus>But the version of mesa reported by `glxinfo` is still the older on e <irfus>I checked the store and it seems to have both versions installed, but the new one is unused <irfus>I had assumed that since it had a higher version, it would take precedence over the older one. What am I missing? <roptat>irfus, that's because the precedence mechanism only works at the CLI level <roptat>in code, it relies of the scheme object, so there's no ambiguity and no precedence <roptat>iirc glxinfo is from mesa-util, which depends on mesa in that way: (input `(("mesa" ,mesa) ...)) the second mesa (with the comma) refers to the guile variable mesa, which is also defined in the same file, it's guix's own mesa variable <roptat>similarly for the rest of the system, packages rely on the scheme variable, so they use the guix version instead of yours <irfus>right, so I should modify the inputs of all such packages to pull 'mesa-21' instead? <roptat>what you need is to rewrite their dependency graph, with something like --with-inputs=mesa@20.2.4=my-mesa <irfus>I am aware of the above when using `guix package` on the command-line, but how to ensure that transformation applies to every package during a system reconfiguration? <irfus>Also, assuming there's a programmatic way of applying that transformation, would that result in rebuilding them or will it use "grafting" (I've not entirely understood how that works but I believe this is the kind of scenario it was designed for?) <roptat>if you change an input in a package, it's rebuilt because it's not the same thing <roptat>if you add a replacement to a package, all packages that depend on it will be grafted to replace references to the old package with references to the new package <irfus>^ but that will need to be a drop-in replacement, right? <sertified>PurpleSym: The jupyter package now works, thank you <roptat>as long as there's a replacement field, it'll be grafted, whether it's drop-in or not, so be careful :) <roptat>to ensure grafting, you can for instance declare a new mesa package that inherits from guix package, but adds a replacement field <roptat>the replacement field does not count for computing the guix store path, so it's the same package <roptat>now, if you rewrite dependencies to use that package, all the dependents will be grafted with the package you put in the new replacement field <roptat>and no rebuild, because it's the same dependency (store path) <roptat>I don't know of an easy way to rewrite dependencies for guix system however <roptat>you can do that for the packages field relatively easily, but not for the services <irfus>yeah, services is where it gets hairy...I have a couple of package transforms in my config already, so I understand how that would work. But specifying the mesa for the xorg-server-configuration, I don't know how to do that <roptat>I think you need to replace the display manager and your desktop manager if you have one <irfus>so the only way aroun d this would be to update the scheme object 'mesa' in the original guix module where it is declared? <roptat>there's a gdm field you can replace with a package where you transitively replace mesa <apteryx>nckx: thanks for the info (httpd); no I hadn't found it for some reason <irfus>since the updated package definition was relatively easy to define, I wonder why this hasn't already been added to guix. Is it simply low priority, which makes perfect sense, or is there another blocker that I am not aware of (that will painfully come to the fore if I attempt the rebuild :D) <roptat>guix refresh -l mesa says there are 2368 dependents, so that's core-updates material <roptat>although, it's not updated to mesa 21 on core-updates either <irfus>core-updates is a branch on the source repo? <roptat>usually this means nobody took the time to update it :) <roptat>we push changes that cause lots of rebuilds to separate branches, and merge them regularly <roptat>we'll start working on core-updates merge very soon, so if you want to send a patch, now's the time to do it <roptat>otherwise you'll miss the window and you'll have to wait for the next merge :) <irfus>ah, right. I'm not really sure I understand the process for sending in a patch, but I could look it up. ***lukedashjr is now known as luke-jr
<irfus>But would that entail more than just sending the updated package definition? Like actually rebuilding it and all dependents, etc. to see what works or not? <roptat>irfus, you just send your patch to guix-patches@gnu.org, either with git send-email or as an attachment <roptat>you're supposed to rebuild all dependents for master, but not for core-updates <roptat>the build farm will do the work, and if something breaks, we'll try to notice and fix :) <roptat>not the best way to push updates, but it ensures we can push to core-updates without rebuilding everything all the time <roptat>as long as you can build the package on core-updates and some dependents, it's ok <irfus>okay, so to just list out the process: I would make the changes in my already checked out copy of the guix src, then use `git send-email` to generate and send the patch with the changes. <roptat>(you have to check out core-updates, not master) <roptat>(and again, for a single patch, if you're not familiar with git send-email, just send it as an attachement) <irfus>I'm really unfamiliar, but would like to learn. <irfus>okay, so would it make more sense to add a new package 'mesa-21' or to make changes to the existent 'mesa' package? <roptat>irfus, make the change to the existing package I think <roptat>we usually keep only one version of each package, unless there's a good reason not to <irfus>"as long as you can build the package on core-updates and some <irfus> dependents, it's ok" - what would this entail? <roptat>from the checkout, build mesa: ./pre-inst-env guix build mesa <roptat>then, use refresh and build some of the dependents listed: ./pre-inst-env guix refresh -l mesa and ./pre-inst-env guix build ... <roptat>(pre-inst-env is generated, you need to run the whole "./bootstrap && ./configure --localstatedir=/var && make" to get it <irfus>got it. thanks for explaining :) <pineapples>Oh. Would you look at that! My patch has been merged <bone-baboon>If I get an error message that is prefix with "guix pull: error: Git error:" does that mean that guix pull is passing on a Git error it received from Git while it was trying to execute the guix pull command using libgit? <nckx>leoprikler: I'm trying to think of scenarios where distros package each others' keyrings (Le Distro Cross-Sign Project!) but none bring much value. <nckx>Hullo pineapples, hope you are well. <leoprikler>it turned out to be somehting else, but I can't think of a good reason to do it either <raghavgururajan>Folks! I am looking into #47641. Any one here have linphone account? I would like to test the issue via messaging. <nckx>Ah, I was still reading, I was too soon. *tissevert has a names epiphany <nckx>raghavgururajan: Are they easy to create? I can try, but not this evening, I'm about to leave (→ eat out erryday ♪ now that it's legal, woo). <apteryx>raghavgururajan: is it easy to get one? if it's not too much hassle I could try <tissevert>nckx: so you're the one who called me «Greensleeves» *tissevert stares at nckx <nckx>apteryx is on the case, good, good. <tissevert>I hadn't yet matched your nick to the name I saw in the mailing list <nckx>tissevert: Whence your nick actually comes, if you don't mind sharing? <tissevert>not at all, I should've thought it was someone who at least partially understood french to translate the «-vert» ending (accurate translation as you'll see) it makes sense now <tissevert>I needed a new nick four years ago, at the time I was very much into «Wynonna Earp» (a TV series about a family of Demon hunters very… a bit silly but I like it) <djames>Is there a GNU Guix system available for powerpc64le? If not, is there a way to bootstrap such a system? <tissevert>the character of the little sister, Waverly, had an interesting echo with my own life, and it was also the time when I started learning knitting and weaving <tissevert>so a name centered around the idea of weaving became pretty obvious, and I thought «why not translate it into my native language, after all I love all languages and that includes frenche» <tissevert>that got the «tisse-» part, and as for the «green», well it's always been my favourite color by far and I was indeed knitting and weaving a lot of green stuff (pretty much all of the yarn I bought at the time was green so… it was simply an objective description at the time «the one who weaves green stuff») <nckx>djames: I don't think you can boot Guix System on PPC64LE today, but nor have I tried. There's certainly no image. It might take some work, but doable work, and your help would be much appreciated. What we call the ‘bootstrap’ (with a working Guix package manager, toolchain, etc.) is done. <nckx>Well, no official image anyway. <nckx>tissevert: Nice, thanks :) <tissevert>but for matters more relevant to this chan ^^' have you had a chance to look at my second patch ? I know I've been very long to answer and send my second version so I totally understand if you haven't, I just want to make sure you're not still waiting for something I'm unaware is missing <tissevert>nckx: always my pleasure to spam honnest chans telling people about my uninteresting life :D <nckx>tissevert: I (only) looked, but you sent your diff as a diff to your previous diff and I didn't actually apply it yet. I'll certainly take care of it over the weekend. <djames>nckx: I see, that is good to know. Is there any repo I can access to look at how the system was built for the x86 versions? <tissevert>oh, cause I generated it on the branch I had started, and not as a total diff from master <nckx>I'm sorry, I really have to leave. If I'm in a state to log back in later tonight (hey, it's Belgium) I will, otherwise good luck & good night. <lispmacs[work]>does guix get some kind of funding for bugsquashing or is that all volunteer? <lispmacs[work]>I was just wondering because I've got like 20 bug reports open from the last two years <drakonis>hhhmm, i dont think there's funding for that <lispmacs[work]>I'm thinking they should get some of the GSoC interns focused on bug squashing, if that is allowed <vldn>is it possible to use "guix deploy" with a machine name? <vldn>like localhost, vserver, mailserver etc.? <vldn>to deploy seperate machines <vldn>or do i have to load seperate files? <mdevos>When running "guix import texlive babel-dutch": command "svn" "export" "--non-interactive" "--trust-server-cert" "-r" "51265" "svn://www.tug.org/texlive/tags/texlive-2019.3/Master/texmf-dist/source/latex/babel-dutch" "/tmp/guix-directory.8EghHU/svn" failed with signal 11. Can someone verify on their system? <sneek>Welcome back mdevos, you have 1 message! <sneek>mdevos, nckx says: By definition, emacs is the favourite editor. Like ed is the standard editor. <mdevos>vldn: "guix deploy" doesn't have an option for only deploying systems matching some constraints. You'll have to load separate files or implement such an option. <apteryx>raghavgururajan: I have an account now, 'apteryx' <apteryx>well, I have to register it in the client <apteryx>raghavgururajan: just sent some message to yu <apteryx>linphone tells me it's delivering the messages: [13:48:11:827][Info]Core:linphone: Chat message 0x48bab20: moving from InProgress to Delivered <davidl>nckx: to explain upstreams response reg. the xmllint patch (if I understand it correctly) - previously xmllint --xpath actually outputted multiple xpath results as a concatenated string which was totally useless, and at the time of the initial Pull Request by "Cyker Way" the default output separator would be changed to a newline and it was also modifying a very important function called xmlSaveTree(). This was later change by upstream so by now adding <davidl>the --xpath0 option has no risk associated to it. <raghavgururajan>apteryx: I got your messages as notofications, but not visible in the app. <eriklovlie>n00b question: I want to invoke a program (from a build phase) and capture the standard output. Specifically it is "patchelf --print-interpreter". The "invoke" util returns a boolean. I didn't quite grok the "invoke/quiet" function but anyway it doesn't return the stdout. Do I need to resort to something like "open-output-pipe" or is there another <eriklovlie>hm... (define (open-pipe-with-stderr program . args) maybe? <jlicht>meo: are you packaging keychain, or should I have a look at it later this week? It seems like an interesting piece of software :) <farkr>how come when I install guile-* packages they write themselves to a different /share/ folder than my current profile? how do I set my current profile to make the libraries usable? <gnutec>Don't forget to play openspades. <farkr>actually, my problem seems to just be with guile-chickadee <farkr>guile-json seems to download into my current profile properly, but not chickadee <farkr>vagrantc: when I run guix install guile-chickadee, it appears in a profile folder that isn't my current profile <farkr>of all the profile folders in /gnu/store/ <luis-felipe>Hi, I ran "guix package -m my-manifest.scm" and the downloads were interrupted with this problem: *luis-felipe retries profile upgrade... <cbaines>vagrantc, I guess that's sort of good it works in some situation, I wouldn't have expected armhf though <vagrantc>i think the build path embedding issues were worked around in 1.3.0 (and a proper fix in core-updates), and you also have to build guix without parallelism ... i think those were the main blockers for reproducibility <Ikosit>If the url stays the same, `guix download $url` should output the same as well, shouldn't it? <cbaines>the URL doesn't matter, it's the contents of the downloaded file that matters <vagrantc>Ikosit: that's probably because the page changes <cbaines>Ikosit, right, take the two store items you get, and run diff to see what's different <cbaines>I see a request-id meta element that's different, which makes sense <farkr>vagranc: my bad. I meant /run/current-system/profile. apparently that's something different than ~/.guix-profile <vagrantc>farkr: that's essentially managed by "guix system reconfigure config.scm" as opposed to your user profile <Ikosit><cbaines "Ikosit, right, take the two stor"> Yes, the problem is that i downloaded the github page, but not the repo <cbaines>Ikosit, right, the Git repository should be more stable <rndd>should i translate word "not" in "@emph{not}" <luis-felipe>Yeah, @emph{} is a texinfo command. So I wouldn't touch the command itself but would translate the "not". *luis-felipe wonders why the texinfo command is in the translation string though... <luis-felipe>The problem I had when upgrading my profile was transient but now the whole upgrade failed for another reason... <rndd>luis-felipe: ok, thank you <luis-felipe>Removed linkchecker from my manifest. Profile upgraded.