IRC channel logs


back to list of logs

<rekado_>I wonder if that would just cause interop problems
<rekado_>I’m looking at my Emacs 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.
<sneek>Got it.
*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>sneek: why was you banished from #guile?
<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.
<guix-vits>the third party ones
***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>apteryx: re, did you want to give it a try before i merge?
<civodul>or are you fine with me merging it?
<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>ngz: how would it be used?
<civodul>i'm not fond of Repology
<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>oh right
<civodul>but then no tool can help you choose an arbitrary commit
<ngz>Yet, there's the notion of "latest tag"
<civodul>oh i see
<civodul>perhaps the GitHub API supports that too
<civodul>how did you implement it?
<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>civodul: on the topic of repology, I've been considering adding a generic "updater" that talks to it, or something similar like
<mbakke>the idea being that if it finds a later version, try adjusting the source URI accordingly and see if it downloads
<mbakke>as a kind of "fallback" updater
<raghavgururajan>Hello Guix!
<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>`asd` files).
<katco>i guess i should have put recent in quotes :)
<mbakke>sneek: seen glv?
<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).
<morgansmith>tried both of those things too, nothing changed
<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
<simonsouth>Oh, right. That could be.
<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?
<morgansmith> ((#:emacs emacs ''()) `,emacs-native-comp)))))
<simonsouth>Dunno. That looks odd.
<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>oh ok. Thanks :)
<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>(re 45253)
<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, agent been running well now
<cbaines>dftxbs3e, that's good :)
<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>I'll try to do it
<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>cbaines, I also enabled 1G of zram yes!
<dftxbs3e>(compressed swap)
<cbaines>OK :)
<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
<dftxbs3e>lfam, I don't think like this :-)
<lfam>That's okay :)
<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..
<dftxbs3e> *
<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
<lfam>No, it doesn't
<dftxbs3e>marusich, hello!!
<marusich>guix pull succeeded, so I am cross-building the powerpc64-linux-gnu bootstrap-tarballs on both VMs you made available to me.
<marusich>I imagine it'll take a few hours.
<dftxbs3e>marusich, :-D
<dftxbs3e>I saw
<cbaines>dftxbs3e, this commit might help with #45294
<dftxbs3e>cbaines, I see thanks. But since it's stuck, how do you even use that commit?
<lfam>`guix pull`
<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
<dftxbs3e>lfam, I already run guix pull :-P
<lfam>And you still experience the bug?
<dftxbs3e>Yes, but I'll try around more.
<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>I see
<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
<lfam>It's just human nature
<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>Grr is so slow
<dftxbs3e>cbaines, where can we see live build results for your guix build coordinator instance?
<cbaines>dftxbs3e, there's this page
<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
<cbaines>there's also the Grafana dashboard
<lfam>I'm curious, are you in the Americas, dftxbs3e?
<lfam>I am, so I always noticed this fast connection to Norway
<dftxbs3e>lfam, France!
<dftxbs3e>cbaines, Thanks! Pending 197227 aaah!!
<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
<dftxbs3e>lfam, random would be much better!
<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
<dftxbs3e>cbaines, okay :-)
<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 CDN, relaly
<mbakke>heh, 'CONFIG_CC_VERSION_TEXT="gcc (Debian 8.3.0-6) 8.3.0"'
<lfam>Yeah :/
<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
<marusich>do you have a power laptop?
<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
<marusich>Ah, I see
<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 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
<dftxbs3e>It's 82 KiB/s for me
<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> uses a CDN, which should provide optimal performance
<mbakke>yes, definitively
<mbakke>many of our mirror lists are outdated, I recently updated the imagemagick one
<mbakke>hm, cuirass is struggling with 'staging':
<lfam>Yes :/
<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
<lfam>cbaines: Something I'm wondering is, does the info on <> correspond to work performed on berlin? Or is it a different build farm?
<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, does know about, but the information isn't really up to date
<lfam>I see
<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>So, GBC can do this
<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 <>, 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.
<lfam>Yes, I understand that
<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
<cbaines>With the caveat that the Guix Data Service's information about substitute availablity and builds is often very out of date, the Guix Data Service is capable of telling you the substitute availability for a branch, staging for example
<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
<lfam>Can you tell me how to reach that 'package-substitute-availability' from the <> home-page?
<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"
<lfam>I understand being wary
<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
<lfam>cbaines: Should I push directly to Savannah, or should I submit my change somewhere? The patch is here: <>
<cbaines>lfam, there's a separate string for the base datetime that you probably want to change too
<cbaines>but yeah, just push to Savannah
<lfam>Oh, right
<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>Oh never mind
<lfam>I think I can figure it out based on the URL for maintenance.git
<cbaines>Yeah, they should be consistent ssh://
<lfam>That's funny, I ended up with <ssh://>
<lfam>Whereas for the main repo, I have <ssh://>
*lfam shrug
<cbaines>providing you get to the right IP, I think it's fine :)
*lfam /afk