<mroh>hmm, font-google-roboto doesn't contain anything (anymore) e93ee2547ecec152f9a198ccc338c4329cc69a71 <sneek>apteryx, you have 1 message! <sneek>apteryx, mbakke says: I don't think removing python2 is feasible, but I am trying to remove all non-essential uses <mroh>I don't have superpower, but I'm just making a (small) patch. I think, the difference is only that the old font.zip has a subdir and the new zip hasn't... <mroh>So overwriting unpack phase somehow should do it... <guixy>Still working on making that arm build farm with foreign distros. <guixy>After some logging, I see `guix offload test` fails at `assert-node-can-import`. <guix-vits>sneek: please sir be so kind and deliver the following words, in other words, tell later guixy: tbh, da Guix in da A.R.M thingy isa reela tricka duck, seen? <sneek>later, guix-vits says: guixy: tbh, da Guix in da A.R.M thingy isa reela tricka duck, seen? <guix-vits>please sir be so kind and deliver the following words, in other words, later tell guixy: tbh, da Guix in da A.R.M thingy isa reela tricka duck, seen? <guix-vits>sneek later tell guixy: sometimes things broken by itselves on arm. cheer up. <sneek>guix-vits, ryanprior says: stop being obtuse :3 <apteryx>amazing! All the emacs-build-system packages except emacs-picpocket and emacs-twittering-mode currently build on master. <apteryx>Our Emacs ecosystem is in good health. <jmarciano>I wanted to do: guix import pypi -r leo, and it failed for window-curses, then I tried: guix import pypi -r window-curses and then it failed with problem here described: http://ix.io/2Ivf <jmarciano>please help if you know how to import window-curses that I may import leo editor <apteryx>If I drop the '-r' option of the importer, I see the message 'guix import: error: failed to download meta-data for package 'window-curses'' <apteryx>it's probably a very old, unmaintained package that lacks common metadata <apteryx>not sure why '-r' masks the error message though... <apteryx>actually window-curses doesn't exist at all <apteryx>there's 'windows-curses' on PyPI though <jmarciano>guix import: error: no source release for pypi package windows-curses 2.2.0 <apteryx>windows-curses seems maintained (last release was last month) <apteryx>but the importer does say what the problem was: guix import: warning: Cannot guess requirements from source archive: no requires.txt file found. <jmarciano>guix import pypi -r leo is original command I wish to get working. <jmarciano>if it looks for window-curses maybe it will never find windows-curses <apteryx>no it does look correctly for windows-curses <apteryx>but it doesn't have the metadata file it expects to find from the package archive <jmarciano>is it possible to provide meta data on command line by constructing it <jmarciano>and does guix import creates scm recipe for a package? <jmarciano>I will need to disconnect within a minute or so, please leave me message by using sneek or email bugs@gnu.support <apteryx>yes, you can try 'guix import gnu hello' to see an actual result of a auto-generated package definition <apteryx>it's not self-contained, in that it's lacking top level imports necessary, such as (gnu packages) et al. <apteryx>but that is usually what we want, as we copy paste these snippets into the correct existing Guix module file, which would probably already have everything needed. <apteryx>(and then edit them into perfection ;-)) <ezioauditore[m]>Ah its functional but ive got a pm ChanServ with guix info so i thought I've to do something with it... ***apteryx is now known as Guest16789
***apteryx_ is now known as apteryx
<mothacehe>davidl:looks like cargo is using "-j1", any reason not to use "parallel-job-count"? <mothacehe>oops I wasn't targeting you David, tabulation error! <zalox>Hi. I'm getting an error when running guix pull. Could someone point me in the right direction to solve? guix pull: error: Git error: object not found - no match for id (c2e2107d73f153793f2486739e39393ef4f19d5b) <abcdw>Hi guix! connected to repl with `guix repl -L . --listen=tcp:37146` using geiser-connect. Every operation works veeeery slow, even simple evaluation of (pretty-print "test"). <abcdw>zalox, Have you configured channels.scm? <zalox>abcdw: Yes. I've added nonguix from gitlab. <abcdw>zalox, probably you misspelled (commit "blablabl") somewhere <abcdw>Make sure that all channels you use have the commits specified in your channels.scm. <abcdw>or just remove (commit "...") and guix pull will obtain the latest possible commit. <abcdw>zalox, looks like there is nothing to break here <abcdw>zalox, mb something in /etc/guix/channels.scm? Try to do explicit `guix pull -C ~/.config/guix/channels.scm` <zalox>Nothing there in etc. Same error with -C <abcdw>zalox, Does it work if you remove channels.scm at all? <mdevos>cbaines: the certificate of cbaines.net has expired (but www.cbaines.net is ok) <cbaines>mdevos, hmm, I get a redirect in my browser. I've restarted nginx anyway just in case. <civodul>cbaines: ah nice! i didn't know we had a MELPA importer lingering *civodul posts a patch that'll simplify offloading setup <civodul>now i can switch back from "fill the patch queue" to "empty the patch queue" :-) <abcdw>guix-vits, I have guile 3.0.4 <cbaines>civodul, great! the recent changes in and around the guix-daemon look really cool :) <cbaines>mdevos, ah, and yeah, turns out NGinx was using an old cert for that domain. I should have actually fixed it now. <mdevos>cbaines: confirmed! I don't see any certificate warnings anymore <guix-vits>abcdw: i should admit, idk even if that was possible to help with `guix repl` this way, as the command may use its very own profile instead of user's guile. <cbaines>I wonder if there are any tools that could be used to spin up VMs or "containers", run the script, and report on the results <cbaines>sort of like the system test stuff in Guix, but more general <mothacehe>that's tricky because we would need VM running foreign distributions <cbaines>yeah, I'm not suggesting trying to extend the guix system test stuff, that might get awkward in terms of testing Guix being installed <cbaines>mothacehe, by the way, how are things going with getting Cuirass to not offload through the guix-daemon? <mothacehe>but currently all the workers are stuck building rust packages <mothacehe>and single CPU are propably pretty weak on build machines <cbaines>and yeah, I noticed the influx of rust stuff, seems my desktop computer has built them all now I think, it's building common lisp stuff now I think <mothacehe>I'm also thinking about prioritizing guix-modular and guix-master over other specifications <cbaines>I've been thinking on how to get the Guix Build Coordinator agents to dynamically do more or less builds depending on the free CPU time/memory, but I don't think I've thought of a good approach yet <cbaines>another approach to packing builds on to machines would be to try and predict the peak resource usage, based on historical data. <cbaines>mothacehe, does zmq have some ordering/priority mechanism? <mothacehe>cbaines: that's interesting, but really hard to get right I think <mothacehe>not per se, but with the remote building stuff, Cuirass now has build queues per architectures <cbaines>mothacehe, indeed, I might try something simple first, like deplaying builds if the load is high perhaps <mothacehe>so if Cuirass can compute a priority of each derivation, then it's just a matter of ordering the build queue <mothacehe>my idea is to have a priority for each "job" and each "specification" <cbaines>In the Guix Build Coordinator, each build has a priority, and the allocators look at the graph, so if a low priority build's outputs are needed by a high priority build, then that low priority build will be treated as high priority <cbaines>It works enough to prioritise building the Guix pull related derivations <cbaines>I need to look in more detail at what's actually going on with trying to build patches/staging/core-updates stuff <GewaltDisney>dreaming of the day guile-emacs will be realized. working on guile is infinitely more pleasant than emacs with elisp <cbaines>I'm still quite attached to the idea that it'll be easier to handle differing needs between building things for substitutes and building things for quality assurance by having more separation <cbaines>although maybe once the tools become sophisticated enough, it'll flip the other way <GewaltDisney>cbaines, this was a response to a convo happening before my comment, correct? i just logged in <mothacehe>cbaines: yeah, I must admit I'm really focused on substitutes availability for now <mothacehe>but it would be nice to see those tools converging on day <cbaines>on one level, I'm not sure it's even a tooling issue. I think building things for substitutes benefits from stricter controls than doing QA stuff <cbaines>and that alone may justify separating out the infrastructure <cbaines>dftxbs3e connected a VM they have to the Guix Build Coordinator I run for patches/staging/core-updates stuff, which is great for helping out do quality assurance, and because I run a separate Guix Build Coordinator instance for builds for substitutes, there's no risk of things getting mixed up <civodul>cbaines: yeah! i like it when i see pause-less substitute downloads :-) <cbaines>I also have some ideas about reducing latency with narinfo's, although it's a complicated plan and involves PostgreSQL, logical replication and knot doing GeoIP stuff <cbaines>maybe there's some room for improvement in doing some kind of automatic mirror lookup (SKS keyserver pool style) with Guix substitutes <civodul>you're the SKS expert, you'll tell us how to get there :-) <cbaines>I'm trying to experience the low latency myself by having guix.cbaines.net serve substitutes from Singapore <civodul>so low latency for pipeline GET /*.narinfo requests? <cbaines>yeah, I don't have much evidence, but I'm guessing latency is a significant factor when fetching substitutes from somewhere far away in network terms <cbaines>this is particularly apparent when doing things like fetching derivations, since there's very little pipelining, and lots of round trips <civodul>ah yes, but only in this case i think <civodul>because in that case many substitutes are fetched one by one <civodul>we could speed that up with connection reuse for --query <efraim>my vim patch is almost 3 months old <mroh>civodul: hey! Thx for asking! The license change should still be applied, imho. The seq change/remove isn't needed anymore. <efraim>cbaines: it needed more work, and more attention than I'd been ready to give it <cbaines>efraim, OK, is that more work to try out using a environment variable for the search path? <cbaines>I guess that would make the behaviour a bit more explicit and user controlable <efraim>the problem is VIM_PLUGIN_PATH is only picking up addons in $GUIX_ENVIRONMENT, not in my profile or $PATH <efraim>I can parse $PATH and append "../share/vim/vimfiles" to pick up directories, that might work better for pure environments <cbaines>efraim, does that depend on whether you use --pure for the environment? <cbaines>I'd expect when not using --pure, the search path would include your profile <efraim>i've been testing so far without a pure environment, it hasn't been picking up the plugins in my regular profile <cbaines>I'm not sure I get the involvement of $PATH <efraim>here's my PATH, as parsed by vim: ['/gnu/store/sjrs4rg4n6s32lk2jjpxqjzanxx2qqwc-profile/bin', '/home/efraim/workspace/guix/scripts', '/home/efraim/workspace/guix', '/home/efraim/Applications/.bin', '/gnu/store/0mq5ja74psqlrbmsl8q6mcp1yrlhcxqh-enlightenment-0.24.2/bin', '/run/setuid-programs', '/home/efraim/.config/guix/current/bin', '/home/efraim/.guix-profile/bin', '/home/efraim/.guix-profile/sbin', '/run/current-system/profile/bin', '/run/current-system <efraim>and VIM_PLUGIN_PATH ['/gnu/store/sjrs4rg4n6s32lk2jjpxqjzanxx2qqwc-profile/share/vim/vimfiles'] <efraim>it should include /home/efraim/.guix-profile/share/vim/vimfiles <cbaines>Taking ruby and the GEM_PATH it uses, I have something like GEM_PATH=/home/chris/.guix-profile/lib/ruby/vendor_ruby in my shell <cbaines>then guix environment prepends to this GEM_PATH="/gnu/store/jjs8x5da831g2gpkz8vavzgcfcs79jql-profile/lib/ruby/vendor_ruby${GEM_PATH:+:}$GEM_PATH" <cbaines>efraim, I think if you add the search path bit to the vim package, then install that in your users profile, VIM_PLUGIN_PATH will include the ~/.guix-profile/share/vim/vimfiles stuff <efraim>I'll try that again, I think I last tried it with the VIM_PLUGIN_PATH searching profile/share/vim/vimfiles/share/vim/vimfiles *efraim has to go AFK for a while :/ <civodul>i've stumbled upon a couple of patch series that were still open and had been either already applied, or redone independently <civodul>i wonder if we should have a linter that checks bugs.gnu.org <cbaines># seems to match up with the commands run as root <cbaines>I don't understand what you mean for $ and no prefix <guix-vits>no prefix is a perl of my refined humor sense.. where is the mirror? <cbaines>right, I guess no prefix could just mean that the person adding those lines didn't spot the pattern *guix-vits ahm cool, ye... maaan <civodul>cbaines: typically, when a snippet shows one or several commands without their output, there's no "$" or "#" <civodul>but the manual isn't self-consistent <civodul>having gone as far as reviewing a PHP patch series, i'd love to see it land ;-) <roptat>civodul, oh right, i forgot about it <roptat>I have a few things to do now, but I'll look at it again this afternoon <sneek>bricewge?, pretty sure was seen in #guix 5 months ago, saying: Hello nckx. <davidl>is there a libsystemd-dev equivalent package in Guix? <luis-felipe>leoprikler: Hey, thanks for taking a look at the GNOME Builder thing. I was hoping it was something easier to solve... <cbaines>davidl, I don't believe so, no one has packaged systemd yet <cbaines>davidl, I think elogind was extracted from systemd though <davidl>cbaines: ok, some rust-package I want - crush - is apparently dependent on it and the author doesn't know how to remove the dependency. <leoprikler>I sadly could only fix your first problem with creating new projects. <leoprikler>Or at least I hope I could. I ran the new gnome builder from pre-inst-env without installing it, as that significantly sped up the interval at which I could test it. <cbaines>davidl, crush is a shell, right? I wonder what it's interacting with systemd for? <cbaines>davidl, systemd might not be that hard to package, and might be one to package crush <civodul>cbaines: mbakke wrote a systemd package on April 1st some time ago! <sss2>yes, this is rot related problem <davidl>cbaines: yeah some new cool "shell-thingy" thing. I have no idea why it needs systemd, I suspect systemd is just a dependency of a dependency. <mbakke>davidl: I have an updated version of that patch somewhere, lemme see if I can find it <sss2>why rtorrent built without rpc support ? <cbaines>sss2, I'd take a look at the package definition to see if there's any information there <cbaines>if there isn't, maybe some input or configure flag is needed to enable rpc support <sss2>still had no chance to touch package writing <sss2>but my exherbo system keep crashing piece by piece <sss2>so soon i will heve no other choice <civodul>cbaines: ooh congrats on the 7-, 8-, and 9-month old patches! *civodul pushes "younger" patches, 5 months at most <civodul>there are quite a few patches for somewhat obscure packages where the author seemingly lost interest <civodul>perhaps we should auto-close them after one year <mbakke>there are some issues that should be fixed before I'm ready to merge it, but at least it builds! <mbakke>though I think it's better to make the package work with elogind if possible <civodul>yeah i think it makes no sense for a Guix package to depend on systemd <cbaines>civodul, with Patchwork I've been marking the patches as under review or WIP, and skipping over them <cbaines>but yeah, I'm not sure how to handle that in debbugs, I wonder if it does any archiving automatically <zimoun>cbaines: I have not follwed the discussion but maybe usertag could help with debbugs <cbaines>indeed, doing more classification/triage would be useful <zimoun>mothacehe: your priority list is smaller number higher priority, right? <mbakke>davidl: in many cases you can simply s/systemd/elogind <GewaltDisney>so I was just chatting with a friend, a nixos enthusiast, who wrote off guix as "elitist" considering it is FOSS-only-firmware at times prevents potential users who can only afford a used PC. I tried to convince him that guix makes the practical case for rigour and truth in a world where science is increasingly computational, as closed firmware can potentially let in side effects that can't be simply reproduced. He said I'm wrong and it <GewaltDisney>comes from a misunderstanding of the relation between machines and the processes they implement. He's a computer science MA, whil i'm just a lowly hacker with a phd in philosophy. who is closer to the truth? <cbaines>GewaltDisney, in some ways it would almost be nice if there was expensive hardware that didn't require non-free software to work properly, but I don't think that's the case <cbaines>firmware is still software, and as hardware becomes more complicated, the issues around firmware become more important <rekado_>firmware can become equivalent to circuitry; the distinction is very small. <rekado_>FWIW Guix does not *prevent* the use of blobs. It’s just that it neither comes with them nor guides people to install them. <sneek>Welcome back guixy, you have 1 message! <sneek>guixy, guix-vits says: sometimes things broken by itselves on arm. cheer up. <GewaltDisney>cbaines, you don't think its the case that closed firmware introduces contingencies that potentially pose problems for scientific experimentation, or you don't think its the case that i misunderstood? <cbaines>GewaltDisney, I was saying in some ways it would almost be nice if there was expensive hardware that didn't require non-free software to work properly, but I don't think that's the case <GewaltDisney>thanks rekado_, i know this and *shame* have some installed myself <rekado_>GewaltDisney: I don’t think “shame” is the appropriate emotion here. “Outrage” perhaps. You shouldn’t feel pressured to do that. <rekado_>a lot of the discussions around free software are tainted by misunderstandings; many think it’s something to do with “purity” (oh, look, there’s even a company with a name like that) <GewaltDisney>and that was part of my case to my buddy, its actually quite easy to get the goods you may need but its better for the guix crew to stand by "truth" and let users do what they will. <rekado_>and many seem to think it’s a personal moral failing to use proprietary software <GewaltDisney>cbaines thanks for the link! i'm always interested in this stuff <rekado_>it becomes a moral question when you become (part of) the oppressor <rekado_>e.g. when you “validate” the existence of the proprietary software and thus make it more likely that others are coerced into using it too. <guixy>I traced it down to the call to the call to read-int <rekado_>but using proprietary software is usually only something you do to yourself. This can be a poor decision, or it can be a “poor” decision like cycling to work while threatening your health. <rekado_>(“cycling to work through heavy car traffic” is what I meant) <rekado_>Guix offers a default that ensures that you won’t ever have to be surprised by being controlled by proprietary software. <rekado_>at the same time it gives you the tools to make a decision to use proprietary software; but we don’t do anything to aid that decision. <GewaltDisney>and I even think that its quite interesting in the way it asks you to question your relation to intellectual property/capital <GewaltDisney>there is something like a built in brechtian "verfremdungseffekt" (alienation effect) <rekado_>(someone would point out that the term “intellectual property” is already accepting one the most important parts of it: that it exists) <GewaltDisney>rekado_ on the topic of IntProp, I would say _it does exist_, as a matter of police coercion, which was the topic of Marx's critique of Proudhon titled "the poverty of philosophy" <GewaltDisney>rekado_ see you later, have a nice day / evening if you're in asia <GewaltDisney>Prodhoun's maxim was of course "property is theft"; Marx begged the question - so what is theft? <mbakke>hmm, there are problems with MariaDB on 'staging' (specifically locating <mysql.h>). <jonsger>civodul: a question regarding 6a060ff: in which case do I need to this "import-module/with-extensions guile-gcrypt" dance? <mbakke>jonsger: with-extensions is for guile modules that depend on C libraries such as 'guile-gcrypt'; with-imported-modules is for making any regular Guile module available. <lispmacs[work]>i notice when I restart gnome shell, about 1 GB of memory clears up instantaneously <civodul>jonsger: (guix build store-copy) depends on (guix store deduplicate), which in turn depends on guile-gcrypt <civodul>thus, when you import with 'with-imported-modules' (guix build store-copy), you also need to import guile-gcrypt with 'with-extensions' <civodul>hmm lots of "import" and "with" here <jonsger>I do not use (guix build store-copy) or (guix store deduplicate) directly. Only (guix store) which imports (gcrpyt hash) as well, so I guess I need to the dance then... <civodul>you have a gexp that has (guix store) in its 'with-imported-modules', do i get it right? <jonsger>civodul: it's a gexp with use-modules and one time a #:use-module in the header <jonsger>so for the future this has to be done with every gexp containing an import of (guix store)? isn't there a nicer solution? <jonsger>how can I pretty-print guix builder files? <jsoo>cbaines: I think the emacs-next patch i sent so many months ago was actually to upgrade to what is now just emacs. Perhaps a few items can be fixed with emacs-next variants as they exist now but the original can be closed I think <GewaltDisney>can we start a personality cult around ludo? it could be the ultimate ironypoisoned antithesis of silicon valley: the luddites, a group of hackers <davidl>mbakke: thx. The package I tried to install - crush - I just tried to install via "cargo build" in the source-dir, and I have no experience with the rust build system. However, I removed systemd from Cargo.toml and did export CC=$(which gcc); cargo build and then it starts compiling but still fails with some error about a file not found which clearly exists - I have no idea how to proceed. <joshuaBPMan>GewaltDisney: I believe this cult already exists...? Ludites meditate whilst reading the little schemer, and then make jokes about Rust. <davidl>mbakke: only the very last step fails, seems like its close to work. <dftxbs3e>cbaines, hey, there's lots of these: 2020-12-18 21:25:35 (INFO ): ade25c9b-909c-43d2-bcbb-5c8ec41837cd: setup failure: missing_inputs <cbaines>if a build can't start because one of the inputs is missing, that's reported back to the coordinator which submits a build for that missing input <dftxbs3e>cbaines, with 4 parallel-builds my machine has been mostly idle <dftxbs3e>really should do that load-average thing <dftxbs3e>cbaines, I think it could be worthwhile to execute in parallel lots of single-threaded phases (like 'configure), then queue parallel compilation phases one by one (for those who have it) <dftxbs3e>cbaines, the back and forth missing inputs pings take a lot of time <cbaines>indeed, I think there's room for code improvements, but yeah, more parallelism would also be good <cbaines>as for executing individual build phases, that might be a little trickier <dftxbs3e>cbaines, I think GNU Guix would also really benefit from parallel downloads and HTTP 2 support, if you ever tried Fedora's dnf, it's really fast at that :-) <cbaines>dftxbs3e, if you change --max-jobs for the guix-daemon, you'll get parallel downloads for substitutes <vagrantc>doing builds with --cores=1 --max-jobs=N for N cores you'll probably get more reproducible package builds <sneek>vagrantc, you have 1 message! <dftxbs3e>cbaines, ohh okayy, I'll increase it further, it's same as parallel-builds for the agent right now <vagrantc>civodul: debian currently has guile-2.2 version 2.2.7, so shouldn't be an issue <cbaines>dftxbs3e, hmm, if you've set some value, you probably don't need to increase it <cbaines>it probably won't help with the slow "missing inputs" stuff <dftxbs3e>cbaines, maximizing utilization of both RAM, CPU and disk/network IO is a really tough problem, not sure any package management system has really solved it well. Maybe Gentoo's good at that I think. <cbaines>dftxbs3e, yeah, I haven't used Gentoo, so if you have any references to what they do, that would be great <civodul>jonsger: re pretty-print, if you use Emacs, emacs-guix does it automatically when you open a *-builder file <jonsger>civodul: I don't use emacs and try to write some `guile -c ...` which I can pipe into ^^ <dftxbs3e>cbaines, That --load-average flag of Portage/Emerge they have is really good I think. <civodul>jonsger: then yes, you can do like "cat *-builder | guile -c '(use-modules (ice-9 pretty-print)) (pretty-print (read))'" <jonsger>no, that's wrong. It prints "Derive" <civodul>maybe you actually need a read/print loop <leoprikler>jonsger: I think you're looking at the derivation, then, not the builder <civodul>jonsger: "Derive" is most likely from a .drv, not from a *-builder thing <civodul>i could tell you about emacs-guix but... ;-) <civodul>we could add one, it could be convenient <civodul>note that the Data Service also has a pretty printer for .drv <leoprikler>Well, technically you can, but there's nothing that does the formatting for you already besides the visual markup provided by emacs-guix ;) <jonsger>hm, setting up guix data service for this single drv seems a bit overkill. Then even emacs looks small and lean ^^ <cbaines>pretty printing scheme files, and derivations are both things that would be good to provide through the guix command line <cbaines>unfortunately no one has got around to implementing it yet <cbaines>Given Nix uses derivations, there's a few standalone tools for formatting derivations I think <cbaines>if it's the builder that's crashing, it's just the Guile used for that that's relevant <cbaines>however, increasing your terminal size or setting COLUMNS inside the build/Guile might be sufficient <civodul>what we could do in core-updates is set Guile's idea of the number of columns early on <jonsger>cbaines: that helps only in some cases <PotentialUser-84>I'm new to Guix. The Evolution program asks for a password every time the computer is turned on. <ngz>cbaines: Let's start a roleplaying game! ;) I want to review bug#45247. I go to patchwork.cbaines.net, look for the bug, see all lights are green, click on patch, click on "View comparison", see that there is no introduced lint warning, click on "compare packages" and then… <ngz>(am I right so far?) then I notice there is no colored square on the right. Does that mean the commit has not been processed yet? <ngz>cbaines: hello, btw :) <cbaines>so I'd click Compare package derivations, then due to a bug in the Guix Data Service, remove the Limit results number, tick All results and press "Update results" <cbaines>unfortunately, all that this will tell you is that the relevant builds haven't actually happened yet <cbaines>it's only one package though, so building it yourself isn't too time consuming <ngz>Sure, but that was for the sake of understanding the process. <cbaines>as this is a version update, this page just showing httpstat tells you that this is a leaf package, there are no dependencies <ngz>PotentialUser: I don't understand your question, sorry. <cbaines>PotentialUser-84, do you want to reigster an account with Freenode, or are you looking for advice on IRC clients packaged for Guix? <cbaines>sorry, that was a question for PotentialUser-37 <ngz>cbaines: how do you see the builds haven't actually happened? Also, what patch could be more interesting as an example. I still have trouble parsing the "Compare package derivations" page. <cbaines>ngz, so, the compare package derivations page lists derivations, and they're grouped by package name/version <ngz>cbaines: In particular, I see no explanation about the in and out of the colored squares <cbaines>the derivations that are present in the base revision, but not the target revision have a red - to the left of them <cbaines>ngz, if you click on the derivation, you'll see the builds with more information <cbaines>the colours are consistent, so blue means scheduled, red means failed, green means successful <PotentialUser-37>cbaines, Yes, I saw this page, but I did not understand it correctly. Excuse me for taking your time, please tell me this in a simpler way (in Guix). Thank you very much. <ngz>There is also gray, and numbers inside. <cbaines>ngz, the numbers are counts of builds in that state <ngz>If I may, I'd suggest to but a quick recap on this page for people like me… :) <cbaines>PotentialUser-37, I don't think Guix provides a simpler way of registering nicknames on Freenode. If you don't understand Freenode's documentation on the process, there's probably other documentation that might be more detailed. <cbaines>ngz, I think that's a bug. If you click on that scheduled (blue) build, you'll see that the events don't have timestamps <cbaines>I can't remember what might cause this, but one part of the code is probably correctly working out that the build has succeeded, and another part incorrectly thinks it's scheduled <ngz>And (false) means "not built yet"? <cbaines>that page is really bad, it's my very early work on a web UI for the Guix Build Coordinator <ngz>I think I start getting the picture (phew!) <ngz>Ideally, it would be nice to have some dashboard accessible from patchwork that lets you know 1. if the patch introduces linting issues 2. if it has been built already 3. if it introduces build failures in dependents <cbaines>ngz, yeah, maybe that can be some other thing that uses information from the Guix Data Service, or maybe those can be reported to Patchwork as checks <cbaines>The current "Checks" are really just me abusing the Patchwork interface to link to other things <ngz>IMO, they do not really belong to patchwork, indeed. <ngz>(not that they are not useful, of course) <LXQJ8n4>Hi there :) I was wondering why guix has a relatively old version of gnome. Is it just because no one has updated it yet or is there some other reason? <rekado_>LXQJ8n4: a newer version is available on the wip-desktop branch, but it hasn’t been merged yet <rekado_>raghavgururajan is better equipped to say something about the state of the branch. <LXQJ8n4>Ok thanks! Do you know when it will be merged? I'm new to guix and don't know how long it usually takes <mbakke>LXQJ8n4: probably not until a couple of months, I think <mbakke>I wonder if we can use a different version of 'glib' for GNOME, so that we can update it directly on master/staging in the future, without having to go through core-updates