<shcv>nckx: how hard would it be to add a hook to exec? most programs are invoked that way as a string, right?
<shcv>guix pack -f docker is what I tried, but it includes gcc for my python package...
<nckx>shcv: We'd basically have to hijack every attempt to exec a non-existent file, and instead exec a Guix helper that prompts the user interactively, the execs the actual binary. There are many ways this could fail (in a pipe, programmes probing for lots of stuff, ...), and it couldn't affect the current environment, only the spawned process.
<roptat>mh... my python changes are definitely core-updates material... it changes some of the bootstrap ^^'
<zimoun>nckx, philosophical discussion? :-p The bug report points somehow that the make-flags in vim have to be compatible with the make-flags in vim-full. If not, vim-full can break. Hence the comment. Really, I thought the comment was helpful. If it appears to you not, feel free to remove. I do not have a real opinion. I mean it is a «trivial» change. :-)
<lle-bout>vv222: Format is called "nar", look it up in the GNU Guix manual, not sure it's actually documented in detail but there's always Scheme code heh..
<vv222>I’m working on a packages generator, and have been thinking about adding support for GNU Guix.
<cbaines>lle-bout, the guix substitute script does things like re-using connections to make requests faster, but that doesn't work in the guix-build-coordinator-agent as the code isn't thread safe (it's not meant to be as the guix substitute script doesn't use threads)
<lle-bout>vv222: ah well! You want to create binary packages for GNU Guix? I don't think this fits GNU Guix model well, "nars" are not made to be distributed standalone. GNU Guix will only substitute a package definition which includes source etc.. to a nar if it exists otherwise build it itself.
<vv222>So it’s about building locally a package from some game you own in a non-Linux-friendly format.
<lispmacs[work]>has ungoogled-chromium been built successfully for x86 32 bit? How do I check that?
<lispmacs[work]>It seems that there is not a substitute so I'm wondering how many hours this will take before it fails
<lle-bout>vv222: I don't think GNU Guix is a good target for that.
<vv222>lle-bout, technically (hard to work with), or philosophically (no non-free software allowed)?
<lle-bout>vv222: GNU Guix is specially designed to always grow things from source, so actually packaging nonfree "binaries" is unnecessarily hard in GNU Guix, so that's why I said it's not really great to use GNU Guix for that.
<lle-bout>vv222: GNU Guix upstream is of course not interested in supporting nonfree software use cases either.
<vv222>I get it, we got a lot of issues with Gentoo support, probably for similar reasons.
<lle-bout>vv222: It's possible to exercise software freedom through GNU Guix channels to extend it without having to do anything upstream though.
<vv222>It started as a .deb only project, mostly targeted at people keeping a Linux/Windows dual-boot only for games.
<vv222>But we’ve been adding the ability to produce other packages formats over the years.
<vv222>Now I’m mostly looking at new formats we could support.
<vv222>If GNU Guix is mostly centered around local installations from source, I might keep that format for a later. There are still several low-hanging fruits to pick first ;)
<lle-bout>vv222: and to respond to the initial question, both (hard & politically undesired).
<vv222>Yes, that’s what I got from your previous answers ;)
<lispmacs[work]>heck, this laptop probably doesn't have enough ram to build ungoogled-chromium. I'll try one of those lightweight web browsers...
<cbaines>lle-bout, before the Guix Build Coordinator agent was using code meant for the guix substitute script, and doing so prevented doing things like caching connections. But now the code used by the agent has been separated out, it's feasible to look at making things faster and more reliable in the agent.
<lle-bout>cbaines: why can 'guix' itself cache connections and not you even with the old code? That's what I don't understand :-S - Sorry, maybe I don't need to understand.
<lispmacs[work]>lle-bout: I'm a little nervous about bringing in 80 gnome dependencies. I'll try midori first, I recall trying that once in the past
<cbaines>lle-bout, there's no need for thread specific connection caching in Guix (yet), but now the code is such that it can be added to the Guix Build Coordinator, Guix or both
<lle-bout>cbaines: why does the agent need multiple threads exactly? Since most of it is I/O bound, can't it use guile-fibers or something, even on a single thread and be fast enough when it comes to queries left and right (not builds)?
<cbaines>lle-bout, the agent does some things, like compressing outputs which can block for a while as well, so a thread per build works well in that case as well
<lle-bout>cbaines: I see, well guess it's not so easy to model these async+sync interactions in GNU Guile yet that just using threads is easier. In Rust for example I am used to having asynchronous runtimes that can defer blocking code to a pool of worker threads and asynchronous code can wait for results of the blocking code running on these worker threads (not blocking the event loop).
<cbaines>lle-bout, that sounds quite like what I've done with guile fibers in a few places, I don't think the Guix Build Coordinator isn't complicated enough benefit from that kind of architecture though
<Whyvn>ah, its menu-entires, and then a list of menu-entry
***apteryx is now known as Guest69784
***apteryx_ is now known as apteryx
***fossguy[m]11 is now known as fossguy[m]111
***amfl_ is now known as amfl
<davidl>Hello guix! I have a feature suggestion that may have been brought up before: how about creating a guix system reconfigure --save-fs-state available for btrfs (and zfs) filesystem options. I just found a detailed guide for using pivot_root to shrink a ext4 filesystem live on Centos7, and believe it can be helpful to implement a transactional disk-state feature in Guix.
<davidl>say you btrfs snapshot a read-write of current root somewhere, now you need to pivot_root into it without rebooting at the end of the guix system reconfigure command, and save that state in guix system transaction history so you can roll-back to it later.
<nckx>davidl: ‘Ensure the system is in a stable state’, ‘Unmount all unused filesystems’?
<davidl>@nckx: yeah Im not sure all information applies and that the feature would be workable in all scenarios but I think the answer in the link can give a good start.
<nckx>‘state in guix system transaction history’ is what's unclear to me.
<davidl>@ncks: if you run guix system list-generations it could list which root filesystem is related by say a btrfs subvolid, and then that can be used to pivot_root back to it if you run say guix system roll-back N.
<nckx>davidl: I did read the answer, and kept trying to insert possible Guix features at certain points, but apart from a Shepherd ‘save/reload service state snapshot’ didn't find a place to do so.
<nckx>You're right: ‘W3C members took a renewed interest in Tidy in 2011 and forked the project to github (now redirects to new maintainers), where it featured compatibility with HTML5 via a key contribution from one of the SourceForge key members.’
<nckx>Did they also relicence it our is one of our licence fields wrong?
<avalenn>I just wanted to install it. And wondered about which one to choose.
<nckx>Maybe we should hide it (allowing it to remain in Guix but not show up in the UI).
<avalenn>License seem to always have been MIT and not X11, at least since first CVS commit.
<avalenn>I'll drop it here. Just wanted to reindent an html file ;-)
<apfel>hm, in my cuirass setup, when i click on the 'raw' link of a build i do not see the logfile, but something like "Resource not found: /build/5/log/raw". This directory does not exist, which makes sense because the document root of cuirass-web is read only, stored somewhere in the store. It seems i missed something in the configuration. But what? Any ideas?
<apfel>ok, examining the postgresql db cuirass is using. Every build which does have a logfile in the databse does not show up in the gui. All those builds which lack the logfile string do show up ... 'select log from builds where id = <build-id>;', i guess this is a job for the mailing list rather the irc :D
<ison>roptat: I've been getting that issue on icecat as well, I've tried everything to fix it including fixing the timezone (which is normally utc on icecat) but nothing works. So I just started using nyxt for gitlab instead as it seems to pass the test.
<lambdanon>Hi, I'm trying to get a DE other than GNOME on my box, but every time I lock any other DE, the locker get stuck in an infinite loop
<lambdanon>Other people added (screen-locker-service xscreensaver) into their services declaration but I still got the same problem even after I added that
<jorts>ison: Me too, the easiest solution was to stop visiting GitLab. Annoying because some Guix packages are still hosted there.
<lambdanon>going to move back to GNOME. I've gotten used to it now
<pretzel>Hi. I have a module describing about 2000 packages. ".drv" building fails due to "Too many heap sections". The module is too large, I guess. Hence, (reluctantly) considering a split into several modules. Would you expect that to help? Thanks.
<roptat>a possibility is that you have a dependency loop in your packages
<pretzel>Good point, thanks. I had the silly thought that loops wouldn't be an issue if everything resides in the same module (not sure why). Is there by chance a way to plot the dependency graph of a module?
<pretzel>mdevos: Assume that I have no idea what I am doing. I'm playing around with a custom channel; defined some packages; tried to pull my channel; received an error. (No modified guix tree, not sure how to combine pre-inst-env with a new channel.)
<rotty>hmm, this is qemu (via libvirt/virt-manager)
<nckx>edgarvincent: By the way, the (After System Installation) part of the commit message is the name of the ‘node’, which you can find by searching backwards from your change for "@node".
<lle-bout>civodul: hello! what do you think about explicitly supporting specific configurations security-wise? As-in, an operating system manifest where all packages it depends on are explicitly checked and updated for security quickly? It would help me focus because there's just so much right now..
<civodul>lle-bout: i agree with what rekado_ wrote; in practice, high-profile packages tend to be patched more quickly because more people care about them
<cbaines>lle-bout, I'd like to see something similar to the Guix Data Service for looking at security issues in software packaged for Guix, that would at least make it easier to work out what is going on
<civodul>cbaines: that could be "guix lint -c cve" or an HTML-rendered version thereof, WDYT?
<vagrantc>figuring out a core set of functionality would be nice ... i get the impression nix has a core built-in package set and then a separate repository with other packages ... i guess there are reasons that's hard to do with guix, though?
<lle-bout>civodul: yes, HTML rendered or Emacs UI for '$ guix lint -c cve'
<vagrantc>though i would think you can find the input/dependency graph for a few key packages and focus on that
<vagrantc>to get a rough idea of what is the core package set
<cbaines>civodul, yeah, the CVE linter is an approach, although with the aim of understanding what's going on with all Guix patches, I think trying to merge the CVE data in with the Guix Data Service data on packages and revisions might be more useful
<cbaines>I think that would provide the information to answer such questions as "does this channel commit provide a package vulnerable to this CVE" for example
<Gooberpatrol66>I think I just screwed up my guix install by running sudo -E guix pull
<civodul>cbaines: ah yes, having CVE data part of the Data Service would be great; though it's volatile data and needs to be constantly refreshed
<civodul>but yeah, if we could show CVEs fixed/introduced at each revision, that'd be perfect
<lle-bout>civodul: if CVE databases are synchronized offline then html page is the result of guix lint (a bit faster than currently..)?
***rekado_ is now known as rekado
<cbaines>civodul, indeed. There's some tricky design decisions about what the Guix Data Service should do and shouldn't do, but it's not something I'm ruling out adding, there's already substitute availability data which is changable and not handled very well.
<vagrantc>would you have the parse the commit log for something like Fixes: CVE-XXX ... or just rely on upstream version data and ignore something where a patch was added to an old version?
<civodul>vagrantc: i guess it'd use (guix cve) to query the list of CVEs that apply to a given package
<lle-bout>civodul, cbaines: we need cpe data everywhere first, havent had time to study the cpe suggest code yet..
<vagrantc>civodul: but how does that know that when it is fixed upstream in version 1.2.x and 2.0.x but guix has it fixed in 1.2.x-1+patches and 2.0.x-1+patches ?
<cbaines>lle-bout, one thing I've had in mind for the Guix Data Service for years is to try and join up identifiers (directory.fsf.org, Wikipedia, ...), although that might involve trying to get the relevant data in to the Guix package definitions of course
<lle-bout>vagrantc: there's an ignore CVE lint property