<marusich>lfam, nckx, dftxbs3e, regarding merge vs. rebase, if the problem right now is that there are conflicts when merging from wip-ppc64le into core-updates because I merged master into wip-ppc64le a while ago, wouldn't we still get the same conflicts if we rebased the work on master? Either way you are going to wind up "combining master with core-updates", aren't you?
<marusich>cbaines_, when did you get conflicts? when merging wip-ppc64le into core-updates, or some other merge?
<marusich>My understanding is that rebasing frequently and merging frequently are equally likely to produce conflicts.
<marusich>If I'm misunderstanding something and it is less likely to obtain conflicts by rebasing instead of merging, then I'm curious to know more about it.
<marusich>As for seeing changes on the branch which are not from elsewhere, try "git log wip-ppc64le ^origin/master ^origin/core-updates". It shows exaclty the commits that we have made on the wip-ppc64le branch.
<marusich>It does not call out cherry picks, of which there is one or two, but that's another story.
<marusich>In any case, I'm happy to help resolve whatever conflicts have arisen, and I'm also totally willing to rewrite the history of wip-ppc64le if everyone thinks it's a good idea.
<lfam>marusich: I think it was a problem with Guix commit signing key authorizations, not with Git history conflicts
<marusich>OK. So the issue is that potentially, something might not work (like guix pull) because lle-bout made a commit on wip-ppc64le before the commit adding them to .guix-authorizations was put into the branch.
<marusich>By the way, does anyone know offhand how .guix-authorizations is obtained? Presumably it is not obtained from the repository we are attempting to authenticate.
<lfam>IIRC, the main issue is that they couldn't push their changes to savannah
<marusich>Oh, maybe I misunderstood; I assumed .guix-authorizations was used in the process of authenticating during "guix pull" but maybe I'm wrong.
<lfam>I think it's used in both places. It's optional during `git push`, since it is implemented in a Git hook, but if the authentication fails when pushing, then something is wrong
<marusich>What I want to know the answer to is: is it necessary to have the change that adds lle-bout to .guix-authorizations on the wip-ppc64le branch, and if so, does it have to appear as an ancestor of the any commits made by lle-bout?
<GreenishGreenBlu>Hello there. Could anyone tell me is LVM support is available in the Lastest release?
<GreenishGreenBlu>There’s a 3-month old post in Reddit announcing it, but I could find no further information.
<Aurora_v_kosmose>Hm. Peculiar. "guix pack -RR -S /README.md=share/common-lisp/sbcl/my-bot/README.md -S /test-config.json=share/common-lisp/sbcl/my-bot/test-config.json -S /run-my-bot=bin/my-bot my-bot", this package fails to run on another machine.
<lfam>GreenishGreenBlu: No, it will be in the next release
<lfam>It's available for Guix users now, but not included in the previous 1.2.0 release
<Aurora_v_kosmose>Hm, yes. SBCL seems to have kept the full library path in an internal loading variable.
<lfam>GreenishGreenBlu: I'm thinking about how I'd approach it...
<lfam>I think I would install Guix on top on the existing OS (assuming it's linux), update Guix to include the LVM support, generate a new installer image with `guix system disk-image gnu/system/install.scm other-interesting parameters`, and then use that new image to install the full Guix System
<Aurora_v_kosmose>So, if I got this right. cl-cl+ssl doesn't propagate openssl, seemingly. And my program which depends on cl-cl+ssl doesn't error-out on build-time because it only ever tries to load it at run-time.
<lfam>Aurora_v_kosmose: You mean the sbcl-cl+ssl package?
<Aurora_v_kosmose>lfam: No, I build it using sources for everything. No particular reason.
<lfam>I guess that depends on if the program records the location of openssl at build time
<Aurora_v_kosmose>When I compiled it from source bottom-up, it did and error'd out when I failed to explicitly list openssl during "guix pack"
<Aurora_v_kosmose>I can't say if it records the location for binary/sbcl inputs, as it included openssl without need for explicit mention in the tarball.
<lfam>It looks like the package definition tries to fix something related to this
<Aurora_v_kosmose>I'm unfortunately too unfamiliar with the more involved internals in Guix, so I figured I'd get told off by someone more knowledgeable if cl- source pages are indeed intended to strip all non-lisp inputs or some other shenanigans.
<lfam>I'm sure it's supposed to work the way you expecet
<dftxbs3e>marusich, yes my commit would have to come after I think
<dftxbs3e>maybe I shouldnt have pushed it, don't know, can always rewrite
<leoprikler>BitPuffin: IIUC it's just "not done yet", but I'll have a look at potential ethical reasons.
<leoprikler>Yeah, there might be some work to do w.r.t. unbundling mozc and also stopping it from promoting its branded offshoot.
***apteryx_1 is now known as apteryx
<pinoaffe>I've got a mysql service set up on guix system, but it crashes whenever I try to start it - anyone know how I could debug this?
<mdevos>does guix have a procedure to normalise permissions and timestamps to what is expected of files in the store?
<mdevos>pinoaffe: if it takes a little time to crash, you could use gdb -p $MYSQL_PID
<brown121407>Hi, is there any browser avaialble on Guix where MS Teams works with audio calls and screen sharing? I am forced to use that for university and I don't really want to switch from my Guix machine...
<mdevos>icecat worked I think (with LibreJS disabled and some exceptions made in TPRB)
<brown121407>mdevos, I don't know what TPRB is but i tried IceCat with the extensions disabled and a lot of cookie permissions for Teams and even switching user agent (and other firefox based stuff) and it fails to join a calls.
<brown121407>Noclip, on ungoogled-chromium i can join calls and talk, but it crashes the page when I share the screen
<Noclip>"guix environment -p" seems to be missing in the manual?!
<PotentialUser-51>Hello! Running Guix as a package manager on a foreign distro, launching an ad-hoc environment to work with Python in Emacs org mode! Bit of a mouthful! Anyway my issue is that one of the packages, BeautifulSoup4, depends on another package, soupsieve, but I'm getting the error that soupsieve is not installed. I'm loading the environment with: guix
<mdevos>brown121407: ungoogled-chromium also crashes when trying to share the screen or camera on Discord. The crash is probably not specific to Microsoft Teams. Unfortunately, I'm not in a position to take a look at how exactly MS Teams and Discord access video and screen
<dftxbs3e>mdevos, but things work with Jitsi apparently
<mdevos>dftxbs3e: is that an in-browser thing, or an application thing?
<mdevos>Now if only MS Teams and Discord were free software, then I could compare the relevant JS code, and experiment with it to figure out the crash, and perhaps submit a patch to MS Teams and Discord (crashing is a browser bug, but a workaround would be nice)
<davexunit>anyone ever have an issue with guix deploy where it said "unauthorized public key"? I re-authorized my local system's key with the remote server I'm trying to update and the error persists.
<PotentialUser-76>Hello! Is there a way to get a useful subset of texlive packages, like Nix's texlive.combined.scheme-medium or Arch's list of 19 texlive packages? There's a lot of texlive packages in Guix, and it seems I can either install texlive and get the entire distribution which is more than I need or I am stuck with finding the correct set of lots of smalle
<brown121407>I see that i have added "Be sure to unpack them as they are XZ archives (but I'm sure you guys know all that :p)" in my mail to them. Maybe i shouldn't have been so sure they knew after all haha
<zdm>Maybe I should re-send them another email, but i dont wanna bug.... but maybe the included ":p" would help smooth things over..
<brown121407>Haha maybe. I think people are not used to images being archived so they maybe didn't even look at the extension
<gregds91>I have an ASUS C201. It uses Libreboot's depthcharge payload instead of the GRUB payload. To install Debian with root encryption, it is necessary to create an unencrypted kernel partition and leave some space before it. How could I do that with Guix? Has anyone successfully installed Guix System on the C201 with disk encryption?
<zdm>brown121407: they said they can't extract it lmao :(
<zdm>maybe if guix could provide just a .iso.... that'd be great hahahahaha
<leoprikler>you should send a message to -done if you're closing the bug by merge or whatever, there might be some reasons for "close", but they're few and far between iiuc
<terpri_>gregds91, for testing you could also try just manually installing the latest guix system generation's kernel+initrd as what depthcharge boots, though that's not ideal as a long-term solution (no ability to boot into previous generations)
<GNUtoo>hi, is there some examples somewhere of package definition to build them from git origin/master or similar
<zimoun>g_bor[m]: hey! how are you? I have questions Outreachy ending next week, I guess.
<PotentialUser-30>Hello, I've guix installed evince, calibre, and xdg-utils, but I'm still getting this error when opening a pdf book in calibre: Launch failed (/gnu/store/zjb9qdgvqncjkq7a80089cmq7dbpc5xq-xdg-utils-1.1.3/bin/xdg-open file:///home/lestephane/Vault/Books/Caleb%20Doxsey/Introducing%20Go%20(631))
<PotentialUser-30>I more generally am unable to xdg-open anything through graphical apps installed through Guix. I'm looking for hints as to what I'm missing
<PotentialUser-30>ison1: sourcing .guix-profile makes no difference for Calibre. `xdg-open` invoked on its own works, but the error message refers to an xdg-open that is not present on my system (/gnu/store/zjb9qdgvqncjkq7a80089cmq7dbpc5xq-xdg-utils-1.1.3/bin/xdg-open)
<cbaines_>GNUtoo, hmm, I think my information is out of date, as I can't see the relevant code
<GNUtoo>I'll try that in the absence of other better options
***aidalgol_ is now known as aidalgol
<shcv>hello; I have a python project for which I would like to perform and share reproducible experiments; how would you suggest I do so? Make a channel with the extra dependencies I need, or just a single module file in the repo?
<shcv> also, if I make an environment with `guix environment` for my python package, how can I get emacs to work within like with venvs? E.g. for pytest, run-python etc.
<shcv>(since I'm running everything in emacs, I'd rather not have to restart emacs within the environment)
<mdevos>if the experiments are tightly bound to the python project I would just create a single module file
<mdevos>idk how venvs in emacs work, but I usually run "guix environment STUFF" from a shell in Emacs
<shcv>hmm; can you have circular dependencies between channels?
<shcv>I guess that probably doesn't make much sense
<vagrantc>circular dependencies seem like something you don't want :)
<shcv>well, I'd like to have a channel of common dependencies, and make each of my projects to some extend 'independent' (so they have their own package code, and scripts to run them), so I could just have each of them depend on the common channel
<shcv>but it would also be nice to have the common channel include the other projects so nobody (including myself) has to add them all to get all the different projects
<shcv>since they're build-time circular I don't think it should be a problem (just download both, so both are available during build)
<ison1>PotentialUser-30: Maybe try using a package manifest
<dongcarl>Question: A colleague and I are building the same manifest, we time-machine to a specific commit, then use `guix environment --manifest=...`, however, our resulting profiles have different hashes, even though the `manfest` file inside the profile dirs are identical. How could that be?
<dongcarl>I guess a good place to start would be: other than the `manifest` file, what else determines the hash of a profile?
<mdevos>dongcarl: no idea, maybe use "diffoscope" to check if the contents of the two profiles are different somewhere
<zimoun>today, at our weekly meeting, I asked to write 2 emails: one about a technical point and one about the achievements. More, I proposed to write a blog post for their personal blog and then probably re-use it for the Guix blog.
<g_bor[m]>Do not worry too much about getting all the features in. If something is in a resonable shape, have that merged. Hopefully we can handle the rest later.
<zimoun>Ok, so to summary the end of Outreahy: blog post + review and merge as much as possible, right?
<g_bor[m]>I would say yes. It would be also nice if you could create a post about your mentoring experience and we should coordinate in how to thank for the work. These seem to be important from a psychogical standpoint.
<g_bor[m]>From where I am standing you both were working exceptionally hard in this timeframe, and the new features are really cool.