<pkill9>if i get a new phone, I could use this one as a disposable one <shcv>what package do I need to include in a pure environment to get the 'guix' command? <shcv>it was going to download a new substitute, so I didn't think that was it <shcv>I could have misread the message though <roptat>the guix package and the pulled guix use a different mechanism <roptat>also, the guix package is necessarily older than the guix you pulled, because when it was defined, the commit you pulled didn't exist <roptat>so you get a slightly older guix inside the environment <pkill9>I think a tool for running programs sandboxed using guix environments would be the final thing keeping guix super clean <pkill9>actually now I think about it, using containers as profiles would be pretty nice, no need to know where any dotfiles for applications are <shcv>where would you set them though? <shcv>I guess you define your own personal packages for them? <pkill9>there's talk on the mailing list of 'runtime-wrappers', which would be preferable <pkill9>i'd rather not modify the packages <shcv>maybe make a (package my-dotfiles), and then (package my-emacs) with my-dotfiles as an input <pkill9>creating another package as a wrapper <pkill9>since this is mostly for desktop use, I will probably make a launcher <roptat>you could use the guix-home-manager to build something like that :) <roptat>you could use it to build a "home" profile, and run your app inside it <shcv>what's guix-home-manager? <roptat>not sure if that makes real sense <pkill9>roptat: I don't want to specify all the dotfiles though <shcv>sounds a bit more roundabout than guix environment <pkill9>I just want it to dump them wherever it wants inside a contained folder <pkill9>which is easy enough by changing $HOME when running the application <shcv>so, something like docker volumes? <pkill9>though i also want to use guix environments as containers for extra security against bugs/exploits <pkill9>not that i've had a problem with it before <pkill9>makes sense for finding random code online <shcv>how do I get whatever context is necessary to interpret a manifest file? I want to see what it's returning <pkill9>this would be a sweet selling point of guix, inbuilt sandboxing <shcv>it has a lot of that already, but yeah, it could probably be made a little easier to use <pkill9>oh yea, all the functionality is there <shcv>ooh, would be cool to have an interactive environment builder <pkill9>then combined with FHS support, everyone can download all the bloated insecure electron applications to their heart's content <pkill9>though most of those are proprietary <pkill9>but all the other random code from random repositories aroudn the internet <shcv>it wouldn't include anything in the profile by default, but whenever an unknown program is invoked it says "unknown program <x> was requested; would you like to add <probable package>?" <shcv>so you could just "guix sandbox -- sh -c `curl web-script`" without needing to add a long list of packages upfront <shcv>idk; I think we need a list of user stories, and figure out what UX would be the best <nckx>shcv: Some distributions provide a bash hook for that (command-not-found) but how would you catch ‘invoking an unknown program’ everywhere else? <shcv>right now what I want is the ability to build a docker container with just my package and it's runtime dependencies <roptat>there's also guix pack --format=docker <roptat>if you don't want a full system in docker <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. <shcv>I doubt python needs gcc at runtime? <nckx>shcv: What's a ‘hook to exec’? <shcv>roptat: you're right; still confused why my python container is 400MB though... <shcv>nckx: I'm not really sure, but I think most external program invocations are resolved by the kernel by name, not loaded directly as binary <roptat>400MB seems excessive, you have something else in there? <shcv>roptat: is that because glibc? I'm used to using alpine containers, which use musl and end up with a 44MB python container <roptat>you can look at that with "guix size python" <roptat>python itself contributes 79.8MB <roptat>so it's going to be hard to ge below 44MB :p <shcv>it might be a compressed image? <shcv>but that's what docker says is the size of the python:alpine image I just downloaded for reference <nckx>shcv: You mean a binfmt_misc handler? <roptat>well that's possible, maybe we package too much useless stuff in python <nckx>That's the mechanism I'd use anyway. <nckx>But it doesn't really address the above. <roptat>ah, they don't package the *.py files at all <nckx>shcv: Hm, I don't think that could work after all. By the time that gets called, the executable *does* exist. <roptat>fun, we have windows executables in the output of the python package <roptat>I wonder if we bootstrap them? :D <roptat>most likely, we could get rid of them *lle-bout sets up ERC on their laptop because they were RDP'ing into their desktop before to use IRC with Hexchat with the same nick and channel config. (a bit of a sad setup). <nckx>Why... can't you run HexChat on your laptop? <lle-bout>nckx: I could but also want to try to go full-Emacs. My goal is EXWM on Wayland when it works. I don't like Sway after all. <nckx>Another one lost to Emacs. <lle-bout>nckx: Emacs is the only platform that puts keyboard control at it's center and is so diverse, so that's what I find so great about it. <nckx>It's the Lisp machine we deserve. <roptat>er... do we actually install python's own unit tests in the python package? <zimoun>nckx, since you already watched the issue about vim-full, feel free to push patch 46950 fixing it. :-) <nckx>That does not look correct. <nckx>It's fine to put that in the commit message, but not in the code, since that's not what it does. <nckx>zimoun: I'll test & push. <zimoun>nckx, as you want. It appeared to me useful to have a comment explaining why the ’delete’. Anyway, feel free to remove and co-author. :-) <nckx>zimoun: The comment doesn't explain the delete, though. <nckx>Removing the delete will not produce the error mentioned in that bug report. <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. :-) <nckx>I already pushed it. Thanks! <zimoun>nckx, however you are the author and the co-author, hehe! :-) When the gitology is not helpful. ;-) <nckx>That's my fault, I'm sorry. <nckx>For some reason your mail still hasn't arrived and I downloaded the patch from the Web UI, but it wouldn't apply, so I used ‘patch -Np1’ and committed... <zimoun>Hehe, do not worry, it is just funny. :-) <nckx>You can have a patch of mine. <zimoun>what do you mean by my mail hasn’t still arrived? <nckx>I'm not sure yet. mu(4e) has become progressively slower over the past weeks, so I wiped my (2.7G) mailbox and redownloaded it. That fixed some of the slowness but... something's off. <nckx>I just mean in my mailbox, not to the list. <lle-bout>nckx: can I update zstd in core-updates? There's a CVE also, fixed in latest 1.4.9, do I graft that on master? <lle-bout>nckx: CVE-2021-24031 and CVE-2021-24032. <zimoun>nckx, thanks for the help today and the review. Good night! <nckx>Me → 😴 as well. Some sleep will do me good. <nckx>lle-bout: - Yes you can. - You should, unless our build is immune for some reason. <nckx>If I start reading CVEs in bed $partner will be justifiably worried. Good night. <cbaines>I've just pushed a merge of master in to core-updates <lle-bout>cbaines: I noticed maybe guix-build-coordinator system test is failing now? <lle-bout>It would be nice of Mathieu who's working on Cuirass was online a bit more here (even if away, just for pings), easiest way to get messages to someone for me is IRC. <lle-bout>I still need to message them for some Cuirass suggestions. <cbaines>lle-bout, you can always use sneek as an intermediary <cbaines>lle-bout, as for the guix-build-coordinator system test, I think it worked last time I ran it for master. Where did you notice it failing? <cbaines>but it's a substitute time out error: guix substitute: error: connect: Connection timed out <cbaines>so the failure has nothing to do with the test <lle-bout>cbaines: I believed it was due to configuration change maybe you forgot the system test, but nevermind! <lle-bout>cbaines: also I don't understand, substitution appears to be very fast when used with `guix build`, what makes it so slow with guix-build-coordinator-agent? <cbaines>do you mean the checking substitutes are available bit in the guix-build-coordinator-agent? <vv222>Hello World! Does guix come with support for binaries packages, similar to the .deb of Debian or the .pkg.tar.xz of Arch Linux? Or is it only working with sources? <vv222>If it has such packages, where could I find an example to study its format? <vv222>Thanks for the info lle-bout ;) <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>lle-bout, the tricky part is that the software I’m working on is about *non*-redistributable packages ;) <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... <lle-bout>cbaines: I don't understand, what is the difference exactly? <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. <cbaines>lle-bout, because the connection caching assumed only one thread, and the agent uses multiple threads. So if you tried with the old code, you'd get threads fighting over the same connection. <lle-bout>lispmacs[work]: also maybe try GNOME Epiphany / GNOME Web, quite lightweight after all. <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)? <lle-bout>Or delimited continuations (asynchronous code, basically) <cbaines>lle-bout, each build is handled by a thread, guile-fibers isn't great in this case (on the agent) as it doesn't build on the hurd (yet) and guile-fibers still uses threads anyway <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 <cbaines>anyway, now I've done the refactoring, I think I can attempt to make things better in the Guix Build Coordinator agent <cbaines>first though, I'm going to get some sleep, so goodnight! <lle-bout>cbaines: Good night! Thanks for all the awesome work! <pkill9>reminder to all guixers: live a life outside of guix <lle-bout>but..but..but!! There's so many things to do for GNU Guix!! <lispmacs[work]>whoa, whoa, whoa, we can afford to have any more sponges like myself <lle-bout>lispmacs[work]: I use it to find stuff in debbugs :-) <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. <nckx>Hi davidl! What would a ‘transactional disk-state feature in Guix’ look like and how/when would it be used? (I don't understand how it's related to resizing fses at all -- what'm I missing?) <davidl>@nckx: the steps needed to pivot_root on a live and running system happened to be detailed on the first answer there. <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>s/possible/possible new/ <nckx>lle-bout: I just noticed ‘Duration -23804 seconds’. <davidl>@nckx: do you think such a feature is doable or not doable in Guix? <nckx>I think so but I honestly still don't understand its exact nature, davidl. I think I need coffee. <nckx>Why do subvolumes need to be involved at all? (They are, at least on btrfs, simply copies of the directory tree exposed as a directory on the same file system.) <davidl>@nckx, sry Im not writing clearly. Im always in a time-crunch.. :/ I can write more about it later. <nckx>davidl: And I may not be thinking cleary, so we make a great pair. But I look forward to it! <avalenn>what is the difference between tidy and tidy-html packages? <nckx>avalenn: They are different projects, but one (tidy) is very old. Maybe we should hide it: it's still used as an input to other packages, so we can't simply remove it without changing that. <nckx>We don't refuse packages because we have similar packages already in Guix, only if they are obsolete/broken on their own. <nckx>If tidy is still useful today, it can be as old as it likes. <avalenn>Ok. I had the impression that it was the same software, on only being the old and unmaintained source repo. <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? <nckx>‘In 2015 a group of concerned developers, users, and software integrators formed HTACG with the goal of revitalizing Tidy’ - OK, but tidy@5.0.0 was also released in 2015... <nckx>avalenn: Are you looking at the actual sources? (I'm not.) <nckx>They seem to be aiming at a merger too, so maybe it'll sort itself out. <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 ***nckx is now known as jorts
<roptat>I still can't connect to gitlab with icecat <roptat>I tried changing my useragent, but it didn't do anything, I still get the cloudflare loop <GNUtoo>Basically there are rebuilts of the Android SDK and so on <GNUtoo>Since they are built from the AOSP source code it should be way better <GNUtoo>As there are a lot of licenses there might still be some small issues but in Replicant we're not aware of any yet <GNUtoo>The advantage is also that it sticks to the Android API (since it doesn't contain google play stuff) <roptat>well, I know about that one, but that's only the sdk, right? <GNUtoo>So the resulting applications should work out of the box on any Android device, including those not using google play <GNUtoo>That project rebuilds the SDK, emulator, etc <GNUtoo>I'm unsure what IDE to use with that though, it probably need a bit more research or testing to get a drop in replacement <GNUtoo>Though AFAIK it should be able to build Android apps from the command line at least <GNUtoo>btw, thanks a lot for this blog post, as it shows how to use unmodified scripts or build systems <GNUtoo>I guess with enough --expose we could get something closer to standard distros and build Replicant for instance <pkill9>I should get into app development <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? <mdevos>(will likely fail due to dependency loops, though) *mdevos thinks loops should be detected ***jorts is now known as nckx
<pretzel>mdevos: Thanks, but wouldn't that require guix to be aware of the package, i.e., "guix pull" / ".drv" building to succeed? (Which it does not, due to $some_reason.) <mdevos>pretzel: I don't follow, the package graph is known in advance, before building <mdevos>(Perhaps you're in a modified guix git tree and you need to use ./pre-inst-env? ./pre-inst-env guix graph PACKAGE) <mdevos>guix graph ungoogled-chromium returns in seconds, e.g. <mdevos>* ungoogled-chromium -> ungoogled-chromium rust <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.) <mdevos>guix graph --load-path=$CHECKED_OUT_CHANNEL package <mdevos>where CHECKED_OUT_CHANNEL is a git clone of the custom channel <mdevos>See ‘8.1 Package Modules’ in the manual (there's also GUIX_PACKAGE_PATH) *rotty has troubles with networking in the installer -- the gui fails to detect internet access, and the "manual" method always configures a bogus ipv4 link-local route and address: <rotty>this is a VM which _should_ get DHCP via dnsmasq, the wireshark trace looks reasonable, AFAICT <civodul>rotty: hi! the installer just runs a regular DHCP client <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.. <rekado_>lle-bout: security is always a best effort. There cannot be any guarantees. <roptat>kozo[m], are you on a foreign distro? <lle-bout>rekado_: sure but would be nice to be able to patch maximum 2 days after CVEs are out and patches exist. <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 <cbaines>Gooberpatrol66, I believe you've done guix pull for your user, but as root. So there's probably some files owned by root which you'll need to take ownership of. <Gooberpatrol66>Migrating profile generations to '/var/guix/profiles/per-user/nathan'... <Gooberpatrol66>guix pull: error: symlink: File exists: "/var/guix/profiles/per-user/nathan/current-guix" <Gooberpatrol66>chown: changing ownership of '/var/guix/profiles/per-user/nathan/current-guix': Read-only file system <roptat>kozo[m], I don't know how to help you then, it works well on my guix system... <cbaines>Gooberpatrol66, are there any files in /var/guix/profiles/per-user/nathan owned by root? <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.. <lle-bout>for example, I have practical example where guix lint -c cve gets it wrong: GNU Lightning package - it mistakes it for some JavaScript lightning package in the CVE database, GNU Lightning doesnt have a CPE id yet because it didnt get any CVE yet I believe. <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 <lle-bout>vagrantc: (properties `((lint-hidden-cve . ("CVE-2000-1234")))) <Gooberpatrol66>I just rolled-back from the "broken" generation. Is there a way to delete just that generation? <cbaines>Gooberpatrol66, delete the relevant symlink to the store <civodul>lle-bout: hold your horses, we don't need cpe data "everywhere" :-) <cbaines>Gooberpatrol66, I think you can also pass a pattern to guix pull --delete-generations=... <civodul>in many cases the package name is the CPE name <Gooberpatrol66>cbaines: the manual says it deletes anything OLDER than the pattern <kozo[m]>Is there a log file of some sort I can find more info of why my --container is failing in guix environment? <cbaines>kozo[m], do you mean guix environment is failing when run with the --container flag? <lle-bout>civodul: but to be precise, we should be explicit? There's vendor + product? <lle-bout>civodul: you would prefer if we did not add cpe data unless necessary because wrong results? What about GNU Lightning that has isnt present in the cpe database and is being matched wrong? <civodul>lle-bout: the lightning issue is probably because we currently ignore the "vendor" part of CPE, as noted in the bug report <lle-bout>civodul: cpe-vendor doesnt exist right now? <lle-bout>we could at least specify that, when GNU Lightning is added in cpe in the future <kozo[m]>so I'm going through my config to see what could be causing the issue <cbaines>maybe it's a linux version thing, what version of Linux are you running kozo[m] ? It fails for me on 5.11.3 <rekado>this works for me on 5.10.12-gnu <kozo[m]>I've tested 5.11.3, 5.10.16. 5.10.20, currently building 5.10.18 <cbaines>kozo[m], and it failed on all those you've tested? <kozo[m]>Interesting it works for you on 5.10.16 <rekado>also works with Guix at commit 297531ef58ea91d167dac0474d02a538e8e6bc74 <rekado>kozo[m]: what file systems are you using? <kozo[m]>Good question. I see /tmp but I don't see it in blkid or lsblk <kozo[m]>This is a fresh install from yesterday, I did use full disk encryption this time <rekado>FWIW I also use full disk encryption <kozo[m]>I'll keep commenting out stuff until I can figure out what it causing it. Thanks for the help. <rekado>I tried mounting tmpfs onto /tmp and I cannot reproduce the error. <brown121407>Hi! How often is core-updates usually merged into master? <roptat>brown121407, every 6 months, but we're late for this cycle <cbaines>is there a good example of setting a package's supported systems to be "just linux"? It would be good if util-linux didn't claim to support the i586-gnu (I'm guessing it doesn't)? <cbaines>I see (filter (lambda (a) (string-contains a "linux")) %supported-systems)) in a few places <roptat>civodul, I tried setting up a phabricator locally, and it looks nice (since we vaguely talked about it a few days ago) <roptat>I can see how it could be useful to track our goals and progress, though it has much more than we need <lfam>lle-bout: I'm accumulating bug fixes and tidying for an upcoming Guix release on the wip-next-release branch. That's a good place to put ungrafting commits in the next few weeks <lfam>I just ungrafted zstd there <lfam>It's "wip", aka "work in progress", so the branch can be rebased instead of merged until we get closer to the release <lfam>That all depends on solidifying the plan for the release, but at least this is an easy place to collect patches