***leoprikler_ is now known as leoprikler
<lfam>It's so nice to watch the substitutes speed by <lfam>What a huge improvement! <txgvnn>Anyone built and using Vagrant tool? <txgvnn>I'm trying to build but don't know how to setup Gem dependencies <kozo[m]>sneek: later tell mothache: Thank you for the work on discoverable publish servers <ryanprior>sneek: later tell txgvnn: I use vagrant but haven't looked into how much work it would be to package in Guix. <ryanprior>Also it would be cool to have a replacement for Vagrant that uses Guix system definitions instead of Vagrant system definitions. <ryanprior>Using Guix to install a system that manages systems represented as code seems slightly silly. <txgvnn>ryanprior: How do you use vagrant. I tried to download vagrant binary from their homepage. But it can not work. (I'm using Guix System) <sneek>txgvnn, ryanprior says: I use vagrant but haven't looked into how much work it would be to package in Guix. <txgvnn>Then I look into Nix to see how Nix define vagrant package :P <ryanprior>That's smart, should give you an idea what the dependencies are <txgvnn>I hope so :( But I can not map from Nix to Guix <ryanprior>I use the Debian package for Vagrant, and I saw recently dpkg was added to Guix, so that's something you can try <ryanprior>I haven't tried Vagrant on Guix System, I use elementary OS (based on Debian) and I run Guix System inside Vagrant X.X <txgvnn>I wonder I have to build Gem into guix packages or just download and install it into vagrant path? <ryanprior>You should be able to use bundler & gems like normal, you don't need to create a Guix package to install software. <ryanprior>Also the project's README specifies: "Vagrant requires bsdtar and curl to be available on your system PATH to run successfully." <ryanprior>I'm not sure if Guix has bsdtar? Anybody know about that? <ryanprior>But I don't have an executable called "bsdtar" on my system & Vagrant works fine, so maybe it just means you have to have normal "tar" I dunno <smithras>so maybe they're using/testing with the bsd version but it works on the GNU version as well <ryanprior>Hell yeah dude that's a good start, I can tell one thing right away though that's gonna be a hitch <khassanov>Hello guys! Anyone use Guix on NixOS? What the preferred way to install it now? <ryanprior>Guix shuts off network access for builds to ensure reproducibility, so you need to fetch all the dependencies ahead of time that you're going to need, you can't just let bundle take care of it all like normal <ryanprior>So that big list of gem dependencies I sent you, we're gonna have to add those explicitly as inputs <ryanprior>Also you'll need to check that all those gems are already packaged in Guix, otherwise we might have to package them first. That can take a while too. <ryanprior>I'll emphasize that you don't have to create a package to use software, it might not be worth your time to do all this. But the end-result of making a package is that we know it'll be totally reproducible :) <ryanprior>And if it /is/ something you're interested in doing we'll be here to advise & encourage & collab <txgvnn>Recently, I built a package for ibus-unikey. Could you add it into Guix? <ryanprior>Do you know how to format and email a patch? The official way to send packages for inclusion upstream is to e-mail a patch to guix-packages@gnu.org <txgvnn>Ya, I know. I just be lazy =)). I will <ryanprior>Ha understandable! That's why I'm working on guix-packaging.el, to indulge my laziness by automate ever-more of my packaging tasks. <ryanprior>I haven't got around to automating the patch submitting workflow yet, but that's on the radar eventually. <txgvnn>Do you push guix-packaging to MELPA yet? <smithras>khassanov: can't say I have :/ A lot of the active people here are in European time zones, you might need to wait a bit to get an answer <ryanprior>txgvnn: I would like to make it available in GNU ELPA if they'll have it, but I need to figure out what the process is for doing that. <ryanprior>I think the code quality has to be very high, and I've been leveling up my elisp skills but there's a lot to learn. And at the same time I'm trying to add features. <xelxebar>Hey, Guix. Want to poke your brain. I am trying to package J (the programming language), and the interpreter comes in three variants---non-AVX, with-AVX, and with-AVX2 extensions. <xelxebar>Previously, when I packaged this for a different distro, I just built and installed all three versions under /lib/j and created a script under /bin that detects CPU features and launches the most AVX-y interpreter at runtime. <xelxebar>My questions is two-fold: Is this a reasonable approach for Guix, and if so, is there a standard approach for creating wrapper scripts that do more than just set environment variables? <efraim>ryanprior: I think bsdtar is in libarchive <efraim>sneek: later ask civodul has the ungrafting branch started building yet? <sundbry>Is there a way I can inspect a failed build using `guix package -f mypackage.scm`, guix is extracting some working files to /tmp and they are cleaned up on failure so I can't diagnose it <ngz>sundbry: Use guix build -K -f ... ***iyzsong-- is now known as iyzsong-w
<jonsger>hi mothacehe, thx for your queue-size patch for cuirass :) <davidl>mothacehe: thanks for the patch! Also tested it yesterday, works great! <davidl>mothacehe: what do you think about developing an option to monitor/build-continuously a set of git-packages at a specific branch - say you can add something like this to your cuirass-spec (#:proc-args . ((subset . manifests) (manifests . ((config . "manifests/user1.scm"))) (git-follow . ("emacs@test" "ruby@develop" "pkg@branch"))) ? <davidl>I wrote a script that does something like that, but it would be nice to have it built-in to cuirass. <mothacehe>davidl: yes, I agree it would be a nice feature. It's a bit like what people are trying to achieve with .guix.scm files in their projects, but built continuously, right ? <dftxbs3e>surprising there's no go importer seeing all the go packages that exist and look similar currently <davidl>dftxbs3e: that TWM looks cool, I can't wait either <efraim>sneek: later tell civodul I pushed a patch to ungrafting to patch a CVE in libssh2, which will cause a full rust rebuild. I guess some of the others will too though. <sneek>Welcome back civodul, you have 2 messages! <sneek>civodul, efraim says: has the ungrafting branch started building yet? <sneek>civodul, efraim says: I pushed a patch to ungrafting to patch a CVE in libssh2, which will cause a full rust rebuild. I guess some of the others will too though. <civodul>was the libssh2 change tested before? <efraim>civodul: I tested it locally, it seems fine <efraim>It's supposed to help against a malicious server. we could revert it and keep the ungrafting branch for ungrafting though <civodul>efraim: if you're confident we can try, i just want to make sure we don't end up in the usual wait&fix loop :-) <civodul>efraim: BTW, could you add the usual header to (gnu services science)? <civodul>i just noticed it was lacking as i was browsing <efraim>oh, didn't even notice that was missing <efraim>we don't want to give vagrant more work, have him strip it out of guix in debian :P <maav>how ru, civodul and guix in general? <maav>btw, civodul, nice ungrafting branch :) ***r7st`` is now known as r7st
<civodul>can't really speak for Guix but i think it's doing ok ;-) <civodul>hmm looks like pciutils fails to cross-build to i586-pc-gnu <rekado_>for wip-r: 83.0% substitutes available (1,264 out of 1,523) <abcdw>I have a quick question, why leiningen (clojure build tool) isn't in official guix channel? I know it's already packaged, but not upstreamed to Guix. Is there some issues with lein? <civodul>abcdw: i think it cannot (or not easily) be built from source <civodul>i don't recall the exact details tho <maav>civodul: yup, 1.2.0 was a supercool release, the bar might be set too high now :-) <abcdw>civodul, thanks, yep the package definition I found just downloads the jar file, which isn't what we want. Will read those thread, thank you! <civodul>what are you up to? we still have GRUB patches floating around, right? <maav>yes... i'm right now working on gettext, mainly issues with plural forms <maav>i've been out most of this time, so i'm mostly at the same point... but i have some tentative patches with localized-text-file in the backlog :) <maav>also, i was looking into the boostrap chain, libc include files and gcc-10 (which seems that the test for <fenv.h> needs a -lm to work properly... :( <civodul>that one's tricky, but if you could figure out what to do, you'd be our hero <civodul>the more i think about it, the more #include_next looks like a brittle hack to me <maav>the main issue i see is that we shouldn't mess with libc and libstdc++ include paths as they are an implementation detail... but we have to at the bootstrap stages, so perhaps using the PREFIX_INCLUDE_DIR to embed the libc into the compiler could be an option, or add an ordering to the path variables, or using -idirafter for libc alone... too many options and each one takes ages to compile and debug on my machine <cbaines>I don't know whether that's helpful though, I haven't been following the discussion <civodul>why is build info missing on data.guix.gnu.org? <jonsger>cbaines: using guix-build-coordinator requires the guix-data-service running or? <cbaines>civodul, just because I've got guix.cbaines.net sending data to data.guix-patches.cbaines.net. It felt a bit odd to send it to data.guix.gnu.org. <cbaines>jonsger, no, but the Guix Build Coordinator doesn't do anything to determine derivations to build, so that needs to be handled separately. ***chrislck_ is now known as chrislck
<jonsger>cbaines: so cuirass is not supported for providing derivations via evaluations? <cbaines>jonsger, I think mothacehe was looking in to something like that at some point, but it's a bit odd architecturally, since both Cuirass and the Guix Build Coordinator are keeping state about builds <cbaines>at some point I'd like to get the Guix Data Service working properly with channels in general, as that might be useful. <jonsger>cbaines: ah so the dataservice doesn't support channels at all? <cbaines>jonsger, well, it works with the default guix channel, but it's not as capable as Cuirass when it comes to working with something like the guix-past channel <jonsger>guix-build-coordinator looks a bit overkill for my purpose but those build hooks look nice :) <cbaines>jonsger, a simple script that just pulls the channel, computes the derivations for some packages, and then submits builds to the coordinator might suffice <efraim>wow, I didn't realize the wip-r branch was so big <bdju>is ldd packaged? I searched for it and the only result is libwhich due to its description. not sure if it'll work the same way. someone told me to use ldd for something. <simonsouth>bdju: Looks like it's part of gcc-toolchain actually. <dftxbs3e>I am wondering what's the best way to have shepherd start itself as my user when I log in? <bdju>oh looks like I already have ldd, I just used it wrong and thought I didn't have it <dftxbs3e>When I log in, or at boot, as my user, either is fine <dftxbs3e>The blog post on Shepherd user services misses just that <bdju>I start the user shepherd in my ~/.profile with a snippet I thought I got from someone else. here: http://ix.io/2Hij <dftxbs3e>bdju, does that work if you login through GDM? Or only when you fire up a terminal? <efraim>I changed mine to: if [[ ! -S ${XDG_RUNTIME_DIR-$HOME/.cache}/shepherd/socket ]]; then shepherd; fi <efraim>I stuck mine in .bash_profile, works when I log into enlightenment from sddm <bdju>I just log in from a TTY but I would think it should work either way <dftxbs3e>BTW I decided to ditch Fedora on my laptop to force myself to get used to GNU Guix, it really helps me be more productive to depend on the tools I decide to improve <dftxbs3e>Ah and.. somehow Emacs installed in my GNU Guix user profile loses theme configuration after each reboot.. it works if I quit Emacs and start it again if I don't restart though (or logout, didnt try) <maav>dftxbs3e: that's quite weird, I have a different theme for each of the emacs daemons i run, but i do it through custom.el (one for each daemon), how are you changing the theme? <dftxbs3e>I'd very much like to go with daemon mode but havent figured that out yet <dftxbs3e>maav, '(custom-enabled-themes '(spacemacs-dark)) <bdju>can someone enable debug outputs on the gtk+ and glib packages? <maav>dftxbs3e: yup, i have something like that... spacemacs is installed with guix, isn't it? <dftxbs3e>bdju, you can use --with-debug-info=PKG on any command that installs something that depends on them <bdju>dftxbs3e: oh, thanks. I'll try that <maav>dftxbs3e: i'm checking and the themes I'm using come from emacs itself, and the other ones are loaded with the site-lisp-file... perhaps is an initialization order issue? <dftxbs3e>bdju, it will have to recompile everything because "functional" packages, so.. will take a while <dftxbs3e>though once it's compiled once it will re-use :-) <bdju>dftxbs3e: maybe I did it wrong then, because it finished instantly and didn't output anything... <bdju>`guix build --with-debug-info=dino` <maav>dftxbs3e: i think the --with-debug-info grafts the package, so only the one needed (glib/gtk) will be recompiled <bdju>I already have dino:debug but some of the dependencies were missing the debug outputs I think <dftxbs3e>bdju, you need guix build --with-debug-info=dino dino <bdju>okay, that output a couple lines and took like 5 seconds instead of 0 <dftxbs3e>or if you want to have debug info on a dependency (or multiple) of dino: guix build --with-debug-info=glibc --with-debug-info=libattr dino <dftxbs3e>AIUI --with-debug-info also applies recursively to all the dependencies of the packages you specify, so if you specify dino it should do it to everything (I think?) <dftxbs3e>bdju, it was just an example, it's used to access POSIX extended attributes IIRC <civodul>dftxbs3e: glibc already has a "debug" output <dftxbs3e>maav, maybe it's initialization order issue.. I see in customize it says: "Note: Your custom settings take precedence over theme settings." <dftxbs3e>but .emacs has it, isnt that what custom settings are? <dftxbs3e>civodul, ah okay! was just giving an example <civodul>sure, the other examples make a lot of sense! <dftxbs3e>I noticed syncthing is quite out of date, trying to update it :-] <dftxbs3e>Too bad the golang importer patches don't include one :-) <maav>dftxbs3e: the custom settings are set by the form custom-set-variables, and as far as i see custom-theme-load-path should be set by spacemacs-theme-autoloads.el, could you try printing out that variable before the custom-set-variables form? <dftxbs3e>maav, how do I print it? Sorry I'm still quite a noob with ELisp <dftxbs3e>maav, just to clarify, the theme does appear in customize, if I tick it it gets set, just if I restart Emacs it doesnt say (though I remember restarting it and it did stay then rebooting the system made it go back to default) <maav>(message "%s" custom-theme-load-path) prints (/home/miguel/.guix-profile/share/emacs/site-lisp/ custom-theme-directory t) on my machine <maav>after installing spacemacs-theme to test it, because before that it only prints (custom-theme-directory t) <dftxbs3e>maav, oh.. here's messages: (/home/lle-bout/.guix-profile/share/emacs/site-lisp/ custom-theme-directory t) <dftxbs3e>Failed to enable theme(s): spacemacs-dark <dftxbs3e>didnt check them before, but it somehow fails to enable the theme <dftxbs3e>even though, if I tick it afterwards in customize, it works <maav>yup, the value seems to be there but the theme still isn't loaded... it's weird. A quick workaround would be to add a function after-init-hook to call load-theme manually <maav>probably there it should work, as it works when you use custom.el... *civodul smiles while looking at the output of "avahi-browse _guix_publish._tcp" <dftxbs3e>maav, can't get more verbose failure message? <maav>dftxbs3e: without directly debugging I guess not <jonsger>hmpf, how can I move back from a profile loaded from a manifest to my main user profile? <dftxbs3e>maav, okay! well thanks for your help! Do you get the bug too? *rekado_ works on CRAN updates now <rekado_>commit 45584061a9ebe961e2be08ee94c3fe8ad74e2713 broke the CRAN importer <maav>dftxbs3e: yes, i can reproduce it, but i'm not sure where the bug is coming from :( <zimoun>rekado_: tell me if you need help with the CRAN update <rekado_>there are some packages I will not upgrade, but we should work on them at some point <rekado_>Iâm skipping r-metap (needs mathjaxr), r-mosaic (needs leaflet), r-imp (needs keras), and r-rgl (needs mathjaxr) <rekado_>so, packaging mathjaxr (and building all JS from source) would be useful. <rekado_>mosaic needs leaflet, which depends on a whole lot of JS that we canât build yet. <rekado_>Iâve been skipping the upgrade for a while now <divoplade>Regarding ocaml and js_of_ocaml, I've sent a patch for a small dependency, that I think is the last missing... But making a package for js_of_ocaml itself is a lot harder, there are PPX problems and strict bytecode versions :( <Formbi>is there a way to disable the escape sequences in guix output? <Formbi>it's another annoying change not announced in guix pull <Formbi>since I use guix mainly from eshell, it now looks like total crap <zimoun>mothacehe: hey! rekado_ merged wip-r to master. A lot of substitutes are missing but we are both sure they build, because we did both locally. For example r-flowmeans or r-flowutils or r-quasr⊠Well, I do not understand who ci.guix.gnu.org to read the raw. Is it IO issues? <Formbi>[K[1mbuilding XDG MIME database...[0m <zimoun>rekado_: I will give a try to r-mathjaxr but I am not sure to be skilled enough with JS stuff. <mothacehe>zimoun: hey, not sure I understand your question. You mean there are builds with empty raw logs at ci.guix.gnu.org? <rekado_>zimoun: thanks! We have a couple of R packages with bundled JS code that can serve as templates. <rekado_>zimoun: itâs mostly just tedious as long as you can find the JS sources. <rekado_>Formbi: does it change if you set TERM=dumb? <Formbi>but such things should be announced <rekado_>I donât disagree with you, just providing context <Formbi>yeah, but some people don't know about such things <rekado_>so I wonder if perhaps Emacs changed when INSIDE_EMACS is set <morgansmith>I also have this issue in emacs. I think 27 works fine but anything later seems to give the same bug. we're talking about eshell right? <morgansmith>I really wish someone would fix that :P I don't understand why the colors work for like the first 100 lines and then suddenly start failing :/ <morgansmith>actually now that I'm looking at it I think the behaviour changed again recently... It used to work for the first 150ish lines of the eshell buffer but now it seems to work for the first 150ish lines of each command... <GewaltDisney>hi folks, during Guix Days there was a convo happening concerning the need for UX/UI designers to work on GuixSD, but I didn't catch any resolution concerning the next steps (admitted i was working and tuning in/out leisurely). I'm a designer that would love to work on GuixSD, is there a hub where these dialogues are happening? <rekado_>GewaltDisney: discussions happen on the guix-devel@gnu.org mailing list <civodul>yup your input would be most welcome! <rekado_>there isnât any focussed UX/UI discussion yet, so maybe you can kick off the discussion there :) <roptat>GewaltDisney, also note we say "Guix System" instead of GuixSD now ;) <zimoun>mothacehe: I am not able to find the evaluation number and so the raw to check waht is wrong. <leoprikler>fwiw there is a guix gui in development currently <leoprikler>it's also well hidden, wait, let me search for it again <morgansmith>it looks like packages->manifest accepts stuff in the form "git:send-email" or '("git" "send-email") but options->transformation will only accept the first form (and then interpret it wrong) <morgansmith>oops, the form should be '(git "send-email"). still doesn't work though <morgansmith>ok, if I remove the part where I apply the transfromations but keep everything else the same it works. So it does pass the send-email output to the transformations function and then the transformation just says nope <leoprikler>It would be a nice exercise to rewrite your transformation logic to be correctly applied to packages <morgansmith>I really don't understand how packages work :P it looks like the function should only modify the package-properties... but are the properties some kind of catch all field? <leoprikler>I think the important distinction here is between <package> and (<package> "output") <leoprikler>you need to transform the <package> while keeping the structure and "output" the same <morgansmith>but wouldn't package/inherit also inherit the output field? wait, is the output field just a list of possible outputs or is it the current output? <leoprikler>where as the current output is listed among with the package and assumed "out" by default <morgansmith>where do package definitions go to become a derivation? is derivations.scm just for nix stuff? <leoprikler>I â„ how Polari sends my clipboard to paste.gnome.org <divoplade>roptat, how do you install an ocaml package with ocamlbuild? I tried ocamlfind install, but it expects me to list the files <morgansmith>leoprikler: That works! Thanks so much! I still don't quite understand what's going on :/ <divoplade>roptat, the files that I can install are: .a, .cma, .cmi, .cmo, .cmt, .cmti, .cmx, .cmxa, .cmxs, .ml, .ml.depends, .mli, .mli.depends and .o <divoplade>My guess is .a, .cma, .cmi, .cmx, .cmxa and .cmxs <leoprikler>morgansmith: it applies the transformation to the package and delivers that + output <zimoun>divoplade: what do you mean by install an ocaml with ocamlbuild? <divoplade>zimoun, the package I'm working on has a makefile that calls ocamlbuild, but it has no install target <divoplade>So I invented mine, which is ocamlfind install <name> ... <divoplade>But it needs to be told which files to install <divoplade>And obviously, there's no point in installing some of these <zimoun>is it a standalone package or a library? <morgansmith>leoprikler: I replaced your match statement with (lambda (package output) (list (transformations package) output)) <morgansmith>I think maybe you overcomplicated it? My way works, right? <divoplade>We could install everything including the source code <divoplade>But obviously that would make very big packages for little gain <zimoun>divoplade: I do not know if there is a policy. The minimal. :-) <divoplade>Maybe there's an ocaml best practice that is taken as a guix policy. <divoplade>But I'm afraid the ocaml best practices is to install everything <rekado_>weâve got a problem with uglify-js <rekado_>it doesnât support the latest ECMAscript, so it fails on the new version of d3js <rekado_>it doesnât know âletâ, nor does it know the new â=>â shorthand for functions. <mdevos>I'm trying to install Guix System on another system. I'm aiming for encrypted root, and placing /boot within the root file system as an âordinary directoryâ. Would I need to do anything special here? <zimoun>rekado_: are you speaking about mathjaxr and JS? <zimoun>divoplade: I commented in the bug report. <mdevos>Odd, the graphical installer has generated a .config with (bootloader-configuration (target "/boot/efi") etcetera). I'll replace it with a section from the local machine, perhaps it will work as well. <mdevos>mbakke: The machine I'm running doesn't have a /boot/efi partition <mdevos>or a /boot partition for that matter <mdevos>I'll read the relevant section in the manual again <mdevos>the proposed config is for the EFI system <mdevos>or UEFI perhaps I guess, not very familiar with the terminology <mbakke>mdevos: indeed, though it won't work without an EFI "system partition" <mbakke>automatic partitioning should create one though <mdevos>the machine I'm running uses grub-bootloader, not grub-efi-bootloader <mdevos>and automatic partitioning created one, but I removed it <roptat>divoplade, maybe look at the opam file? <mdevos>I'll try guix system init and see if it installs & boots <argylelabcoat>If I'm using Guix to develop a package from scratch, is there a more sane way of development than the flow of: Make changes to source code repo. Commit, get hashes, Return to Channel Repo, update hashes in package spec, build. <mbakke>argylelabcoat: you can use 'guix hash' to get the hashes? <argylelabcoat>in fact, I wrote a short bash script to get both git and guix hashes in one go <argylelabcoat>but my issue is, I'm hopping from my source code post-commit into the channel code to paste the hashes in for building <argylelabcoat>is there a more sane way to use guix for dependency management for development than doing this? <mbakke>argylelabcoat: I tend to use (source "/path/to/my/checkout") for development <argylelabcoat>I've been considering actually having a copy of the package spec in the source itself, that has a (source "./") type reference <mbakke>argylelabcoat: you can also create a guix.scm in your repository that defines a trivial package and uses (source (git-checkout (url (dirname (current-filename))))) <argylelabcoat>but I feel like something is missing here, is there a way I can have during development, a .envrc or something similar that references a specific version of the package channel? <mbakke>then guix will build the most recent commit <mbakke>ah yes, a copy in the package spec is a common method <mbakke>but if you have a channel, you can use (source "/foo/bar") and use guix build -L . my-package from the channel directory <mbakke>lots of ways to skin this cat :) <argylelabcoat>then hop into the source and it knows what git revision of the guix package channel, and what revision of my current package channel are needed <mbakke>argylelabcoat: if everyone has the same channel, you can create a guix.scm in the repository that inherits from the channel and provides for an easy 'guix build -f guix.scm': https://paste.debian.net/1176263/ <argylelabcoat>can I, have a `guix environment` that references a specific git checkout of a channel? <mbakke>argylelabcoat: I suppose you'll have to use 'guix time-machine' with a given channels.scm file <mbakke>i.e. 'guix time-machine -C channels.scm -- environment foo' <argylelabcoat>mostly want to keep things frozen while development is occurring <argylelabcoat>don't want one team member using a slightly different package with potentially breaking changes vs rest of the team <mbakke>argylelabcoat: distributing a channels.scm file somehow is likely the best option, then you can e.g. 'guix pull -C channels.scm -p ~/dev-guix', and use '~/dev-guix/bin/guix build -f guix.scm' <mbakke>time-machine has a little overhead :) <argylelabcoat>fair enough. I'm working on a strategy for rolling guix out internally at the office... and with different teams. channels.scm looks like a good solution, but sometimes work is done on different versions of the same code, in which case having environments might be more useful, though I suppose "pull" might allow movement in any given direction <leoprikler>argylelabcoat: "At different versions": `guix time-machine` <olivuser>I am still having trouble with a rather freshly installed guix system. <olivuser>the basic commands do work, but I do have quite a bit of problems within emacs (which sucks since I use exwm as window manager) <olivuser>the problem seems to boil down to the fact that emacs does not find commands even though they are installed on the machine and found when executed from the command-line <olivuser>this relates to git, but also to ls (in the case of dired) <olivuser>does anyone know what this problem is related to? <leoprikler>olivuser: perhaps a mismatch between emacs' PATH and your shell's PATH? <olivuser>leoprikler, do I set emacs' PATH in init.el or in some other place? <leoprikler>I don't think you should manually set that anywhere, but try "echo $PATH" in your shell and (getenv "PATH") from emacs and compare them <leoprikler>if the latter is lacking stuff like $(HOME)/.guix-profile you need to startup your Emacs differently <leoprikler>repeating since you were away: I don't think you should manually set that anywhere, but try "echo $PATH" in your shell and (getenv "PATH") from emacs and compare them <leoprikler>if the latter is lacking stuff like $(HOME)/.guix-profile you need to startup your Emacs differently <olivuser>Leoprikler, thanks, will check that out. But if stuff fails, how would I start emacs differently if it now is started by gdm upon login? <leoprikler>I'll get back to you once I've figured out whether you can indeed do this from inside emacs <leoprikler>for the record, how did you configure your gdm to run emacs? <leoprikler>that much I understood, but what I'm actually wondering is how gdm calls emacs/exwm/whatever <leoprikler>sneek: later tell olivuser: if you use emacs through xinitrc and it doesn't have $GUIX_PROFILE in $PATH, try `source /etc/profile` before exec emacs <argylelabcoat>I've been building a bunch of package defs, but they definitely don't lint well yet. How important is "Software Heritage" before submitting patches? <cbaines>argylelabcoat, that's a bit of an odd lint check, I'd just ignore it <lfam>argylelabcoat: You can ignore that message. In general, the linter is things that are "nice to have" <lfam>If you re-lint in a couple days, that warning will probably disappear <leoprikler>I always thought there was some kind of CI hooks somewhere to submit packages to Software Heritage *post* upstreaming <lfam>*Something* triggers that <lfam>I don't recall where it happens <argylelabcoat>my brl-cad package still segfaults on execution, so I have to debug it some more... but it's source isn't in heritage. The packages that reference public github projects all pass I think <lfam>Right. Anyways, you can ignore it <leoprikler>github already submits repos to SWH on its own without guix having to lift a finger, that's why <mbakke>the lint check itself triggers SWH archival, but it only works with git repositories <mbakke>pango@1.42 fails on the "ungrafting" branch <olivuser>leoprikler, I dont know, I chose exwm upon system installation <sneek>Welcome back olivuser, you have 1 message! <sneek>olivuser, leoprikler says: if you use emacs through xinitrc and it doesn't have $GUIX_PROFILE in $PATH, try `source /etc/profile` before exec emacs <PotentialUser-54>Hey ! Is there a way to git-fetch from a ssh authenticated repo in a package definition ? Using the usual pattern, the builder cannot clone the repo and I get "error: cannot run ssh: No such file or directory" in the build logs. <leoprikler>could it be, that gnu/services/ssh.scm:570:31 is evaluated a bit too eagerly? <leoprikler>PotentialUser-54: no, Guix doesn't store your git+ssh secrets for you <leoprikler>you can direct it towards a local file with --with-source however <civodul>PotentialUser-54: or you can use --with-git-url=PACKAGE=ssh://... <civodul>that'll clone on the client side, using your SSH agent <civodul>or you can use the undocumented (git-checkout ...) form <PotentialUser-54>thanks --with-source works for now, even if a bit clunky .. i suppose we should set up something via vpn anyways <civodul>mbakke: re pango, did you find what happened? <civodul>also, should we start building the branch on ci? <lfam>I feel like maybe we should join the staging and ungrafting branches, since the ungrafting branch is no longer just ungrafting <jboy>I'm running weechat installed by guix on a foreign distro, and weirdly, weechat calls /usr/bin/python3 for plugins rather than the guix-installed python interpreter. Has anyone encountered this issue before? <lfam>jboy: That's not supposed to happen <mbakke>civodul: yes, let's start the branch <mbakke>I did not find out what the issue with Pango is yet .. I know it is not related to the FreeType or Fontconfig changes though. <mbakke>...which is somewhat surprising, what else could it be :) <jboy>lfam: that's what I thought. having trouble debugging the issue though. <leoprikler>jboy, perhaps python is called via just "python" instead of the full store command and "/usr/bin/" shows up first in PATH? <mbakke>ah, perhaps some of Pangos dependencies need the older freetype, instead of pango itself? <jboy>leoprikler: usually my guix-profile is first in my path, but I just thought that since I'm running weechat from systemd (--user), the path might be different... <mbakke>in any case this is only an issue because of our ancient librsvg <civodul>well let's start it, it won't be lost anyway <mbakke>I feel my time would be better spent getting Rust to work on armhf and i686, so we can switch to the new librsvg.. <civodul>though the idea of having Rust this deep in the stack kinda scares me <jboy>ah yes, setting `Environment=PATH=/home/.../.guix-profile/bin` in the systemd service file fixed the issue. <ngz>Speaking of Rust, my life has become more miserable since I tried to package rust-x86⊠<mbakke>tbf I find using an ancient and unsupported SVG rendering library scarier :-) <mbakke>and the Linux kernel is introducing Rust now as well.. <joshuaBPMan>civodul may I ask why having rust "this deep in the stack scares you?" <civodul>ngz: you seem to have entered a Rust packaging loop <mbakke>ngz: perhaps the new rust importer can make your life less miserable? :) <civodul>joshuaBPMan: on one hand it's nice to have a memory-safe language used (at long last), but OTOH Rust is big, moving fast, and lacks a good packaging story <lfam>It's like starting the free software ecosystem over from scratch <lfam>As if it were the early 90s again <lfam>I wasn't there, of course <civodul>starting over is not necessarily a bad thing *rekado_ wears a dress shirt over a t-shirt <lfam>And as many have pointed out, Rust doesn't have a good packaging story <lfam>It will leave many free software institutions behind <lfam>The communities and organizations that took decades to build will be wasted <civodul>it's also ostensibly not about user freedom, empowerment, etc. <lfam>I think Guix is in a good position to manage the transition, though <lfam>No, the values are missing, civodul <lfam>Well, hindsight is 20/20. Maybe the older groups were not effective at putting their values into practice, either *mdevos tried to install GRUB for BIOS boot onto a GPT formatted disk. <mbakke>mdevos: BIOS GRUB works with GPT, but you need to reserve some space at the start of the disk <mdevos>mbakke: the guix system init grub install error message didn't mention that <jboy-->I'm running `guix environment --ad-hoc --container -N weechat gnutls nss-certs -- weechat-headless` but the weechat instance then doesn't accept any SSL certificates. How can I make the process aware of the CA store? <procra>hi, i successfully installed guix on another HDD on my computer, i doesn't was starting until I blacklisted radeon, the thing is that now i don't have internet and i don't now if i should activate it trough unix standard(the ones in the manual) tools or the daemon manager has something special for it, there is something that you suggest? <civodul>procra: hi! if you chose "NetworkManager" for network management during the installation, and if you have GNOME or similar, you can configure network via the settings panel <procra>civodul: the thing is that i blacklisted radeon on grub in order to the system boot, so i can't login in a graphical way <mdevos>Does someone now a reasonable size for the EFI partition? There is 90 GB left unallocated on the machine I'm configuring. <civodul>procra: oh ok; you can try running "nmtui" from the console (again, if you chose NetworkManager) <civodul>mdevos: my understanding is that less than 100 MiB is enough <mdevos>civodul: ok, I'll allocate 400MiB or so <ngz>hmmm rust-tokio-0.3 has rust-tokio-test-0.3 as development input, and rust-tokio-test-0.3 has rust-tokio-0.3 as both input and development input⊠how am I supposed to deal with that? <mdevos>"guix system init" failed at the end because the bootloader configuration was incorrect. I now have correct that (I think), but guix system init is "copying to '/mnt'..." again. I presume it's mostly parts of the store that are copied (I can't imagine writing some configuration files would take minutes). Would it be possible for "guix system init" to not copy already copied things? <cbaines>ngz, cycles work differently with the rust things passed around through the arguments, the sources are what's being used, so generally you won't have cycles <ngz>cbaines: but if I commit rust-tokio-test-0.3 first, HEAD will be broken because rust-tokio-0.3 is unbound, and there's the same issue the other way. <mdevos>ngz: perhaps first define rust-tokio-testless-0.3 without tests, then let rust-tokio-0.3 depend on rust-tokio-testless-0.3? <mdevos>At least, that's what I would do for non-Rust packages *mdevos is not familiar with Rust packaging <zzappie>Hey guix! Is reply to patch coverletter automated? How long it usualy takes? <cbaines>ngz, ah, I see. I guess add the packages in one commit then <jlicht>zzappie: not too long, for me it usually responds within 10 minutes. (And most of that delay is probably on my end) <zzappie>jlicht: oh well I guess Ill send the rest tomorrow <ngz>mdevos: It makes sense, but here it is different, since I can build both. The problem is the order variables are being bound. <ngz>cbaines: OK. That sounds right. Thank you. <jlicht>the discovery feature is going to be a game changer for me (if I ever get back to the office, that is) <jlicht>so thanks to all who worked on it :) <jboy-->ah, right, I need to include `--expose=/etc/ssl/certs` in my invocation of guix environment <civodul>jlicht: i noticed that on my laptop downloading from localhost with on-the-fly compression is slower than downloading from ci (!) <civodul>we'll have to suggest good settings for 'guix publish' <jlicht>civodul: hmm, seems like a case of having folks test drive it and then coming up with some sane defaults indeed <jlicht>Is there some way to map or change the UID regarding the owner /opt/files in `guix system container --expose=/opt/files`? <jlicht>s/owner/owner of/, and the command still has a ` my-container-os.scm` argument of course ***m`wleslie` is now known as wleslie
<mbakke>hm, I really don't understand what's causing the Pango test failures on the ungrafting branch <mbakke>and there are only security fixes on that branch, so I'm wary of re-adding some of the old variants as a workaround <civodul>jlicht: i don't think there's a way to do that, no <civodul>mbakke: could it be non-deterministic? <mbakke>civodul: nope, reproduces on both my laptop and build server <mbakke>...which does appear to be indeterministic <mbakke>"someone" tried restarting the derivation there :-) <mbakke>not sure how to restart the evaluation though <civodul>there's cuirass-howto.org in maintenance.git with super tricks :-) <mbakke>reading the Pango commit log is funny ... "Fonts are amazing, and not in a good way. My system has fonts with 0, 1, 2 "Regular" faces. It also has fonts where the "Regular" face is, in fact, bold." :P <mbakke>perhaps we can start a "zero cuirass failures" effort one of these days, similar to the old Nixpkgs "ZHF" cleanup :-) <cbaines>that would be nice. My thinking has been split on two fronts, it's valuable to fix things, but it's also important to introduce less breakages <cbaines>Which is where that page which lists packages that broke between two revisions, and the patch review stuff in general comes in <kisaja[m]>will we have guix-talk.iso like parabola has <civodul>mbakke: hmm /gnu/store/zvxi3psi8prfyl4ilmh7vwrgj5dmkjss-pango-1.44.7.drv builds for me