IRC channel logs
2025-06-02.log
back to list of logs
<mra>I think (hope?) I've resolved 41602 with pr #127. i'll have to make a pr for 55321, since afaik that was waiting on a fix for 41602 <mra>hopefully this is finally resolved. finally being able to actually use guix would be nice lol <jackhill>hmmm, my guix is still tyring to pull from savannah. I don't have a ~/.config/guix/channels.scm. Where else should I be looking? <bracket>Curious if anyone has managed to package a generic npm package with guix? <bracket>I mean like an arbitrary package. I am trying to get the @11ty/eleventy package working through guix, but have been having very tough luck so far <ieure>There are various packages, see ex `guix search ^node-' <ieure>The JS ecosystem is challenging to make proper Guix packages for due to the dependency footprint and version pinning. <bracket>I've looked though there and tried to replicate, but my packages keep wanting to pull/use the devDependencies for everything, which balloons the package count to over 100,000 for a single parent package <podiki>oh maybe it is ipv6 for berlin cuirass that keeps gateway timing out for me...seems i have more success via ipv4 <apteryx>lilyp: I guess I'll revert the using godef from emacs-go-mode; it seems useless. I fixed a crash in one of its library, and now all I can get is: godef: Offset -1 was not a valid identifier <apteryx>even after updating go-golang-org-x-tools, which seemed like it could be related <apteryx>long story short: use gopls language server if yo want code navigation with emacs-go-mode <ebrasca>My search-patches gives me guix install: error: test.patch: patch not found <jakef>if a package has an input (origin (inherit (package-source PKG))), would the origin be sensitive to transformations of PKG? <xelxebar>csantosb: IIRC, it's in gnu/system/install.scm <csantosb>xelxebar: installation-os, I see, thanks <apteryx>it's gnu/system/examples/vm-image.tmpl <jakef>if package A needs the checkout of package B, should we include package B as a (native) input or just a checkout of it as an origin? the downside is package B won't be a transformable input <evilsetg>With the migration of the project to codeberg, are there any plans to migrate the issues from debbugs there? <andreas-e>No, the issues should be handled in debbugs. This will require quite some work, help is welcome! <xelxebar>jakef: If it really doesn't make sense for B to be an independent package; if it's really just adjunct source that's separate for some reason, then I would think origin make sense. <jakef>xelxebar: in this case, A is a plugin for B. so it uses some of B's source code. <xelxebar>I've encountered similar situtions in the past and ended up always trying to make them separate packages, though. <jakef>it just feels a bit suboptimal having the builds artifacts as inputs when you only want the source code <xelxebar>That's sort of the default for Guix, though. We mostly don't ship dev variants like you see on Debian et al. <xelxebar>evilsetg: Are you on the mailing list? The proposal document went around, with lots of details. That was one of the points explicitly debated, apparently. <sneek>civodul, you have 3 messages! <sneek>civodul, podiki says: does the codeberg->savannah mirroring handle force pushes to branches? namely for mesa-updates which i did on codeberg (updates and rebase) <sneek>civodul, podiki says: I ended up changing the git url in cuirass via the web interface for mesa-updates, so it can start building i hope <evilsetg>xelxebar: Thanks, I totally forgot to look in the mailing list. Will check the discussion out. <mra>oh, civodul, you may want to have a look at PR #127. I know that you were involved in the discussion on issue 41602, which this PR means to resolve <civodul>mra: just had a quick look, thanks for the heads-up! <civodul>hmm what’s the btrfs-balance process? <civodul>seems to be quite CPU-hungry on berlin <identity>civodul: running btrfs-balance(8) is quite CPU and IO intensive indeed <identity>civodul: not normally, i think, but there may be a timer for it <ebrasca>I am getting "File CMakeLists.txt is read-only; trying to patch anyway" can you make files writable? <ebrasca>I used this line to patch (patches (search-patches "config/modules/aux-files/stable-diffusion-cpp/vulkan-support.patch")) <civodul>ACTION updates teams with new Codeberg accounts <ekaitz>hi people I have a stupid question: is there any obvious way to filter codeberg emails form guix according to: those that are very specifically directed to me (such as mentions) vs those that are coming to me because I'm part of a team? <futurile>ekaitz: in 'preferences' there's a 'set email preference' and you can set "Only email on mention". How do you currently filter out your email? <ekaitz>futurile: that would only send me the mentions... i want everything to be sent to me, but filter it in my email with tags and so on <ekaitz>isn't there any email header or so that I can use? <futurile>ekaitz: hmm mention me on an issue and I'll see what it sends me <futurile>ekaitz: I currently filter on X-Forgejo-Reason" "pull" - I don't know if mentions change that <gabber>did i miss some memo on how our new pull-request workflow works? i guess i "fork" the main repo to my own codeberg account, push my changes there and then do a "pull request" which would merge to the main repository? am i missing something? <gabber>also: do i need to add my codeberg account name to my team entry? <meaty>Guix, does anyone here have experience running a cgit server with guix system container? I have a simple-operating-system set up with cgit-service-type, but I cannot access it because trying to use port 80 gets permission denied <meaty>Run with 'sudo $(guix system container remote.scm --network)' <ekaitz>gabber: what you say sounds correct. You could also use agit-flow that doesn't require you making a fork of the repository, but it's not necessary <apteryx>civodul: btrfs-balance runs every 3 days on berlin. it reclaims freed btrfs blocks (which is necessary to actually free space on btrfs). <apteryx>it's gotten slower than it used to be, I think. I think the time it takes should vary linearly with the size of the used space. Our disk usage used to be around 10 TiB and now it's often aroun 40 TiB. <civodul>apteryx: sounds like defrag on MS-DOS? :-) <civodul>but yeah, we should probably check where increased disk usage comes from <apteryx>it's shuffling bits around, thus is IO intensive. <apteryx>it's best to run it regularly otherwise all the freed space we 'guix gc' daily won't actually be usable <apteryx>3 days is about right, I'd say. If there's not much to do, it doesn't take much time. <apteryx>if we do it once a week, it'll take longer then <ruther>meaty: that is because it is privileged port, see net.ipv4.ip_unprivileged_port_start. Containers cannot bind on privileged ports, at least by default <apteryx>(it's a bit like 'guix gc' in that sense) <apteryx>maybe the performanec of the array has gone down? I remember different area of the SAN disk can perform very differently. So the more we use, the less consistent the performance may be (the SAN appears to be assembled from non-uniform disks, or at leat that's how I'd explain that observation). <ruther>gabber: you do not need to add your codeberg account to any team entry. Not even sure what you mean since only someone with admin access could add you to a team <apteryx>increased disk is mostly from nars, I think. We're building way more of them since we use topic branches. <apteryx>and then multiplied by 2 because we still compress with lzma. that's the easy place to reduce our usage. the other easy place is shortening our retention policy, e.g. from 6 months to 3 months. <cbaines>civodul, apteryx you could tweak the usage parameter (currently 5) and/or use the limit parameter <apteryx>we don't want to limit it; we want a full run, to match the full 'guix gc' run <civodul>apteryx: it could be the array going slower, but i have no clue how to investigate <mra>civodul: thanks for the feedback on #127. i think that the problem itself is easy enough to solve, it's just trying to solve it in a way that's compatible with adding ZFS support that's a bit thorny <mra>I do wonder... with ZFS being such an outlier in terms of licensing, maybe the changes to initrds could just have a special case where if ZFS is included the initrd is marked as non-substitutable? <apteryx>civodul: in the past, we benchmarked using fio, but interpreting the results is not easy <apteryx>maybe you could run 'kdiskmark' via x-forwarding to get an easier to comprehend picture (it's a graphical tool that uses fio under the hood). <civodul>apteryx: no idea; i must say i don’t know much beyond top and iotop <civodul>mra: maybe; the ‘guix publish’ patch cannot be ZFS-specific though <ruther>is there other interface to QA that would be faster? For example loading failing changes on a branch loads for too long, sometimes even leading to time out <cbaines>ruther, not that I'm aware of, QA is just querying data.qa.guix.gnu.org though, and you can easily run QA locally, so there are options <ruther>cbaines: hm. I suppose it is data.qa.guix.gnu.org that is slow though? <cbaines>ruther, yes and no, QA queries data.qa.guix.gnu.org in the background, but it's also the case that data.qa.guix.gnu.org is particularly suffering at the moment <ruther>maybe at least the 502 timeouts could stop, depending on how the proxy is made <cbaines>I think there's maybe some inefficiencies with the way it produces such large JSON responses <mra>civodul: yeah, completely agreed <ruther>cbaines: currently? it was never fast for me, I don't use it that often, but never in last months when I loaded it (clicking on failed, blocked, etc.) <cbaines>I think it worked better a month ago, but this could also be down to the current patches and branches it's working with <ruther>I am looking into failing package build on core-packages-team. Currently my hypothesis is that package is failing because of update of gcc from 11 to 14. This package is no longer maintained. What is preferred way to resolve this - somehow patch it or just use older gcc with it? <civodul>ruther: which package is currently failing? <ruther>civodul: the one I am looking at is motif <ruther>I don't really know how to see in QA how many packages depend on failing one so I chose one randomly that had was succeeding -> now failing, I think it's just a leaf package in this case <ruther>There are 7 failing total, one of those is failing only on 64 bit <ruther>and one of them is failing only on x68_64 <ruther>civodul: btw I really think we have an issue with force pushes to savannah - I've sent you explanation in e-mail <andreas-e>ruther, cbaines, civodul: I am a bit lost with mentioning savannah. I suppose QA/the data service has been switched to fetch branches from codeberg? <ruther>Ah, then it's not that of an issue, I was afraid it wasn't switched <andreas-e>How about the patches? Right now it seems to still work on debbugs. I think this is a good choice, since it will help us empty the old issues and patches list. <gabber>ruther: i am part of some teams as per teams.scm and am wondering how my team membership translate to the codeberg situation. now i'm seeing commit ddd1581f0b3 adding codeberg accounts to some of them and wondering if i should add my codeberg user account to my teams.scm entry as well <civodul>andreas-e: the Data Service can now receive webhooks for new PRs and act on them, but i don’t think this has been deployed, and probably work is needed on qa-frontpage as well; cbaines, WDYT? <mgd>Hello all. I've just done a fresh install of GuixSD with exwm. packages installed though (M)ELPA work fine but the same doesn't work when using guix install. Is there an extra step I have to do to make emacs recognize the packages? <ruther>mgd: do you have emacs installed in the same profile & did you relog after installing the first emacs package? <cbaines>civodul, andreas-e it's probably not deployed to hydra-guix-130 yet, but it can be, I deploy specific commits when testing out stuff <andreas-e>Well, I would argue that as long as debbugs is not empty, we should process the bugs there first :) <andreas-e>Probably we also need some kind of coding sprint for emptying debbugs. <civodul>andreas-e: that’s a good idea, it would be great to have an online hackathon <civodul>(not that of the FSF, but a Guix-specific one) <civodul>but yes, we should keep working on patches available on Debbugs as well <andreas-e>Another question is that of the branches. Once we have gone through the list at QA, shall we continue using debbugs for newer branches? <civodul>cbaines: let me know when you deploy the Data Service, i’m curious to see how it goes <civodul>andreas-e: we should eventually switch to using “issues” instead of guix-patches, following the GCD, but we should think about how to transpose this process concretely <civodul>i think we want to keep the methodology, just move it from Debbugs to Forgejo <ruther>hm. I added gcc-11 to package native-inputs on core-packages-team and now libstdc++-11 is failing to build with "internal compiler error: in gimple_build_eh_must_not_throw, at gimple.cc:730" <cbaines>civodul, nice! I was looking at the runner/Actions thing in terms of GitHub'ifying repositories <cbaines>unfortunately I don't really know how this Actions thing works, back in my day you used Jenkins/Concourse with GitHub, and I never used GitHub Actions myself, so I'm going in to this a bit blind <civodul>cbaines: i don’t have a clear view yet, but i’m confident we’ll put it too good use :-) <civodul>potentially things like ‘guix lint’ or triggering web site updates could go through this i suppose <cbaines>civodul, I've deployed the latest data-service to hydra-guix-130 (data.qa.guix.gnu.org) now <civodul>cbaines: does it really need to be removed? i’d expect the new ‘git_repositories’ rows to just be added leaving these two rows unchanged, no? <civodul>i don’t see any call to ‘specify-git-repositories’ though <civodul>cbaines: i’d prefer to let you handle the update/reconfigure though, when you have time (no rush) <civodul>BTW, i also took note of your comments regarding handling authentication in the application rather than in the reverse proxy <ruther>mgd: so what is your emacs load path? <ekaitz>civodul: as a basque I have to agree with the "no ETA" part <jakef>so many exciting developments <meaty>Is the documentation for functions in the manual generated from their docstrings? Or is it manually copied over <ruther>mgd: so how did you install the emacs packages? guix install? <andreas-e>civodul: Did you see the message by sharlatan about CI not "being healthy"? Indeed I saw that it did not process the c++-team branch, and apparently this has now spread to master (but this show 504 right now anyway). <mgd>ruther yes, for example `guix install emacs-ef-themes` <ruther>mgd: does ~/.guix-profile/etc/profile set EMACSLOADPATH? <ruther>mgd: also apart from the load-path variable in emacs, what is the env var EMACSLOADPATH set to? <mgd>ruther I'm not sure about your first question. I'm fairly new to guix. EMACSLOADPATH is /run/current-system/profile/share/emacs/site-lisp:/gnu/store/qly0w6rap420fz1prf278549bm93k8sd-emacs-29.4/share/emacs/29.4/lisp <ruther>mgd: does ~/.guix-profile/etc/profile contain the string EMACSLOADPATH? <mgd>ruther ah, it doesn't <ruther>mgd: then you don't have emacs in your profile which you claimed you did... or does `guix package --list-installed` really show emacs? <mgd>ruther I'm new to guix and I might have missed a step in the installation? I just used the graphical install with exwm as the window manager. I'll check now but I assumed emacs would have been installed with exwm <mgd>ruther you're right. Emacs is not coming up under --list-installed. So even though exwm is running, i still have to install emacs with guix? <ruther>mgd: you need to have emacs in the same profile you install emacs packages to, to get the search path EMACSLOADPATH. <ruther>this doesn't have anything to do with exwm, it's just how guix works <ruther>the same would be if you installed emacs to your system and then guix installed emacs packages, being in another WM, doesn't matter <mgd>ruther I see, so I need to install emacs with guix install? <mgd>ruther that's working now. Thank you for your help <mgd>ruther that's working now. Thank you for your help <g_bor>Should we ask around upstream for help? <g_bor>The thing is simply adding keepalive is not a good solution (it would be easy though) <g_bor>Proxy-Connection header is not a standard header and is viewed as an ad hoc header by the standards committee. However, it is widely used by browsers and proxies. <g_bor>This is the problem with it. <g_bor>I would also split the issue of the http_parser off from this one, it should be independent. <civodul>g_bor: i don’t know, we could report it upstream (libgit2) indeed <g_bor>Let's go for it, and we see how it goes. It might still be something on our side, but I don't think so, especially that they already tackle similar issues in the code. <g_bor>Let me take a look, I will report it and link it to our issue <g_bor>Is it a blocker for you as of now? <meaty>where are php modules packaged? or does php not work like that <ieure>meaty, Pretty sure it still works like that, though it's been about 15 years since I used ot. <ieure>There was a $PHP_INCLUDE_PATH or something similar. <meaty>ieure: I mean where are the packages for them under guix? I want to package freshrss <meaty>but `guix search php zip/json/etc.` yields no dice... there *is* an importer though, it seems <g_bor>civodul: I have pinged them, it looks like we have a genuine new problem, but I am not sure, as there are quite some issues open. It also looks like it was last touched 4 month ago, which indicates that either I am missing something, or that we might have to take this into our hands. I can spend a bit more time on this, but I would not like to <g_bor>stuck in a situation where we need to maintain a patch downstream... <meaty>hmm... what color should a "help-wanted" label be? <meaty>I'm thinking "lemon yellow" #fff36D but maybe it would look ugly in a set with the guix orange <csantosb>I'm a bit disconnected ... are we building patches submitted in codeberg with qa ? <csantosb>I know this is the case with guix-science, also in codeberg <guix-newbie>can a guix.scm refer to the directory it is in as the source for a package? <luca>guix-newbie: Sure, use `(source (local-file (dirname (current-filename)) #:recursive? #t))` <ruther>guix-newbie: it isn't a good addition, because it has nothing to do with origin, you put local-source directly to package-source <guix-newbie>I looked at `origin` because the documentations says: "The source field of the package is an <origin> object (see origin Reference, for the complete reference)." <civodul>i’m looking at the problem that prevents some people from pushing to the repo <civodul>i’d like to test the hypothesis above <mra>is there a guix policy on WIP pull requests? i could make one with the 55231 changes, but exactly what that pr will look like will depend on how #127 is merged <mra>just don't want to clutter up the repo with a WIP pull request if those aren't appreciated <ieure>mra, I'd only put up a WIP if I was seeking feedback before completing it. Otherwise, would keep in a branch in my fork. <ieure>IMO, that's the line -- put up a PR when you're ready for feedback. <mra>ieure: alright, sounds good. I'll hold off for now. I still need to figure out how to fix the 55231 patches to work around non-substituability not being inherited <guix-newbie>is it possible to get the output of `git ls-files` as a list of strings in guile? <guix-newbie>i'm coming from nix and there, listing files in a flake only covers the files that are part of the same repo as the source file <mra>adding something like "if this initrd takes the zfs package as an input, mark it non-substitutable" would probably work, but this feels kind of hacky and quite brittle <guix-newbie>which is convenient when adding a `guix.scm` or similar to a package <mra>although treating ZFS as a special case probably isn't too ridiculous. licensing-wise, it kind of it. <RavenJoad>guix-newbie: This is what I use in modules for my Guix-based projects. (define vcs-file? ;; Return true if the given file is under version control. (or (git-predicate (string-append (current-source-directory) "/../..")) (const #t))) <RavenJoad>Then pass that to local-file's #:select? predicate. <luca>Alternatively if you want to build from HEAD you can `(source (git-checkout (url (dirname (current-filename)))))` <guix-newbie>the git-checkout sounds like it does a checkout, i just need the list of files (from HEAD) <identity>guix-newbie: my first thought is, you could invoke git ls-files, get-string-all the output, string-tokenize the string, and you have your list of files (do not come to me when it breaks on whitespace in file names though) <guix-newbie>identity: i looked for how to capture stdout, but did not find anything yet, so i'm not sure how to get the output of git ls-files <ruther>guix-newbie: that's what pipes are for, ie. open-output-pipe <civodul>mra: you can mark pull requests as WIP; hopefully that should be clear enough to avoid misunderstandings <mra>civodul: alright, thanks. i'll make one when i get home <guix-newbie>luca:'s suggestion of git-checkout lists the files. Now I'm bumping into the fact that guix does not have many node packages yet and that in contrast to nix, they need to be all be (manually?) converted. My fairly small project needs 944 packages... <ruther>guix-newbie: they aren't usually manually made, that would be insane. That's job of the importer <identity>ah yes, node, fairly small project, 944 dependencies <ruther>like every small node project... :) ... :( <guix-newbie>yeah, i'm not thrilled with it either and regularly try to cull it. the use of typescript + vue + express adds up <guix-newbie>ok, so besides node-build-system there's an importer somewhere <identity>guix-newbie: guix import npm, also see (info "(guix) Invoking guix import") <guix-newbie>i guess i need the wip-node-importer branch for that <guix-newbie>ah, no, that's 4 years old. master says: `guix import: error: node: invalid importer` <luca>What command did you use? <identity>guix-newbie: the importer's name is npm-binary