<dftxbs3e>adfeno, " luckly, the third-party package-managers provide ways to do that." you said <adfeno>ah, I meant some. I don't know if cargo does. <dftxbs3e>cargo is not an easy one when it comes to opting out their default registry <joshuaBPMan>hey guix! I just made a really really simple endlessh service! I'll post a patch in a few. I've got to clean it up a bit. <pinoaffe>joshuaBPMan: sweet, I think I'll set that up on some of my machines :) <dftxbs3e>alextee[m], I think if you're not alone in that case it's good to add it ***lovetolearn is now known as ltl2
<nckx>alextee[m]: That link uses âbsd0â, analogous to Nix's other âbsdNâ names. In Guix it would be âbsd-0â. <nckx>We use bsd-2, bsd-3, etc., instead of BSD-2-Clause, BSD-3-Clause, ⊠*nckx wonders why SPDX chose such a confusing name for the 0-clause. <alextee[m]>yeah it's weird that they went with bsd-* for the rest <alextee[m]>actually i'll resend it bc the second patch needs an update too <nckx>Thanks for the new package! (I wonder why software like this can't just âreverseâ the X keymap instead, but I've not tried it myself.) <lfam>vivien_: We will update the nettle package, in a few months. Most of the distro depends on it, and we batch updates to packages like that on the core-updates branch <lfam>`guix refresh --list-dependent nettle` <lfam>"Building the following 5054 packages would ensure 10260 dependent packages are rebuilt: [...]" <lfam>The rebuild limit for updating directly on the master branch is 300 <lfam>Why do you ask vivien_? Is there something wrong with it? <vivien_>I'm writing guile bindings for it and the online manual has more and different stuff than what I can test ***jsoo_ is now known as jsoo
<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>I wish I understand it better <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? <lfam>That would be my expectation <lfam>Like I said, I'm not that clear onit <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>I'd guessa a few months, but it's hard to say. No ETA proposed yet, as far as I know <lfam>Now, you could install Guix, update it, and get the LVM support. But it would be annoying to do for an existing LVM deployment <lfam>It's under lvm-device-mapping <GreenishGreenBlu>Iâve wanted to install Guix for a while, but lack of LVM was a dealbreaker. <lfam>Well, hopefully it's not too much longer :) <lfam>It's definitely a great time to *test* the new features, before they get into a release <lfam>I mean, I'm sure they work, or they wouldn't have been added. But sometimes there are corner cases, UI problems, etc <GreenishGreenBlu>Iâm already trying to figure out how to go through what you described as annoying without melting anything. <Aurora_v_kosmose>So, I was getting errors loading openssl on that bot of mine, because it was not included in the end-package as a transient dependency. <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 <lfam>Or, you could use another computer. The `guix system disk-image` command creates something you can flash to a USB stick <lfam>It might not work. We try to validate a bunch of things with the installer before issuing a new release. It usually needs some adjustments <GreenishGreenBlu>The need for adjustment is part of the neatness: Iâll have a margin for error, hence for breaking something and having to learn in order to fix it. <lfam>Notably, it defines an operating-system, which is the Scheme code that defines an operating-system, as handled by the `guix system` command <lfam>There's also a manual installation method. Both are documented in the manual under System Installation <GreenishGreenBlu>Time to run a few errands. I didnât spent long here, but I this is really a great channel and I thoroughly enjoyed the conversation. <lfam>Glad to hear it! See you around <lfam>More like You Gots to Chill by EPMD <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. *Aurora_v_kosmose just tested <lfam>That package includes openssl as an input, not a propagated-input. I don't know how that build-system (asdf-build-system/sbcl) works but usually inputs are not propagated in guix packages <lfam>Maybe it should be here? I don't know anything about those packages <lfam>Yeah, maybe we are talking about different things <lfam>Wait for someone who knows about Lisp stuff :) <Aurora_v_kosmose>propagated-input means visible from profile, I only meant visible to the package itself. <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 ***janneke_ is now known as janneke
<BitPuffin>Is mozc (japanese input) not packaged because of some ethical reason or is it just that nobody did it yet? <Noclip>This issue already existed several month ago so it shouldn't be related to a recent youtube-dl version. <Noclip>In case that's important: I'm using the guix package manager on a foreign distro. <Noclip>I assume there is an easy way to fix this but I don't know how so I hope someone here can help me with it. <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) <Noclip>Does it not work with ungoogled-chromium? <mdevos>nevermind about the question I asked, reset-timestamps suffices <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>"youtube-dl isn't able to use SSL:" <Noclip>Looks like I forgot to setup SSL support for guix according to the manual. I did it now and youtube-dl seems to work now fine with https. <pinoaffe>mdevos: thanks for the tip, as far as I can tell it crashes within a second or two <Noclip>How can I enter an environment that I saved with --root to disk? <leoprikler>Noclip: you can source $GUIX_PROFILE/etc/profile, where $GUIX_PROFILE is the root you saved it to <Noclip>So I have to run "source path-to/etc/profile" in bash? <PurpleSym>Noclip: You can also use `guix environment -p /path/to/root`. <Noclip>That doesn't work like a fresh environment. <Noclip>PurpleSym: That seems to work, thanks. <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 <PotentialUser-51>environment --ad-hoc python emacs python-requests python-soupsieve python-beautifulsoup4 -- emacs <Noclip>Mhh, it's listed on the page for "guix package" so I assume it's not on environment page to keep the manual less redundant. <leoprikler>PotentialUser-51: Could you try a minimal environment with just python and BS4 and launch python directly from it? <raingloom>Noclip: It's also not in the info page. But there is nothing to suggest that --profile is supported, it only links to the common build options page. Should be fixed. <Ikosit>Hi! I have problems packaging pystring. Is there another package, which only uses libtool and has no "configure" file? <Noclip>How could I limit compilation performance? I don't want to melt my laptop ... <mbakke>dftxbs3e: huh, I had not noticed, interesting <dftxbs3e>mbakke, I think it's related to the graph library ***av0idr is now known as avoidr
<andreas-e>Interesting! It said the site is blocked by an extension, but I have not installed any. <andreas-e>Also I tend to get a similar message for certain videoconference sessions. <mbakke>just the "learn more" link gives that message here <mbakke>it's a side effect of the ungoogling, so help pages won't work <dftxbs3e>it replaces "google.com" with random domains like this <Ikosit>At what stage in the build process the output directory is created? <mbakke>vherrmann: typically during installation (guix does nothing magic in that regard, it's up to the build scripts) <dftxbs3e>mbakke, also do you think ungoogled-chromium should propagate xdg-utils since it depends on it for xdg-open (opening mailto links on issues.guix.gnu.org for example) <mbakke>dftxbs3e: it would be great to encode the absolute xdg-open file name in the binary <dftxbs3e>It would be nice of Nyxt was written in Scheme <Ikosit>mbakke: thanks, now my package works :) <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) <mdevos>PotentialUser-51: is using the browser version sufficient? <PotentialUser-51>I suppose maybe? Is it possible to use videoconferencing in the browser version? <mdevos>Unfortunately, I can answer "yes" to that question. <mdevos>(with "unfortunately" I mean MS Teams is not free software) <mdevos>idk if I used IceCat or ungoogled-chromium <mdevos>in case you're out of options, (a) complain to Microsoft and (b) set up a Debian VM and install the .deb <dftxbs3e>(A) Refuse to use MS Teams to your employer and suggest Jitsi/BigBlueButton which work well and are Free Software <dftxbs3e>And it has public instances that provide as much data security as MS Teams (which for better data security you setup your own instance) <roelj>Does someone have /gnu/store/hpq6b6znqk85x0v6l5qnzzwnmxhk01jc-BSgenome.Hsapiens.UCSC.hg19_1.4.0.tar.gz? :) <roelj>Nevermind^^ I found a link to it. <dftxbs3e>anyone here uses gnu-debbugs in emacs, how can you easily pipe to git-am content of patches? *raghavgururajan *sounds-horn* Psi and Psi+ are on the way to Guix *sounds-horn* ***pocketroid_ is now known as pocketroid
<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 <roptat>in this commit, I changed php, so I expected to see some evaluations <roptat>I need to check it works, and I'll send a patch this afternoon <brown121407>Is the way to create a meta package on Guix to just have a package with no build steps, and with the related packages set as propagated inputs? ***apteryx is now known as Guest82559
***apteryx_1 is now known as apteryx
<pkill9>what meta-package do you want to create? <dftxbs3e>marusich, I got an openjpeg failure, not valgrind <dftxbs3e>marusich, can't find anything about it anywhere, probably due to gcc-8, it's some test failures <dftxbs3e>marusich, obscure to me, I am not very motivated to work on PowerPC 64-bits porting now, will come back to it later, I need fresh air, I will be trying to package cryptpad <_mdevos>brown121407: I would suggest using trivial-build-system, but maybe there's a better way <brown121407>pkill9, not looking to build anything right now, I was just curios thinking about PotentialUser-76's question <jackhill>brown121407: the gnome package is an example if you want to look at one. <jackhill>I would also appreciate some sort of guidence for TeXlive. I'm using the all-in-one package right now, and would like to move to the individual ones, but don't know where to start. <zdm>was wondering how chroot would work with guix? <zdm>/gnu/store/*bash/bin gives permission denied <zdm>i made sure to mount with `-o exec' when i mounted the filesystem /mnt, so im not sure where/what im doing wrong <zdm>any guidance much appreciated <zdm>i asked hetzner to upload iso for me, which they responded asking for a direct link, which i gave a tar.xz to. but they didnt decompress or it anything, so that doesnt work hehehe... <brown121407>zdm, weird, since I asked them to do the same thing and the image they added for me was the decompressed file <zdm>brown121407: they just uploaded the xz file haha <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 <zdm>Yeah they replied to me: "Unfortunately we are not able to extract the ISO. Please send us a new link for the ISO, with the .iso extension." <terpri_>zdm, just send them an email with the uncompressed .iso attached ;) <zdm>A 500MB email attachment? haha <alextee[m]>should I put kgraphviewer in kde-frameworks.scm? <zdm>random question: whats with all the [m] in peoples nicks <alextee[m]>also, should I put massif-visualizer in kde.scm or in valgrind.scm ? <brown121407>zdm, do you have another server from where to serve them the uncompress image? <zdm>I do not, unfortunately. <zdm>Maybe I could email the guix mailing list and ask if the Guix project would be willing to serve direct ISO files. I don't know how annoying that would be for the Guix devs though. <zdm>I suppose I could just upload the iso to a repo on a git hosting service or something though <zdm>Yeah probably just do that instead of bothering Guix devs, better use of time. <terpri_>gregds91, well, for starters guix doesn't normally have a "kernel partition", instead grub is configured to load the appropriate kernel/etc. from /gnu/store <dftxbs3e>dongcarl, send "close <id>" to control@debbugs.gnu.org <dongcarl>dftxbs3e: Thanks! Do I need anything in the title? ***zimoun` is now known as zimoun
<andreas-e>dongcarl: Or send a message to xxx-done@debbugs.gnu.org, where xxx is the bug number. I do not remember whether this message also appears on the webpage of the bug. <terpri_>gregds91, but i wonder if depthcharge could conceivably chain-load another bootloader instead of a kernel (sort of the reverse of efistub) <leoprikler>done sends a message to everyone, close doesn't afaik <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 <GNUtoo>ison1: in guix source code I didn't find any, I grepped for 'master' <GNUtoo>What I'm trying to do is use origin/master automatically, so guix will fetch the last revision, always <GNUtoo>So for instance the "Extended example has: <GNUtoo> (let ((commit "e98d0a37c93574d2c6107bf7f31140b548c6a7bf") <GNUtoo>I'd like something with origin/master instead <GNUtoo>The use case is that I've a guix.scm to build a software that only works on Android, <vagrantc>you need to know the hash of the commit, so that's not really possible <sneek>Welcome back vagrantc, you have 2 messages! <sneek>vagrantc, dongcarl says: why did you switch from Guile 3.0 to 2.2 for the debian Guix package in db204bf310fe11a2d2fa92b7afabafe6b0c6565f? <GNUtoo>And it has 1 dependency that is a library that I need to test with, and I'd like to use origin/master for that library <vagrantc>dongcarl: switched to guile 2.2 because guile-gnutls in debian wouldn't build reliably on guile 3.0, so the gnutls maintainer reverted the switch to guile 3.0 ... <GNUtoo>And for the Android software, I manage to build the current source with the trick that is described in the guix day presentation about guix.scm <GNUtoo>So indeed it requires a hash, but maybe it could be computed somehow, like with git fetch <dongcarl>It's... not the best... I've been appreciating the scale of what you did more and more recently as my community members all try to build Guix and its dependencies from source... <vagrantc>zimoun: nice to hear it's actually being used :) <dongcarl>Most of the time I just reference your debian/rules lol <vagrantc>dongcarl: most of the work was done by computers, i just told them what to do :) <ison1>PotentialUser-30: if you're running it on a foreign distro have you tried sourcing ~/.guix-profile/etc/profile? <GNUtoo>Though I'm unsure if we can fetch the last hash of a branch easily without a git clone <GNUtoo>Maybe that'd be the way to do it though <ison1>well you can use tags instead of commits, maybe there's a way to do it by tagging the latest commits, but I don't know <GNUtoo>That would probably be complicated <GNUtoo>Though maybe with curl I can fetch the last revision <GNUtoo>Thoug we use cgit so I'd need to find a way in our infrastructure to do it cleanly <GNUtoo>I've already examples to run commands and I reused it in the guix.scm of that dependency <GNUtoo>So I probably need to find a command line that can get me this hash <GNUtoo>and I'd probably then need a way to tell Guix to compute the sources hash automatically <cbaines_>GNUtoo, if you want Guix to fetch the tip of that branch when the package is built, you can use (git-fetch ...) as the source I think <GNUtoo>The issue is that I'm in a source directory of a package (libsamsung-ril) but I want master on a dependency (libsamsung-ipc) <cbaines_>I'm not sure there are examples of that use in the guix.git repository <GNUtoo>I probably need to look for guix.scm in various packages <GNUtoo>So that's why I went asking here <GNUtoo>in case people knew which ones to check <GNUtoo>or if they used similar tricks in their personal system.scm <cbaines_>and you're sure you want to use whatever commit master is pointing at right? Rather than a fixed commit? <GNUtoo>Else we'd have to modify this hash all the time <GNUtoo>(and it would polute the git repository) <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 <mdevos>(Use "C-U M-X shell" for multiple shells) <mdevos>Also, in mind you can define a channel in the same repo as the python project, see â6.6 Package Modules in a Sub-directoryâ <shcv>yeah; I guess env support within emacs isn't essential; for a long time I've been running stuff in external shells anyway <shcv>ok, thanks; I'll look at that <mdevos>... and there's of course the option of submitting package definitions upstream. <shcv>Yeah, that might be helpful for the dependencies; I don't know that my work is ready for upstream yet <mdevos>shcv: is your work something with a public repo? <mdevos>(I'm wondering what other people use guix for) <shcv>I'm not using guix yet, (except for recently switching my personal machines to GuixSD) but I was thinking it might be a good for making my research more reproducible <shcv>so after looking at what you pointed out, I think I'll make a common channel with the main dependencies I have across projects (and possibly submit them upstream when I figure out how) <shcv>and then make each of my projects also a channel, with the module in a subdirectory and a dependency on the common channel <shcv>then I'll need to figure out how to make a build/run script for actually running everything <shcv>do .guix-authorizations fingerprints need spaces? <mdevos>shcv: no idea, maybe just copy the conventions used in the .guix-authorizations of the guix repo? <shcv>I wonder if there's a way to generate that... <mdevos>I don't think there is, but perhaps copy the .guix-authorization, throw out everyone but andreas <mdevos>and change the key fingerprint & name field appropriately? <GNUtoo>I still need to generate the hash but I'll see that later <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) <shcv>I might just try it to see what happens... <shcv>though... does adding a channel as a dependency actually import all of its packages? i.e. make it a 'union channel'? <mdevos>shcv: I think so, yes. Maybe it's more convenient to keep all package definitions in the common channel, though ***rekado_ is now known as rekado
<shcv>right; I guess the instructions for each of the other projects would be pretty similar regardless of where the channel was kept <shcv>plus that way I only have to worry about keys and such for one repository <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>dongcarl: is the derivation the same? <dongcarl>zimoun: How do I go backwards from a profile path to a derivation path? <dongcarl>zimoun: Say, my profile is /gnu/store/8wskrs6hx1s82m6lyzm0l6p4r6lb0gwh-profile <dongcarl>Man... there are so many useful flags... <mdevos>Maybe check whether you are on the same architecture <zimoun>g_bor[m]: you mean discuss alive? <zimoun>dongcarl: you should check the âconfig.scm-builderâ file in the derivation. And see â(define-public %sysconfdir "/usr/local/etc")â on your â./pre-inst-env guix pullâ <g_bor[m]>No, mainly are your questions public, or should we go to a private messaging? <zimoun>g_bor[m]: my questions are about the end of the Outreachy the next week. And what is the usual end? These kind of questions <g_bor[m]>Ok, I think we can keep it here then. We can move to another channel if something comes up. <g_bor[m]>One thing that is important is to get the code merged. <g_bor[m]>Another is to provide the final feedback. <zimoun>the code is not ready to be merged before the next Tuesday. <zimoun>it needs review and some clean up. <zimoun>well, only one or two features could be merged <g_bor[m]>Two things would be nice: get a blogpost about the final state, and do some kind of celebration. <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>that just the code needs careful review. I mean, for I example I have not carefully reviewed. Well, we should have our last meeting on Monday or Tuesday. <zimoun>For the review, maybe it is better to send the patch set via guix-patches? WDYT? <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. <zimoun>Ok, it could be a section. I agree that it is important to demysthify both the participation and mentoring. <zimoun>my pleasure, it is a really intersting experience <zimoun>g_bor[m]: BTW, could you merge a patch to maintenaince/doc/outreachy sent on 07 Dec. with Message-ID 86blf55rh2.fsf@gmail.com? <g_bor[m]>I will have a look at that that this weekend. <g_bor[m]>I will also check the outreachy ideas page, and send a reminder to prospective mentors if the proposals are not on the outreachy site yet. The submission deadline is 7th March. <g_bor[m]>We don't have anything new from the gsoc coordinators yet. The next step there will be the slot assignments. <jackhill>DrimysWinteri: after a quick look at `guix search` I see: emacs-matrix-client, quaternion, and nheko *lfam tests updating the default linux-libre kernel to 5.11 <lfam>Now's a really good time to test your stuff <lfam>It's no more special than usual <lfam>I just like to warn people when updating the major version of the default <zimoun>lfam: maybe it deserves a --news <lfam>Maybe... there's usually few kernel updates between releases <lfam>Oh, I forgot that --news is part of `guix pull` <lfam>Does it need to be translated? <zimoun>well, if you submit the patch to guix-patches, I guess the review will transalate to French, German and Spanish, at least. :-) <lfam>I don't want to wait for the code review process for this <lfam>Or rather, I don't want to add to the reviewers' workload <roptat>if you give me the text, I can translate it in French for you on the spot :) <lfam>Please, feel free to suggest improvements <lfam>I wasn't planning to do this so I just made it up / copied it from the Kernel Newbies website <lfam>Oops, I forgot to include that in the paste <lfam>"The @code{linux-libre} kernel is updated to 5.11.2" <lfam>I guess the main text should end with "[...] and improved Btrfs performance." <lfam>The Guix system tests I've tried are all succeeding with the new kernel version <lfam>I never knew the French word is noyau <lfam>I suppose it's no more ridiculous than the English "kernel" <roptat>same word as for what's in the middle of a fruit (when it's big enough and there's only one), don't know the English word for that... kernel? <nckx>lfam: Ignore my last mail; hadn't seen your commit was to maintenance (not artwork). I'm reconfiguring berlin. <lfam>You could say kernel but it's not idiomatic <lfam>Usually we say "pit", but you have to give the name of the fruit also. Like "peach pit" <lfam>Well, wikipedia say it is idiomatic, but you might get some funny looks <roptat>alright, need to go, I'll send my patches to bootstrap ocaml later tonight :) <lfam>We also say "stone", and all those fruits are called "stone fruits" <shcv>I usually think of kernel for smaller seeds <shcv>like "a kernel of corn"" <roptat>what about grape? do you simply say grape seed? <lfam>Yeah, the grape seed is too small to be a kernel, stone, or pit <leoprikler>according to Wikipedia it seems to be mostly corn and wheat? <lfam>They also describe "apricot kernels", which sounds weird to me <lfam>I already sent the email but it will be useful in the future <leoprikler>Well, etymologically it comes from the German "Kern" and Aprikosenkern would make sense. <shcv>what's the right way to have a python package output a cli program? <shcv>I'd be happy with an example, but I can't think of one at the moment <leoprikler>IIRC python-build-system should already do this (if applicable) <shcv>ok, it installs the script with `guix install`; guess I was mistakenly expecting it to appear in `guix environment` <nckx>shcv: Did you omit â--ad-hocâ? <shcv>though now I apparently need to declare an additional file (a grammar spec "bspl.gr") that wasn't copied <shcv>why does guix have to rebuild the entire man page database after every change to my profile? It's usually the longest step <shcv>interesting; --add-hoc doesn't add the script either <leoprikler>because that part's implemented as a hook and if you change a program, chances are it installs man pages <nckx>I'm not sure what you mean by âadd the scriptâ. The difference is: guix environment hello -- hello â nope; guix environment --ad-hoc hello -- hello â Hello, cruel world. <shcv>ok, I think it's because my shell is overwriting the environment <nckx>Did you edit your ~/.bashrc or so? <nckx>That's a common source of bugs. <shcv>yeah, I have a really old .zshrc I've added things to over the years <lfam>Guix exposes the crucial difference between login shells and non-login shells <lfam>And thus, the difference between zshrc and zprofile <nckx>And I don't know what .zshrc is in that context âș <shcv>I guess the question is how much I should move to .zprofile vs eliminate entirely <nckx>Rule of thumb: if it's an exported variable (like PATH), and it's in bashrc, and you don't know why, it's wrong. <shcv>I really should clean it up; I'm cleaning up a lot of things in my current migration to a new computer anyway <leoprikler>I could probably gain a few lines if I added insults for "command not found". <nckx>I think my first commit to Nix was adding the insults to sudo. <nckx>It was definitely one of the first. <nckx>So yes, this is a priority. <nckx>I don't actually know if they're enabled. I've matured, now it just prints âNo.â. <pkill9>does anyone have a direnv type setup for entering guix environment when entering a folder? <nckx>Does not seem to be enabled, so you'd need to add the configure flag. <leoprikler>well, I could also make it print ă¶ăŁă¶ăŒă§ăăŻ, but there's only so far you can go with static strings. <shcv>pkill9: I don't, but I'd be interested in setting one up <leoprikler>But even if we recompiled it, how would you enable it? <shcv>though I'd also be interested in an emacs version <nckx>leoprikler: Just add âDefaults insultsâ to sudoers? <nckx>Not everything needs to be a service, Guix. <leoprikler>Oh, sudoers is one of those files that Guix doesn't touch? <nckx>leoprikler: Well, I have (sudoers-file "/etc/guix/sudoers") . <nckx>Guix touches /etc/sudoers. <leoprikler>Ahh, but one can make that a file or file-like object <leoprikler>And it's directly at operating-systems level, interesting.