<iyzsong>well, for library packages, the convention is that the main 'out' is for development, and binaries are put into the 'bin' output. i have to agree we lack a tool for search which package provide that file...
<EternalZenith>Ah, I was hopinig there was some undocumented feature of "guix package" that provided that
<nly>I noticed unusually high CPU usage in normal desktop tasks, upto 50% just in just opening the browser. In dmesg I get 'fatal error during GPU init' and some more 'amd gpu...' errors
<g_bor>civodul: it goes like this: postgresql has a few extensions that are packaged. But does not find them, unless we make them available. So roptat implemented an addition to our postgresql service, where you can list packages that are made available to the service. However it would be nice if we could list the packages that make sense in htis context.
<civodul>g_bor: ok i see; it's a fairly common problem i guess, for all services that have plugins or extensions
<civodul>we don't have a good answer yet other than "guix package -s postgresql" i guess
<g_bor>civodul: I see. Maybe we should at least indicate in the description that this is a postgresql extension, should not be installed, but instead provided in the relevant field of the service definition?
<civodul>g_bor: yeah, or just write "this package provides a PostgreSQL extension" or something
<g_bor>or postgresql-extension, so that we can provide a keyword to use with guix package -s?
<g_bor>What I have done so far: set boot to UEFI => that made the UEFI boot options available, including UEFI iSCSI settings. I set that up, so that that device1 had iscsi name, ip, netmask, iscsi gateway. That made the HBA appear in the storage administration interface. Now I am waiting for an admin to insert an install disk locally, so that I can go on.
<jlicht>the thing was that sometimes a Coffeescript feature was introduced in a commit, and already used in the source in that same commit. This happened like 5 times, and I basically had to backport the feature myself without using the feature, if that makes sense
<roptat>the node scripts rebuild the js version everytime you run them, so I guess someone could easily introduce a feature in the compiler, compile it and then use it in compiler code before commiting
<roptat>wouldn't it be simpler to re-implement coffeescript though?
<jlicht> The approach that we now have for bootstraping rust seems to work; cut the dependency graph somewhere by having an alternative implementation with some simplifications, and use that to bootstrap more recent compilers. If something like that happened for coffeescript, it would help