<rekado_>I wonder if that would just cause interop problems <rekado_>I’m looking at my Emacs init.org and I don’t like that I’m separating the package installation (via manifest) from configuration. <rekado_>some of you probably use “use-package” to load and configure packages <rekado_>apparently “use-package-ensure-function” or “use-package-pre-ensure-function” could be used to let “use-package” install things via Guix. <mbakke>the reason mariadb dependents fail on 'staging' is because mariadb_config assumes the include directory etc is relative to /proc/curproc/exe in the new version... <raghavgururajan>sneek, later tell LXQJ8n4: Within wip-desktop, most are ready except GDM. Danny (dannym) and I, are still figuring out where and how to merge, without affecting current guix system. *raghavgururajan just realized that he has lot of email backlogs to reply *apteryx run their good old fiasco finder script: Number of potentially problematic GitHub packages: 94 ***butleria1 is now known as butlerian
<apteryx>berlin's bandwidth is not great ATM: 217KiB/s <lfam>apteryx: I've noticed slow speeds from berlin to north america for the last week or so. I noticed it seems to be per-file — some downloads are as fast as normal, others are really slow <lfam>I'm wondering if something changed about how uncached files are served <dissoc>im having a hard time getting a lvm volume (raid1) to work with guix. is there a more detailed example anywhere? <dissoc>i set up the mapped-device of type lvm-device-mapping <dissoc>and i think it fails because lack of kernel modules. but i added (service kernel-module-loader-service-type'("dm_raid" "dm_mirror")) <dissoc>it seems to work when i do everything manually after modprobe dm_raid in working system. just not at boot <dissoc2>i think i got it to work by adding "raid1" to the initrd-modules <rekado>apteryx: connection-wise nothing has changed <dftxbs3e>cbaines, guix-build-coordinator-agent somehow ended up disabled, disk space had run out again with guix gc for 15G free space every hour, so increased it to 32GB every hour <guix-vits>you may keep silent. i know that were hippies' conspirstion. <guix-vits>is list of substitute servers do exist? i used search on irc logs, but didn't found anything. ***clemens3_ is now known as clemens3
<mbakke>rekado_: I've been working on a TeX Live upgrade and could use a sanity check. For 'mit-scheme', I had to add kpathsea to its texlive-union, and also patch shebangs in the texlive-union procedure. Does that seem reasonable? <mbakke>maybe kpathsea should be in 'texlive-base' instead <civodul>rekado_: yesterday you wrote about 'use-package-pre-ensure-function', it'd be nice if this could use Emacs-Guix <ngz>Speaking of Emacs Guix, I wrote a tiny Elisp library to use Repology API. Maybe it could be of some use for Emacs Guix. <civodul>we have "guix refresh", which performs the same function but runs locally <civodul>i hope we won't let it bitrot in favor or a service <ngz>I use it to check if some Emacs packages need an update. <civodul>do you know if there are cases where "guix refresh" isn't up to the task? <civodul>would be nice to see how we can fix it <ngz>guix refresh is of no use if we use a tagged revision in a git repository. <civodul>depends on where the repo is hosted :) <civodul>there's a "github" updater, for instance <ngz>Yes, but, IIRC, it works only on releases. <civodul>but then no tool can help you choose an arbitrary commit <ngz>Yet, there's the notion of "latest tag" <civodul>perhaps the GitHub API supports that too <ngz>But really, my intention is not to replace guix refresh. It's more about kno <ngz>knowing when to refresh <ngz>It can also be used, well, to find packages not in Guix, but in other distros <morgansmith>How do I set a property using transformations so that it propagates everywhere? I'm trying to change the emacs used in the emacs build system by setting the #:emacs key everywhere. <ngz>Hmm, the manual is lying! guix refresh --type=crate => error: no such updater… <ngz>Oh. I see. It's "guix import crate", but "guix refresh --type=crates" <ngz>What about renaming the crate updater `crate' instead of `crates'? <mbakke>the idea being that if it finds a later version, try adjusting the source URI accordingly and see if it downloads <katco>any stumpwm users having issues after the recent common-lisp build system work? any stumpwm module which has `inputs` defined can't find said inputs when trying to load the module. in my config i'm doing this: `(set-module-dir "/run/current-system/profile/share/common-lisp/sbcl")`. if i instead do `(set-module-dir "/run/current-system/profile/lib/common-lisp/sbcl")`, it can't find the stumpwm modules at all (i think it needs the <katco>i guess i should have put recent in quotes :) <sneek>glv?, pretty sure was seen in #guix 2 months ago, saying: nckx: OK.. <morgansmith>Does anyone know how I would change a build input using transformation stuff? <morgansmith>I think build-system-with-package-mapping is my solution but it's not exported <simonsouth>morgansmith: Perhaps you want package-input-rewriting? Section 8.3 of the Guix manual talks about this. <morgansmith>ya idk this doesn't seem to do anything: (package-input-rewriting/spec `(("emacs" . ,emacs-native-comp)))) <simonsouth>package-input-rewriting takes a spec/procedure pair, so you'd need ,(const emacs-native-comp) I believe. <simonsouth>Or just use package-input-rewriting (without the /spec). <simonsouth>Not sure then. It's not something I've used myself. <morgansmith>I think it's because this is a build input, not a normal input <morgansmith>also there is a #:emacs flag specifcally for this but that also doesn't seem to work :/ <morgansmith>my current hypothesis is that there is something not right with the inheritance :/ I can use the #:emacs key to change the emacs in the build-input from an inherited package only if the original package also used the #:emacs key. I think the default has more authority than a key in an inherting package <morgansmith>I'm thinking this because I can do it properly on the emacs-xelb package, but not emacs-org <morgansmith>ok, I figured it out. It's just cuz no-one told me how to use substitute-keyword-arguments. I actually still don't really understand it. The docstring is quite short and it's not mentions in the manua. <morgansmith>so why the heck do I need this double quoted empty list thing? <simonsouth>I suspect ((#:emacs _) `,emacs-native-comp) would work as well, since you don't care what the existing value is, you just want to replace it with something else. <simonsouth>Just looking at the definition in guix/utils.scm:396 and how this is used in e.g. java.scm to replace arguments values. <morgansmith>nah, the _ doesn't work. I assume the case you saw it assumed that the key would always have a value. Since I don't have a value sometimes, it really wants a default <morgansmith>damn it! now I need to somehow limit this transformation to only things using the emacs build system since other things throw an exception. this is really frustrating... <morgansmith>ok, somehow to problem wasn't what I thought it was, it was actually my previous problem a second time <morgansmith>apparently you have to do this if some of the packages don't specify the phases: ((#:phases phases '%standard-phases) <morgansmith>can someone please make some substitute-keyword-arguments documentation? I'm really struggling here <cbaines>morgansmith, I don't quite follow what you say about the phases, what do you mean by "this"? <morgansmith>((#:phases phases '%standard-phases) vs ((#:phases phases) <morgansmith>I was using the second and it seemed to work until it didn't. no clue why <cbaines>morgansmith, both are valid I think. In the former, a substitution will always take place, either using the old value, or the default you've given if no old value exists. <cbaines>In the latter case, a substitution will only take place when there's something to substitute <morgansmith>my stuff seems to be mostly working now that I'm over that hurdle <apteryx>civodul: I somehow thought it was already merged :-) <apteryx>I won't have time to test it before later today. <apteryx>feel free to merge it already if you are confident! <morgansmith>is there a way for me to use substitute-keyword-arguments in a way so I can set a keyword if the package actually has that keyword (otherwise I crash) and always set it even if it's not already assigned to a value? <cbaines>morgansmith, there's a distinction here between the keyword being present in the arguments, and the build system supporting that keyword argument <cbaines>I'm not sure what you mean by crashing, but it sounds like you can do that through providing a default value <morgansmith>it crashes on guix/build-system/gnu.scm 327 because the gnu build system really doesn't like being passed a #:emacs key <morgansmith>I think I'll just put a little if statement that checks the build system of the package <cbaines>checking upfront whether you're trying to make a appropriate modification seems the right way to go <dftxbs3e>cbaines, CPU not 100% all the time still but not OOM'ing or anything <dftxbs3e>I made it 16 cores and 24GB to 32GB of RAM (ballooning) - also increased host's RAM because it was lacking a bit. <dftxbs3e>I have other VMs that also need some space and they were running onto each other toes when it comes to memory <dftxbs3e>turns out netdata isnt packaged in GNU Guix <dftxbs3e>Also it seems very complex for me to write a service.. would really love to learn how to make one for netdata <cbaines>dftxbs3e, does the VM running the coordinator have any swap? that might allow builds to get by when low on memory <dftxbs3e>but it's running on SSDs, don't want to wear them out too fast.. <lfam>You can always buy another SSD. You can't buy back the time it would have saved you <civodul>apteryx: alright, i'll merge it soonish! :-) <civodul>there was a previous series on the same theme <dftxbs3e>how do you solve/workaround that gcrypt issue that prevents upgrades? <dftxbs3e>I am thinking everyone must be meeting this issue now.. <lfam>dftxbs3e: It was mentioned (in another bug report, I think) that not everyone is experiencing that bug <dftxbs3e>lfam, hmm, maybe if you upgraded at a certain time range it gets you stuck <lfam>That bug report does not include a reproducer, so it's hard to help solve it <lfam>When there is a bug, and then a fix, and then someone says "It's still broken" but doesn't share a reproducer, it feels like the reporter is mistaken <lfam>Maybe they are not, but it's basically the worst case for getting help with a bug <lfam>Without a clear way to reproduce this bug, it's likely that nobody will try fixing it <lfam>I'm going to do a reconfigure now to see if I can reproduce it <lfam>In general, knowing how to file good reports is a minor superpower <cbaines>including all the information Guix gives you when it crashes is at least in my opinion a minimally viable bug report <lfam>It also requires `guix describe` <dftxbs3e>lfam, they gave commit id, not sure if sufficient to reproduce but growing a system with that probably is enough <dftxbs3e>But I think it's related to a third party channel I use <lfam>They didn't give the commit ID of their current version of Guix <dftxbs3e>Some recent changes caused API incompatibility issues <lfam>And as you say, with channels, all bets are off. This is why `guix describe` is necessary for a bug report <dftxbs3e>The error message surely doesnt hint at an error with a third party channel though heh <marusich>guix pull succeeded, so I am cross-building the powerpc64-linux-gnu bootstrap-tarballs on both VMs you made available to me. <dftxbs3e>cbaines, I see thanks. But since it's stuck, how do you even use that commit? <cbaines>dftxbs3e, I believe you'd just need to reconfigure using Guix more recent than when that commit was merged <lfam>`guix pull` is the tool used to upgrade the available version of Guix <lfam>And you still experience the bug? <dftxbs3e>I always run: guix pull && guix upgrade && guix system reconfigure /etc/config.scm <lfam>If you'd like to get help solving it, please share the results of `guix describe` <lfam>You might also try reconfiguring after removing the 3rd party channels <dftxbs3e>lfam, it seems I am not allowed to post the result of guix describe here or elsewhere GNU Guix official :-( <lfam>Because your channels provide nonfree software? <lfam>Did you try to proceed without the channels, just as a test? <dftxbs3e>I'll try now, fiddling as we speak! Thanks! <lfam>Great, let us know how it goes <dftxbs3e>Can't wait for GNU Guix to work properly on POWER so I can get rid of the channel :-) <lfam>It's ironic that supporting POWER requires nonfree software <dftxbs3e>lfam, I bought an RYF Libreboot'd Thinkpad from Technoethical but they shipped me with faulty RAM and refuse to replace.. they went radio silence. <dftxbs3e>Also never approved my negative review to show on their website.. shady <lfam>I think all "review sections" are like that <lfam>I mean, imagine you went to the grocery store and the aisles were full of people complaining that they didn't like the food <lfam>No business will allow that <dftxbs3e>Faulty RAM, I'd rather say that they Libreboot'd a Thinkpad X300 which doesnt have upstream support and therefore the DRAM init code is wrong and makes RAM appear faulty. <lfam>This general class of issues is what makes me feel unenthusiastic about the "free hardware" thing <lfam>It's like if someone refused to use nonfree software in 1990 <dftxbs3e>Working with uncooperative hardware vendors certainly is always going to create issues like these. That's why I got Talos II :-) <lfam>Maybe when freely supported hardware is even 2nd class, not to mention 1st class, then it will be viable <dftxbs3e>But that vendor "Technoethical" is just shady. I wish the FSF didnt promote them. <ngz>Hmmm, is there anything special with rust-cbindgen? It points to version 0.13, and the 0.14 release inherits from it. It's rather unusual. <lfam>ngz: Not knowing the specifics of this case, I noticed several cases like this <lfam>Maybe the crate importer does this? Like, 0.13 already existed, and the importer needed to create 0.14 <ngz>No, the importer doesn't use inheritance <lfam>I think it would be better if the importer didn't use inheritance at all <lfam>ngz: Since 0.14 was added by Mark in a "standalone" commit, I'm guessing they needed it but didn't want to disturb (or debug) other cbindgen users <dftxbs3e>cbaines, where can we see live build results for your guix build coordinator instance? <cbaines>it's not "live" though, you have to refresh it <lfam>I noticed that mirror slowed down in the last week. It used to be super fast <lfam>It seemed to correspond with the discovery of the Solarwind thing. I'm guessing some infrastructure was taken offline <lfam>I'm curious, are you in the Americas, dftxbs3e? <lfam>I am, so I always noticed this fast connection to Norway <lfam>I thought about making Guix use the "mirrors" at random, but it actually pre-compiles the list, so it's not easy <lfam>Since this mirror was always so fast, I lost my motivation to change things. Maybe we should rearrange the list <lfam>Yes, but like I said, it's not simple <cbaines>dftxbs3e, don't be too put off by that high number, I still need to do some more work on currating the backlog of builds <lfam>In the meantime, we can reorder it so it starts with a fast site <lfam>Hm... the Norwegian mirror is fast for me again :) Almost 5 MB/s <lfam>The Oregon mirror appears to be offline <dftxbs3e>lfam, still slow for me but I am waiting it out. <lfam>The Australian mirror is also gone <lfam>The Finnish mirror is slightly slower than the Norwegian one but it uses FTP <lfam>We should probably be using the kernel.org CDN, relaly <mbakke>heh, 'CONFIG_CC_VERSION_TEXT="gcc (Debian 8.3.0-6) 8.3.0"' <lfam>I thought about changing that but... does it matter? :) <mbakke>no, I'm just surprised you don't use 'guix environment linux-libre' ;-) <lfam>All the requirements for `make oldconfig` and `make bindeb-pkg` already exist on the system <lfam>I do that, and I also do `guix system vm` <marusich>lfam, you said "It's ironic that supporting POWER requires nonfree software" - can you elaborate on what you mean? <dftxbs3e>marusich, because my laptop isnt exactly RYF-certified :-P <marusich>dftxbs3e, I guess I'm confused; I thought you were talking about Talos II machines <dftxbs3e>marusich, just that I am working on x86 laptop to bring POWER support <lfam>I thought it was ironic that, in order to use POWER hardware, they are having to use a channel that provides nonfree software, since free software support is one of the big advantages of POWEr <lfam>But, I think I misunderstood their situation <dftxbs3e>My Talos II doesnt *require* any non-free firmware, though I like to provide one to my AMD GPU until something better comes out. <mbakke>interesting that the uio.no mirror slowed down on long distance links, I get ~23 MBps from Norway <lfam>mbakke: It had slowed to ~200 KB/s last week, but now it's back to ~5 MB/s <lfam>It was never slow for me until last week <lfam>I guessed some cache was rebooted due to Solarwind <lfam>We should revamp our mirror list, since several of the mirrors are gone <lfam>kernel.org uses a CDN, which should provide optimal performance <mbakke>many of our mirror lists are outdated, I recently updated the imagemagick one <lfam>It does appear to have actually built some things, however, although I'm not sure in response to what. After a few days I noticed that no Rust compilers had been built, so cbaines logged in to berlin and built them "manually", and I can confirm I no longer have build them on the staging branch. But a large part of the ffmpeg dependency graph is still not built <lfam>Let me know if you have any ideas for how I can help. I have time... <cbaines>lfam, if you have a target derivation, I can ask for that to be built on berlin <cbaines>I just checked on the rust stuff, and it build eventually <lfam>Yes, your manual intervention worked <lfam>I'm open to advice for how to proceed <cbaines>is the issue getting enough substitute availability to allow merging staging in to master? <mbakke>the ungrafting branch still has 30k+ scheduled builds, but all the build nodes seem to be idling <lfam>From my point of view, the issue is that I can't tell how much has been built so far <lfam>The GBC is super helpful <cbaines>lfam, I'd check using guix weather, as I don't think the Cuirass web interface is particularly accurate (as it may show builds as scheduled, when the output has actually been built) <lfam>Right, I don't really use the Cuirass UI at all. I mean, I still look at it for some reason but I don't expect anything. <lfam>I'm still missing the old Hydra workflow <lfam>GBC has the potential to surpass it, once I figure it out :) <cbaines>and yeah, data.guix-patches.cbaines.net does know about ci.guix.gnu.org, but the information isn't really up to date <lfam>Sorry if this has already been discussed, but here is what I used to do with Hydra <lfam>We would add a new jobset for a branch, and it would build all changes for each push to the branch <lfam>Then, I could select particular jobs (builds for a push to a branch) and compare them between branches. Example comparison: Latest push to staging compared to latest push to master <lfam>The question is, does it correspond to substitute availability for users? <cbaines>I'm not sure I follow your question, does what correspond to substitute availability? <lfam>Using the interface at <data.guix-patches.cbaines.net>, I can compare build results between branches, at certain points in time. This comparison roughly corresponds to "compare particular commits" and is good enough. It can filter out build results in a useful way, like "show what broke". <lfam>But, can I use to make a judgement about when a branch is "ready" to be merged? <lfam>The relevant questions being, "did it try to build all the new derivations yet, and did an acceptable percentage of them succeed?" <lfam>I suspect you've answered this before... <cbaines>So, when trying to reason about the result of merging one branch in to another, I'm a little wary of the novel things that this might lead to. Take a simple example of ruby being upgraded on core-updates and a Ruby gem being upgraded on master, if core-updates doesn't have that gem upgrade, then merging core-updates in to master will result in a package derivation that's unseen on either branch. <cbaines>I think the practical way of dealing with this is just to try and keep core-updates up to date with changes in master, so with that in mind... <lfam>(I used to manage core-updates on Hydra) <lfam>There's always some risk of breakage at the final step, but good information will minimize the scope of the risk <dftxbs3e>cbaines, lfam: what they do in other CI systems is to do a post-merge CI check and then actually merge. The rust-lang teams do this. <dftxbs3e>They have a bot called "bors" that automates this process. <lfam>I think we have a good idea how CI workflows. The issue is that Guix is still developing the tooling <lfam>dftxbs3e: There was a kind of disaster in the past that left us without any CI tooling <cbaines>You're aware of the Guix Data Service functionality to check for packages failing to build on one branch, but working on another <cbaines>Informed with all that information, package substitute availability on master and staging, plus information on specific failing builds, I think the rest is up to someone to make an informed decision <cbaines>lfam, currently, you need to edit the URL. /package-substitute-availability works for revisions as well as the latest-processed-revision pages <cbaines>I'd feel more comfortable leading people to it if I could give some information about how up to date the information is. Maybe I should just put something on the page saying "this information is probably not up to date" <cbaines>But back to judging when a branch is ready to be merged, no blocking broken packages on that branch when compared to master, and a similar level of substitute availability seem OK criteria to me <lfam>How can I edit the URL to get "package-substitute-availability" for a particular revision? <ZombieChicken>Is there a guide for installing GuixSD onto the Pinebook Pro? <ZombieChicken>I know there is/was some work on that, but I can't seem to find it atm <lfam>Another question I have is about the compare-by-datetime timestamp format. When I put the wrong format, it tells me what the correct format is. It might be good to always show the required format next the input box <cbaines>lfam, I think that's reasonable, would you like to try making that change? It's safe to just find the relevant strings and update them I think. <lfam>What program is it? I'm not finding these strings in build-coordinator.git <cbaines>lfam, wrong repository, you want data-service.git on Savannah <lfam>Ah. I've been conflating the data service and the build coordinator <cbaines>lfam, there's a separate string for the base datetime that you probably want to change too <cbaines>I'm quite happy to try and make the Guix Data Service less of a most changes go through me thing <lfam>cbaines: What is the Git push URL for this repo? <lfam>I think I can figure it out based on the URL for maintenance.git <cbaines>Yeah, they should be consistent ssh://git.savannah.gnu.org/srv/git/guix/data-service.git <lfam>That's funny, I ended up with <ssh://lfam@git.sv.gnu.org/srv/git/guix/data-service.git> <lfam>Whereas for the main repo, I have <ssh://lfam@git.sv.gnu.org/srv/git/guix.git> <cbaines>providing you get to the right IP, I think it's fine :)