<singpolyma>nckx: really? Is that documented? I feel like I've read the guix pack part of the manual a lot recently... <nckx>--format=deb: “This produces a Debian archive …” <nckx>Maybe you're reading an old manual? <nckx>The Note: is one such wart (which I was just wondering about). <nckx>Your link is for the latest release (1.3.0). <singpolyma>Oh. That's very unexpected since one is very unlikely to run a "release" version of guix for long <nckx>I've suggested adding a note to the top. <nckx>I'm so annoyed by this eternagotcha that I can't be bothered to deal with it. <nckx>Yes, that sounds extremely illogical put like that 😃 ***Tirifto_ is now known as Tirifto
<nckx>The (reasonable) argument is that a lot of newbies tend to install Guix with the Web manual next to them for some reason rather than the manual that came with the release, get confused that the two don't match. <podiki[m]>devel version tracks master and/or core-updates changes? <podiki[m]>seems like you'd only want the "stable" version when following the install <podiki[m]>(and I too prefer reading the web version, never got into 'info' much though always mean to) <nckx>That's fine, but it's fair to expect you to take care of making sure the versions match in that case. <nckx>It should just be made clearer which manual is which. <singpolyma>I would just have expected the main url to be the latest version <singpolyma>If it had 1.3.0 in the URL I would be less confused <podiki[m]>at least a note like "after install and running a pull, the 'stable' manual is no longer what you have" or something better <podiki[m]>(I'm always a -git -devel type person anyway, but I can see it throwing people) <singpolyma>Well, a guix user has no good reason to believe they are running a "devel" version <podiki[m]>admittedly, the version numbers in general threw me at first, as I wan't sure how that jived with a rolling release; so I was confused what guix does (and with core-updates and other branches) <podiki[m]>perhaps that ("versions" of guix) should be clarified as the root here? <nckx><If it had 1.3.0 in the URL> I was just typing up a bug report suggesting exactly that. <nckx>podiki[m]: If you're writing babby's first system configuration with which to ‘guix system init’ from the live installer following the manual's instructions, you are expected not to pull. Hence the manual should describe what is possible in the release version of Guix. That is at least the reasoning. <podiki[m]>nckx: do we have anything explaining what versions of Guix means? I don't remember seeing it. I think that would be helpful (rolling release but also versions with new features or major updates) <podiki[m]>nckx: yes, that is a good point, and great to have the manual with the install media. but seems the stable manual is limited really to that environment, or reading up before installing (when you'll be using a release version) <nckx>(By the way, the manuals do contain “This document describes GNU Guix version 7f5e881, a functional package management tool written for the GNU system.” after the ToC, which nobody wil see.) <nckx>podiki[m]: I certainly don't dispute that. <singpolyma>After I install guix the first thing I always do is run pull, since the release version is basically broken for my use cases anyway <podiki[m]>and guix will tell you to pull if it has been some days, if you do some (most?) operations with guix <singpolyma>I knew this pulled from git but hadnt really processed that running guix pull means not running a release anymore <nckx>Why would you want smelly old bits on your shiny new sys. <singpolyma>Well, the systems I run guix on are themselves Debian stable. I don't mind old usually :) <nckx>The manual contains half a thousand mentions of the word ‘version’ and I didn't check them all, but I didn't find an explanation of ‘Guix releases’. You're just expected to absorb it through osmosis. <oriansj>well writing from the perspective of people who are unfamiliar with your project is an incredibly rare skill. So Guix documentation comes from the perspective of people who are familiar with it all and thus skip the bits which trip people up. <podiki[m]>hmm something for Introduction or Getting Started perhaps <podiki[m]>yes, us newer users are important with our annoying questions ;) <nckx>oriansj: Agreed! Doing it well, at least, in a way that doesn't read like a weird blog. <podiki[m]>thanks for creating an issue nckx, I'll chime in there later too <nckx>‘Guix is a package management like Debian.’ <podiki[m]>(since I see a brief description of "versions of Guix" to be related for a beginner learning what Guix is) <podiki[m]>I'll volunteer to help write anything too, if needed <oriansj>podiki[m]: start with the questions you don't know the answer to and what you needed to learn to effectively find those answers. <podiki[m]>often the answer was to ask nicely here :) and then answer the same questions for newer newbies. but yes, we can head that off with the manual more <oriansj>especially with labels/tags that match what people looking for might look for first. <sneek>Welcome back jab9, you have 4 messages! <sneek>jab9, raghavgururajan says: Could you share your ~/.config/sway/config file? <sneek>jab9, nckx says: rspamd does a lot more than ‘just’ filter spam: it can send DMARC aggregate reports (which allegedly helps tiny personal mail servers maintain a reputation at the megaproviders', although I haven't verified that), greylisting, RBLs, and doesn't require an external DKIM filter. The others don't do all of that, although Spamassassin does more than Bogofilter. rspamd is probably heavier-weight, though (I run a Redis service <sneek>jab9, nckx says: n't comment on the effectiveness of the spam content filters themselves; that would need a proper benchmark. <sneek>jab9, nckx says: Note that ‘heavy-weight’ doesn't mean slow, in fact rspamd seems faster than others. <podiki[m]>perhaps a cookbook beginner's guide, or add to the "getting started" section. though generally I do find the manual pretty good, I just started quickly doing things that needed more <jab9>raghavgururajan I will share with you my sway/config file...busy at the moment... <nckx>podiki[m], singpolyma: Thanks for taking your turn to hammer on one of the perennial weak points. It's only ‘annoying’ in that our heards are so tired, and the sand is so soft & comfy. *nckx eyes the inviting hole anon. <podiki[m]>well I'm all in on guix, really enjoy it and the community is both helpful, but at a size where you can contribute easily <Jeremy[m]>the tech is also state-of-the-art, I don't think there's anything else out there that compares <MeowcatWoofWoofF>I don't really understand how to install from source using guix, as opposed to running autoconf/automake manually. <Jeremy[m]>MeowcatWoofWoofF: you create a package description right? <Jeremy[m]>write a package description, let's say `example-package.scm`, and then run `guix package -f example-package.scm` <nckx>MeowcatWoofWoofF: Well, guix isn't built to build/install unpackaged software from the command line, if that's what you're trying to do. No ‘guix try-to-build-and-install-what's-in-this-directory’ command. It's designed around writing package descriptions (build recipes), then building those in an isolated environment and installing them into the store. <nckx>(And it sounds like that's what you're trying to do; apologies if I'm off base.) <singpolyma>A try-build-install-. script would be totally possible in some cases though <MeowcatWoofWoofF>lol, I just want to use the official Mullvad client on my fresh install. <pkill9>MeowcatWoofWoofF: you can still run autoconf/make etc manually <sneek>pkill9, you have 2 messages! <sneek>pkill9, maximed_ says: While SELinux configurations usually label binaries specially, SELinux can do without labelling binaries, if the programs manually switch context (I don't remember the necessary commands though). (IIUC, I haven't ever actually tried this) <sneek>pkill9, maximed_ says: E.g. with 'runcon' <MeowcatWoofWoofF>How do we use stuff like "gem update" on Guix System? Is it okay to give ourselves write permissions to stuff like '/lib/ruby/gems' under the GNU store? ***jonsger1 is now known as jonsger
<apteryx>hmm, we don't have this yet in our wrap-program: set var to X, but if the allow the environment to completely override it <apteryx>that's useful if X is to accept a single value, not multiple <nckx>(wrap-program … `("X" ?= (,blah))) …? <nckx>Makes sense if there's a use case. <apteryx>my use case is GDK_PIXBUF_MODULE_FILE <apteryx>if won't allow multiple variables, I think, and the profile value is more worthy than the one computed at its build time <nckx>Why wrap a backup though? <apteryx>it's just sugar, to allow running the software directly from the store <apteryx>(it's for the glib-or-gtk build system, which already wraps the binaries with all that is needed) <nckx>Makes it harder to reason about its behaviour, but it's similar to the if (getenv("XDG_FOO")) … else "~/.local" stuff many ‘apps’ already do in code. <apteryx>perhaps I'll punt on that sugar for now <nckx>It's just an icky boundary in general. <nckx>I'm not against it per se, I just don't know what to think ☺ <apteryx>it's fine, you gave me an excuse to be down scope my change ;-) <nckx>I was just curious, so thanks for sharing the use case. <apteryx>MeowcatWoofWoofF: it's not OK to write to /gnu/store for any reason <apteryx>can't you install the gems as your user ? pip for example has a --user mode <apteryx>or better yet, package it for Guix :-) ***califax- is now known as califax
<MeowcatWoofWoofF>'gem update --user' worked. Can I do that with any program featuring its own package management? <MeowcatWoofWoofF>(Still trying to set up VPN after successfully installing the Guix System) <apteryx>MeowcatWoofWoofF: it's up to them, but it's a common pattern <apteryx>just remember that if you even have some weird problems with your Guix packages, they may have to do with the out-of-band dependencies you manually installed with external tools <MeowcatWoofWoofF>'gem install bro --user' also worked, but the bin directory for Ruby isn't included in PATH by default. That can always be appended, at least. <apteryx>arg. the issue runs deeper than staging <apteryx>inskscape doesn't use the glib-or-gtk build system and is used in builds not using glib-or-gtk either <apteryx>so setting GDK_PIXBUF_MODULE_FILE in glib-or-gtk doesn't help for these. ***jeremy is now known as jeremyc
<jeremyc>I am brand new to Guix (not Linux). I have installed Guix a few times but can not seem to get it to even register as a drive that is bootable. I am on a modern computer (11th gen Intel) and UEFI enabled. My standard Linux distro is debian. Any thoughts? I just got done installing 1.3.0 from bootable USB onto a M2 SSD, the only one in my system. <jeremyc>Reboot, computer doesn't recognize any drive as bootable. <apteryx>I've heard that the installer could sometimes get confused by existing partitions <apteryx>but if you managed to install without error, it's probably not that bug <jeremyc>OK, it said success at the end and to reboot. <apteryx>OK. There are images built tracking current master on ci.guix.gnu.org, perhaps you could try these <jeremyc>apteryx, ok, thanks, I'll head over there and see what I find. <podiki[m]>this (installer issues) come up enough perhaps we should have a link to a current from master installation image? (do we want to prefer that or 1.3.0 in instructions?) <podiki[m]>or at least for troubleshooting to try a more recent image easily <raghavgururajan>sneek, later tell jab9: Np! You can share when you are available. :) <jab>sneek: raghavgururajan thanks for having me share that. My sway config was currently NOT under version control... <sneek>Sneeky bot running on Guile version 3.0.3 using bobot++ release.2.3.1-6-a463-dirty ***matijja` is now known as matijja
<brendyn>im a bit confused about how to use channels from a manifest when using a guix checkout instead of a pulled guix. <efraim>brendyn: `./pre-inst-env guix package -L /path/to/channel -A foo' <brendyn>efraim, an i install from a manifest using this? <efraim>brendyn: sorry, I'm bad about checking back with IRC and I don't hear the bing since I don't have speakers <efraim>`./pre-inst-env guix package -L /path/to/channel -m /path/to/manifest' <efraim>why is cmake and cmake-bootstrap at different versions? <nckx>Good morning Guix in general and excalamus, efraim, brendyn, and civodul (phew) in particular. <ss2>what would be the best way to debug a service? It fails, and I don't find meaningful error messages for it. <ruffni>ss2: are there (more meaningful) error messages in the program being started by the service? <ss2>No, none that I can find. The only errors are that the service fails in messages. Changes are that the declaration isn't correct. <ss2>But I loaded it into an REPL, and there's an error thrown, so that might help. <nckx>gierdo[m]> I'm running guix on top of debian/ubuntu, mainly for managing an environment as consistent and manageable (as code) as possible between various work/personal machines. <nckx>gierdo[m]> The ubuntu base (work machines) is a requirement, the debian base is a nice to have for a few things, so going full-on guixsd is not really an option. <nckx>gierdo[m]> I run sway where possible with i3 as fallback. Now to the challenge: <nckx>gierdo[m]> If swaylock/waylock/i3lock are installed in the user profile, they don't work due to suid (access to /etc/shaddow) only being possible in the system scope. I haven't found other solutions than building/installing the screen locker outside of guix. <nckx>gierdo[m]> Does anybody of you have a similar problem + solution? Is it possible/recommended to run "guix system" if not running guixsd? <nckx>So, first off: it is definitely not recommended to run ‘guix system’ if you're not running Guix System (we got dropped the ‘GuixSD’ name years ago). It will turn your Debian system into a Guix System, basically, and you certainly don't want that. <nckx>Store files can't be setuid and I don't know if there's an accepted method to install setuid programmes through Guix on foreign distributions. Guix System just makes a copy and chmods that; you *could* write a hacky script that does the same and puts them somewhere first in $PATH… <nckx>I doubt there's something built in. <ruffni>just to get this straight: `guix pull` fetches the latest commits from channels and (if no substitutes found) /builds/ the most recent version of `guix`? is it possible to cross-compile this process? <gierdo[m]>I was afraid of that.. Not that big of an issue. <nckx>gierdo[m]: A script like that would be relatively simple to write (for each in set uid pro gramme; do cp $HOME/.guix-profile/[s]bin/$each $HOME/.local/bin; chmod $HOME/.local/bin/$each; done) but make sure you don't make hard links to save space. Guix used to do that and it was a security hole 😉 http://issues.guix.gnu.org/28751 <nckx>gierdo[m]: No apologies necessary, it's just astounding how such an ancient name refuses to die. <nckx>One which we generally agreed, when the change to ‘Guix System’ happened, was clunky and opaque ☺ <nckx>It felt like longer ago, but still, years. <nckx>excalamus: I must be missing some subtlety because both sound the same to me. <nckx>In retrospect an announcement might've been needed even though we apparently didn't think so at the time. Perhaps we underestimated how well-known GuixSD was by then? Who knows. <excalamus>nckx, I was trying to avoid my first expression being interpreted as sarcasm <efraim>nckx: IIRC you can't delete openssh's /var/empty, it makes the openssh service fail to start <nckx>excalamus: Oh, no problem, but I can see how the second is safer in that regard. <nckx>efraim: I'll add a comment then. <mfg>So the library itself is missing from guix environment julia --ad-hoc julia, so that's the reason why it cannot be found <efraim>ba912479e8481d69b699ce348b35d5d70f0c9367 <nckx>Point taken, I should've added a comment then… <jbv1[m]>@mfg yes there is a problem with the current llvm-julia it does not create libLLVM-11jl.so I have to send a patch <mfg>jbv1[m]: ah i see, thanks for working on it :-) <jbv1[m]>out of curiosity do you often use julia on guix ? I plan to propose a patch for julia build system to make guix more inter operable with julia package manager and would be interested to hear opinions on the topic <civodul>so, gforge.inria.fr finally went down <civodul>but the irony of it is that despite all our work, we've already lost upstream tarballs <civodul>like "guix build -S scotch --no-substitutes" won't work <civodul>dstolfa: i've been told about the one of "scotch", i haven't checked others yet <mfg>jbv1[m]: in fact this is the first time i have used julia. <jpoiret>i'm trying out core-updates-frozen and `light` isn't building with "ld: light-light.o:/tmp/guix-build-light-1.2.2.drv-0/source/src/helpers.h:24: multiple definition of `light_loglevel'; light-main.o:/tmp/guix-build-light-1.2.2.drv-0/source/src/helpers.h:24: first defined here" <mothacehe>nckx: hey! do you think you could create me an account on the guixp9 machine please :)? <sneek>mothacehe, you have 1 message! <sneek>mothacehe, raghavgururajan says: Just saw your gnome40 branch. Glad! :) Let me know if you need anything. <mothacehe>raghavgururajan: I merged the wip-gnome40 branch in the core-updates-frozen branch! Thanks for your work on the wip-gnome branch! <nckx>OK. PM me your private SSH key and I'll get to it in a jiff. <nckx>I mean, it was worth a try. <nckx>Please, everyone PM me your private keys, thanks! ***tricon_ is now known as tricon
<jbv1[m]>efraim: yes gr !! I'd be very happy to have it on guix !! <cehteh>hmm would it be totally unreasonable to ask for 'guix system reconfigure' without an FILE argument, using the current system description from the store? <cehteh>and 'guix system reconfigure --edit' fetches that, starts an editor, saves a tempfile, reconfigures the system .. basically aiming to deprecate the /etc/config.scm on users descision <civodul>oh, and kudos raghavgururajan & mothacehe for GNOME 40! <nckx>mothacehe: You should be able to log in! Let me know. Change you password just in case. <mothacehe>hey civodul! thanks, back from holidays (even though I didn't fully disconnect :p) <mothacehe>the core-updates-frozen now even has GNOME 40 + Wayland support thanks to Josselin <jpoiret>what's the policy on patches for core-updates-frozen? light doesn't build at all on it, just need to pass -fcommon to gcc to fix it <mothacehe>nckx: I still have: mathieu@10.0.0.7: Permission denied (publickey) :( <mothacehe>jpoiret: build fixing patches are welcomed on the core-updates-frozen branch <jpoiret>alright, expect one in the next hour then <jpoiret>by the way, about wayland becoming default for gdm, what do you think would be the best way to achieve that? set the flag to be the default in gdm-configuration or change the desktop.tmpl file instead? <jpoiret>since it can be a breaking change for nvidia users *nckx types some more hateful stateful things… and now? <nckx>Great! Somebody should port Guix to this architecture so we can get rid of Debian. <mothacehe>jpoiret: maybe we could start by a change in the desktop.tmpl file until we get some feedback from Nvidia users? <mothacehe>nckx: could you also initialize my password :)? <jpoiret>right, this seems like a good starting point. is there also a mechanism to warn users that use default values for some records that they are going to be changing soon? <jpoiret>just like the warning i've been getting about targets vs target <nckx>mothacehe: I sent it in a mail. <nckx>Hm, it's still spinning in mu4e. Which has become terribly slow, again, as of late. <mothacehe>He, my Gnus setup is also terribly slow these days <mothacehe>jpoiret: we could use "warn-about-deprecation" when wayland? is #false, but every GDM use would get a warning <nckx>Re-initing the database ‘fixes’ it, but sheesh. <nckx>I think the mail has left the building. <nckx>the_tubular: ‘All tests should pass’ 😛 The Guix package in Guix doesn't mean much, although one of the previous updates did add XFS support, which was probably good news for both people interested in Guix on XFS. <nckx>But -8 is just to got a fix to the lint test into the package proper. <nckx>Well, for ‘guix pull’ users, Guix pulls (heh) directly from master, so there are no separate ‘updates’: each commit to the master branch is an update immediately available to users. <jpoiret>guix "the program" itself contains all packages definitions, when you guix pull you don't just update a package list (like in arch for example), but you update the whole guix program <jpoiret>guix-home is just a new feature of guix itself <nckx>The package guix is only relevant for Guix's own test suites, and initial deployments where it's the ‘bootstrap guix’, but you're expected to use it only to immediately ‘guix pull’ to master. <mothacehe>nckx: sorry to bother you again, I could change my password but I'm not part of the sudoers group <nckx>‘You have new mail in /var/mail/debian’ 😃 <nckx>The incident has been reported! <nckx>I'd never actually seen that happen. Anyway, you're added now. I can't find my checklist which has these steps on it <mothacehe>nice, I should be able to debug this cuirass-remote-worker thing now :) <mothacehe>23412 powerpc64le-linux builds pending, the guixp9 should be quite busy. <ss2>sorry that I have to ask again, I've been extending my practice service module, but it is somewhat just not really functioning anymore. Paste: http://ix.io/3AOx <nckx>Rebuilding OpenSSH on only 2 of the 8 cores? Yes. <ss2>And then I load it into my system declaration, and add the service type. Has it mayb got to do with the way I put it into my declaration? <ss2>This service type I've now more or less copied in style that was laid out in radicale-service-type. I suspect that maybe the way I'm loading it is just not right anymore. <ss2>And I've got no idea how to debug this yet. :/ <jpoiret>ss2: what do you mean by "Not functionning anymore"? is the shepherd service not starting? <ss2>lemme fetch the error.. <ss2>Sometimes it passes, but then the service unit fails, and I'm lost.. <ss2>allright, I disabled all reverences to activation-service-type. Now at least reconfigure passes, but the service is dead. <ss2>I'd really like to find out why this happens. <ss2>okay, there is something in the logs. <jpoiret>mpd looks like it needs some mandatory configuration, but your mpd.conf file is empty <ss2>I does initiate a daemon, although it can't do anything anymore. <ss2>I'm not planing to extend it, since there's a service declaration anyway. <ss2>and I just figured that placing #log-file: "/var/log/programme.log" with put most of the errors into that file shepherd is trying to spawn. Which is a great help. <ss2>I just spend half an afternoon without knowing that. ^^ <michzappa>I think I've found a bug in the crate importer when a package has a version of 0.0.0. Has anyone heard of that before? Might email guix-devel later or do a more in-depth trawl through the issue tracker <MeowcatWoofWoofF>Is there any use case for using 'sudo guix install'? I was thinking root might be able to utilize some things, if given their own guix profile. <michzappa>if you want to have packages in root's guix profile but not your other users then that is a use case, as for why someone would want that I am not bsturmfels <nckx>IIRC you're on a foreign distribution (which might default to -i already), but make sure to use ‘sudo -i’ just in case. <nckx>Was bst*** a typo or does matrix.org enforce absolutely no nick consistency across the bridge? <MeowcatWoofWoofF>Instead of stuff like 'guix install ruby' I need to use 'guix install ruby:bin' <nckx>MeowcatWoofWoofF: It spawns a ‘log-in shell’ which is… an esoteric concept, but it boils down to whether the elevated programme sees root's environment (as if you'd logged in as root, or run ‘sudo su -’), or still sees your user environment whilst running with elevated privileges. The former is what you want, since you want guix to operate on /root/.guix-profile; you do NOT want guix writing ~/.guix-profile but making it root-owned, because <nckx>that will cause problems later. <civodul>mothacehe: hey! i just noticed that one can restart a previous evaluation but cannot trigger a new one <civodul>like when you don't want to wait until it's time for the next one <mothacehe> civodul: we could definitely add something like that but I fear it won't be trivial given how things are wired. <civodul>re triggering, it's just that i had set a 2h period for the "source" jobset and now i'm eager to see whether my fix actually fixes it :-) <civodul>mothacehe: BTW, we've had issues on berlin where some Cuirass logs show "cannot build foo.drv which is missing", suggesting that .drv's resulting from evaluation are not protected from GC <michzappa>nckx: that was a typo, company-mode got in my way <mothacehe>the "cannot build foo.drv" in Cuirass are not caused by gc'ed things but by the publish server sending 504 errors <civodul>i saw you mention that bug, but i thought it was not related <mothacehe>yup, i'll try to resume my investigations on that topic now that I have a consistent access to my computer :) <civodul>i think berlin is running 'guix publish' before e53d8a84c6fbf7641e7d0e6e8658da0bb01fcd71 <mothacehe>I'd like to find a nice metric to monitor I/O pressure too ***GNUtoo_ is now known as GNUtoo
<Gooberpatrol66>what all monitoring programs (something like nagios) does guix have services for? <roptat>there seems to be four of them, hopefully you can find one that's good for you :) <iskarian>a lot has happened while I've been busy with other things! <iskarian>guix home is in master now, it seems; I'll have to try that out sometime <nckx>That wasn't supposed to happen just yet, but here it is ☺ <iskarian>Maybe I'll wait for the inevitable bug fixes to land first :) <nckx>Python people! Is there an environment variable I can set so AssertionErrors don't truncate the middle of long strings? E.g. "blah blah … blah blah" — the bug is obviously hiding in the …. <nckx>Please say yes because monkey-patching Python is torture to me. <jeremy>I am doing a manual installation and the font is very small. Can I change the console font some how? <jeremy>nm, asked it after searching and failing, then of course found the answer. setfont FullGreek-Terminus32x16.psf.gz is fine. <nckx>Glad :-) It's a valid question and it's something that could probably be automated. <tekakutli>alo, is anyone free and willing to help me see whats wrong with my package attempt? <drakonis>well, post the definition on pastebin or debian paste <tekakutli>btw what happenes with (build-system gnu-build-system) if the makefile only has make install <iskarian>you need to delete the configure phase, check the source for "delete 'configure" for examples <maximed>tekakutli: The Makefile won't work, as it tries to install things in ~/.local/share, and $HOME is not set to anything useful in the build environment <maximed>I don't know where krita looks for brushes <iskarian>is that where the guix krita package looks? <maximed>if it looks in XDG_DATA_DIRS, maybe replacing ~/.local/share with /gnu/store/[...]-rakurri-brush-set-for-krita-[...]/[something] works <tekakutli>well im actually in arch, and yea it uses the same .local/share/krita than non-guix krita <maximed>tekakutli: Possibly it looks in .local/share/krita, but also in $XDG_DATA_DIRS <maximed>If it's only in the former, some patches to krita might be necessary such that it can find brushes installed with "guix install rakurri-brush-set-for-krita" <maximed>License information seems to be missing in the source code of rakurri-brush-set-for-krita <maximed>jgart: ‘guix pack --format =docker’ <-- a space too much? <maximed>jgart: There's another one: "guix pack --format =deb" <jgart>If there are any other things just let me know here <radvendii>is there a way to use a local directory as a channel in guix? <radvendii>I want to modify something in guix and test it out <maximed>"guix build -L/some/directory/with-modules stuff" <maximed>"guix install -L/some/directory/with-modules stuff" <maximed>radvendii: What do you mean with ‘replace’? <radvendii>like i want to modify some of the existing guix infrastructure <maximed>radvendii: Like modifying an existing procedure in Guix? <maximed>E.g., changing how modify-phases works <maximed>radvendii: Usually one would clone the git repository of guix, make modifications, and build it <radvendii>oh and then use the `guix` executable from that <maximed>"git clone ...", "guix environment guix", ./bootstrap, ./configure --localstatedir=[something], make modifications, make, ./pre-inst-env guix do-stuff-with-modified-guix <maximed>There's a section in the manual about hacking on guix <radvendii>hmmm... if i just want a simple build, i would have expected `guix build -f guix/guix.scm` to work <jgart>radvendii, you can put a package in a file and build it outside of a source tree <maximed>If guix/guix.scm ends with a package, that should work <jgart>and then you can later integrate it into a tree <maximed>But it won't automagically use your modified build system <radvendii>jgart: what do you mean? i'm not trying to rebuild a package, but a build system <jgart>for when you don't want to think about it <jgart>You can still put build systems outside of a tree <maximed>radvendii: Another possibility is copying the definition of the build system from guix into the file holding the package definition of the package you're testing <jgart>I think yoctocell has one for gerbil IIRC <radvendii>there's a bunch of interdependent stuff though. i'm not sure exactly what i'd have to copy out <maximed>radvendii: It depends on what you're modifying <maximed>If you want to add more implicit inputs or something, copying the code from guix/build-system/SOMETHING.scm should be enough <radvendii>like there's `guix/build-system/go.scm` which references `guix/build/go-build-system.scm` <maximed>radvendii: maybe replace %standard-phases with (modify-phases %standard-phases (replace 'stuff ... )...)? <maximed>And later do it ‘properly’ in the source tree of guix? <maximed>But you might need to rename it, I dunno <maximed>If you'll copy it, make sure to adjust the file name in you modified go.scm as well ***jeremy is now known as jeremyc
<radvendii>hmmm i'm a little confused about scoping. if i have a function i want to replace a phase with, and i do `(replace 'phase my-phase)`, it complains about undefined identifier (even though i've defined it in that file) <radvendii>my understanding is this is because it's being quoted, and passed off to another file where that function is not defined <radvendii>if i do `(replace 'phase ,my-phase)`, it complains about "Unknown # object", and the same complaint if i use `',my-phase` <radvendii>is it just not possible to define it in a separate function? do i have to do it inline? <nckx>It expects a quoted sexp (data), not a procedure object (opaque callable thing which can't be carried over the host -> build environment barrier). <radvendii>and sexps don't take their context with them <radvendii>so it's like a dynamic scoping kind of thing <nckx>Right. Not yet, at least. <nckx>awb99_: You can ignore that. <awb99_>I tried to search a manual what I can do. <awb99_>but couldnt find the meanings... <nckx>“Use the given verbosity LEVEL, an integer. Choosing 0 means that <nckx> no output is produced, 1 is for quiet output; 2 is similar to 1 but <nckx> it additionally displays download URLs; 3 shows all the build log <nckx> output on standard error.” <nckx>Info: (guix)Common Build Options <awb99_>wow! you know it all nckx! faster than the speed of light :-) thank you! <nckx>Uh… I… OK ☺ You're welcome. <awb99_>I got a question on custom channels. I look at them as a source code repositioy that has shared code. So essentially I could put in there custom configurations, and helper libraries. And of course package definitions. <awb99_>But now my question is, if a custom channel would also be a good place to put in config files, say bash_rc files, <awb99_>I did define a few packages that are not in guix. <awb99_>And I added in install, install-lists, of packages I use. <awb99_>And in config I put configurations for services that I will use in os + machine configs. <civodul>the patch can modify anything that's in the original source <awb99_>I have a problem updating a guix server via ssh deploy. I have created a new root image that I have started the server with. Now I want to send an updated config via guix deploy, <awb99_>it all worked nicely, it has been building local packages to be sent to the server. <awb99_>In the end I got an error: unauthorized public key <awb99_>It is somehow weird, since I can connect with my private key to the server via ssh. <awb99_>Is there a second key for ssh deployment? <sneek>Welcome back attila_lendvai, you have 1 message! <sneek>attila_lendvai, iskarian says: I'm sitting on a patch for that at the moment, I've just been busy :) <attila_lendvai>iskarian, ouch. i wonder what "that" meanas here, and how much we have stepped on each other's feet... <attila_lendvai>iskarian, with this i can import the closure of go-ethereum, except one dependency (cloud.google.com/go/bigtable@v1.2.0) <iskarian>attila_lendvai, looking at your commits... let's see... the github forks will work if you manually go the pkg.go.dev url and click the button *attila_lendvai has also sent an email meanwhile <radvendii>ah. so it's still going to have that dynamic scoping problem <attila_lendvai>radvendii, IIUC that's a syntax for looking up symbols at compile-time from packages you haven't imported, or @@ for private symbols <attila_lendvai>iskarian, oh, nice! i didn't know i can force that site to cache/parse projects. lemme see the log where it has failed... <iskarian>attila_lendvai, I'm not sure why vcs->origin even checks iv VERSION starts with v; it should never. *attila_lendvai notices the go importer mails on the list <iskarian>attila_lendvai, it took a minute to wrap my head around your changes because I didn't even consider modifying go-version->git-ref since no packages use it for tagged versions :) perhaps they should eventually, rather than `(string-append "v" ...)'? I'm not sure. <attila_lendvai>iskarian, i didn't really understand the problem domain here. i just took the easy way out of the hole i found myself in with those prefixed git tags. <iskarian>the 'begin' at build-system/go.scm:75 is unnecessary; the third+ arguments of 'if' are essentially wrapped in 'begin' by it <iskarian>I wouldn't bother with detecting a "/" at the end of ref-prefix, just decide whether the ref-prefix should contain it or not and assume that <iskarian>(and of course describe how ref-prefix is used in the docstring) <attila_lendvai>iskarian, yeah, that'd probably be cleaner. not sure what's the semantics of go-version->git-ref anyway. maybe it should be renamed to something less definit, like extract-foo-bar. <iskarian>as far as the "Fix the interpretation of the replace directive" commit, I'm not going to read into that rn, but perhaps take a look at my last message in #49602 <iskarian>(we should also use the parser's support for recognizing comments to use "// indirect" requires and blocks only for "upgrading" the minimum version of packages, but not actually include them in inputs) <iskarian>(especially important since all dependencies for the main package/tests are required to be in the go.mod as of go1.17) <attila_lendvai>iskarian, will do. FYI, the anomaly that lead me to look there was that go-ethereum's go.sum did not contain a dependency that the importer was struggling with. but i'm not well versed in any of this... i just want to do reproducible builds of go-ethereum. <attila_lendvai>iskarian, great work with that parser, BTW! looks very elegant compared to the problem at hand. <iskarian>thanks! I can relate, haha, I was just trying to import aerc :) and somehow got into all this <attila_lendvai>iskarian, i'm completely fine if you butcher my commits, take whatever is useful, merge with yours, and push the results. you seem to know more about this than i do. <iskarian>oh, the contents of that paste was all I had, and I don't even have commit access! <attila_lendvai>iskarian, i'm still wondering why we don't just leave all this complexity to the upstream tooling... especially if golang prefers to link stuff statically. <attila_lendvai>iskarian, hrm, shall i then look into incorporating your suggestions into my patches tomorrow? will you have time to deal with this? <attila_lendvai>iskarian, AFAIU nix lets the golang tooling fetch all the sources, calculate the hash, and capture it in the packaging (what they call vendoring). i don't think the guix way of packaging every dependency separately brings any extra reliability on top of that. <attila_lendvai>...and it brings a disproportionate amount of complexity. especially if we want reproducible builds. <iskarian>I don't think that's a goal of guix. we want builds to be reproducible with other guix builds, but not necessarily <iskarian>regarding packaging each dependency separately, I don't think it's for reliability but rather vetting each dependency so no malware slips in <iskarian>not sure that packaging each dependency separately is necessarily the way to go, but the problem still needs to be solved. with nix's method, it's too easily for dependency changes to slip things in <attila_lendvai>i think it's very much desirable with go-ethereum, and in general in the crypto space. these software are dealing with wallets holding millions of dollars worth of crypto... making a mistake in the go importer, and building it with a wrong version of a dependency that has a bug unfixed, may result in enormous losses. and it's not even hostile actors here... <attila_lendvai>iskarian, but do we seriously think that the guix project will put comparable efforts into auditing e.g. the go-ethereum codebase and build infrastrucutre than the upstream itself? <iskarian>isn't it additive, rather than either-or? If we're using --pin-versions? <attila_lendvai>iskarian, golang's algo to pick of the actual sources based on the go.mod requirements is not trivial. aren't we reimplementing that in the importer? or 2) is our strategy to just grab anything mentioned, put it all there, and then let the golang tooling run this algo at build time? <iskarian>since we use GOPATH to build, golang doesn't know anything about versions at build-time <attila_lendvai>iskarian, then a misbehavior in the go importer can lead to compiling with the wrong versions, right? <attila_lendvai>e.g. if your geth client is staking, and it's running with a bug compared to the rest of the network, e.g. due to getting compiled with the wrong version of one of its dependencies, then such a bug directly turns into real losses. <iskarian>you could always install Go and clone and build :) <attila_lendvai>iskarian, that's not my point. my point is that guix tries to act as an extra pair of eyes wrt worms, but may end up mis-compiling the package and causing losses for people who just guix package -i go-ethereum <attila_lendvai>FTR, i have tried running the official geth binary, and it seemed to work when run this way: ~/.guix-profile/lib/ld-linux-x86-64.so.2 geth <attila_lendvai>hrm, maybe i'll just create a package that grabs the official binary and wraps it... <attila_lendvai>iskarian, would it be easy to change the build process so that guix puts all the dependencies it thinks into a directory, and then golang's compiler picks up whatever it choses based on the go.mod files and its algorithm? that would be somewhat safer, because a mistaken guix packaging would only lead to build errors due to missing dependencies. <attila_lendvai>iskarian, re replace directive: reading the golang spec didn't make sense to me either. these directives are only useful if the ones in the toplevel project apply to every dependency in the transitive closure.