IRC channel logs


back to list of logs

<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 waves
<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>Hey vagrantc
<lfam>I built 'gnu/system/install.scm' on my Macchiatobin (after a kludge for <>) and tried to boot it
<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>mostly because i keep poking him :V
<drakonis>because i wont shut up on NixOS's irc
<drakonis>there is a lot to learn from how guix does things
<drakonis>im a advocate y'all
<raghavgururajan>nckx and/or apteryx: For safety check, does #48394 look good?
***iyzsong-- is now known as iyzsong-w
<pocketroid>Greetings programs
<apteryx>raghavgururajan: checking
<raghavgururajan>apteryx: Thanks!
<nckx>raghavgururajan: <05:00 safety check> I keep weird hours but not that weird. :)
<nckx>apteryx: ‘httpd’, as I'm sure you discovered.
<tissevert>hello guix
<nckx>Hi tissevert.
<tissevert>nckx: Goedemorgen
<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>*of course
<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
<zzappie>which is so funny
<tissevert>with a space in it like this ?
<zzappie>tissevert: sorry what space?
<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 : )
<tissevert>s/is/is is/
<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>morning all
<colemickens>Is guix purely evaluated by default?
<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
<soheilkhanalipur><nckx "‘bzless /var/log/guix/drvs/vl/zr">
***pocketroid_ is now known as pocketroid
<PotentialUser-75>How do I expand the root partition?
<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
<PotentialUser-75>Ah that is an idea
<Formbi>I'm trying to run pdflatex and it says «Sorry, I can't find the format `pdflatex.fmt'; will try `pdflatex.fmt'.»
<Formbi>what should I do?
<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
<jlicht>cbaines: delete all gcroots?
<jlicht>welp, too slow
<cbaines>I think I've deleted them all, but either I've missed some, or that's not enough for some reason
<leoprikler>cbaines list the referrers?
<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?
<sertified>or had*?
<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?
<PurpleSym>cbaines: Ah yeah, you’re right.
<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?"
<leoprikler>Why should Guix package Gentoo's keychain?
<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
<leoprikler>I wouldn't recommend you start doing so now :P
<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
<yuqio>leoprikler: Okay, thanks :)
<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?
<sertified>PurpleSym: $ jupyter notebook
<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.
<rekado>that’s the spirit
<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 spent some time trying to build substitutes for it
<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.
<civodul>roptat: the post is already pretty clear:
<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
<mhj[m]>Subtract Linux, add Plan 9! ;)
<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>it'll rebuild everything
<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 :)
<irfus>oh, gotcha.
<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>that would be the easiest
<roptat>for gdm for instance:
<roptat>there's a gdm field you can replace with a package where you transitively replace mesa
<roptat>same for the other services
<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, 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?
<irfus>I see, for e.g., where it's the latter. But this is a new major version...
<raghavgururajan>Hello Guix!
<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>raghavgururajan: Hi!
<pineapples>Oh. Would you look at that! My patch has been merged
<tissevert>pineapples: great : )
<pineapples>tissevert: Thanks!
<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>Gud mornink Gweks.
<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.
<raghavgururajan>nckx: Morning Toby!
<nckx>Hullo pineapples, hope you are well.
<nckx>And Raghav!
<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.
<leoprikler>(the cross-signing)
*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»
<nckx>Indeed m'friend.
*tissevert stares at nckx
<nckx>apteryx is on the case, good, good.
<tissevert>: )
<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
<tissevert>(it was patch #48126)
<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.
<tissevert>oh my bad it wasn't the expected format ?
<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
<tissevert>: / sorrryyyyy
<tissevert>I'll try again
<pineapples>nckx: I am! Likewise :)
<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
<raghavgururajan>nckx and apteryx: It is easy.
<raghavgururajan>using email address is better
<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://" "/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.
<raghavgururajan>That's one of the bug.
<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>util that does what I want?
<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>Nice! 1.3.0
<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
<vagrantc>what do you mean by "download into" ?
<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>Do you know what that means?
*luis-felipe retries profile upgrade...
<vagrantc>farkr: ~/.guix-profile ?
<vagrantc>so, finally got a reproducible build for guix on Debian: ... but only on armhf ... seems amd64/arm64 fail on any test suite calling out to gnupg.
<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?
<Ikosit>Because it doesn't…
<cbaines>the URL doesn't matter, it's the contents of the downloaded file that matters
<Ikosit>cbaines: `guix download` changes its output every time i execute it
<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>hi everyone
<rndd>should i translate word "not" in "@emph{not}"
<rndd>in documentation?
<luis-felipe>rndd: I'm not sure, but I'd translate it.
<luis-felipe>The @emph{} part looks like texinfo...
<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...
<luis-felipe>Something related to the "linkchecker" package...
<rndd>luis-felipe: ok, thank you
<luis-felipe>Removed linkchecker from my manifest. Profile upgraded.