<ryanprior>I just found the Guix Potluck discussion and I'm glad because I was about to write up some ideas along those lines (but would not have been able to create a working prototype so quickly)
<ryanprior>The Q in my mind has been: how can I include a Guix packages in the source code repo for a project I'm working on? What would that look like and how could we make it easy for people to consume?
<ryanprior>Potluck sounds like it will provide nice answers to all that.
<apteryx>ryanprior: aren't Guix channels providing what you need?
<ryanprior>Nope, I wouldn't want to ask anybody to add my repo as a channel to try out my package, since channels can basically execute arbitrary code.
<ryanprior>Potluck packages are sandboxed, so the stakes are lower for trying one out.
<ryanprior>Also, if you did add a GitHub repo as a channel just to get that one package, I think the package file itself would have to be stored outside the repo, or somehow inside the .git folder, or something? Because otherwise how would you provide a hash for a repo that contains a file with the repo's hash in it?
<ryanprior>You'd need some kind of escape valve from that hash paradox, which Potluck also provides.
<nckx>That's not strictly necessary. Channels can point to any git ref, such as branches (‘master’) or tags. Your ‘guix’ channel points to master, whatever it happens to be at that time. An upstream guixfile could do the same. But I agree it's not suitable for the RCE reason.
<apteryx>I'm not familiar with potluck, I didn't know it had a sandbox feature planned.
<kamil_>mbakke, I'm sorry to bother you, but do you know how can I scan the currently installed version of the kernel for CVE's? I've booted into an older deployment running the 5.4.31, and `$ guix lint -c cve email@example.com` fetches the list of CVEs for the 5.4.41; is there a way around it? `$ guix lint -c cve firstname.lastname@example.org` is telling me that there's no package for that version.
<mbakke>kamil_: I think you'll have to use the time machine, i.e. 'guix time-machine --commit=abc123 -- lint -c cve email@example.com'
<kamil_>mbakke, I'll try this out, and report back
<mbakke>kamil_: you may also be able to call (@ (guix lint) check-vulnerabilities) directly in your system configuration, i.e. (define kernel (lookup-inferior-packages ...)) (check-vulnerabilities kernel))
<mbakke>kamil_: did you use the same commit as your inferioR?
<kamil_>Oh, I haven't configure one. Like I've said, I just booted into an older deployment that has the 5.4.31. If an inferior is required for this to work, I'll configure it right away to the best of my abilities
<mbakke>kamil_: 'guix time-machine' and inferiors use the same mechanism: they pull an older guix revision and lets you interact with packages from that revision
<mbakke>so if you can identify a commit that has the 5.4.31 kernel, you should be able to lint it with time-machine
<xelxebar>Kind of surprising that git tags don't work for --commit options. I'd have expected that the revision-resolution would just be punted off to git, that way the revision specifications could be denoted any which way.
<pkill9>the guix repo only has a very few tags, that's probably why it's not been implemented
<pkill9>the --with-commit flag for packages takes git tags
***catonano_ is now known as catonano
***jonsger1 is now known as jonsger
<pkill9>I tested using emoji to define a variable in Guile, and it worked, so I propose we use emoji for variables that reflect how we feel about guix
<srandom>Except for some embedded Linux and Android, user namespaces will be cut out because they are almost unused.
<kmicu>cbaines: if we want to be precize then we need to qualify ‘Expat as defined by FSF’, Mit as defined by SPDX, Mit as defined by Github, Mit as defined by OSI, and so on. In practice we see again and again folks popup here asking where’s Mit (Expat). We will see that more and more because of SPDX. So Guix can follow naming scheme defined by FSF or alias Expat as MIT to help folks searching for Mit.
<cbaines>kmicu, the license record in Guix includes a URI, and it should be possible to interpret that unambigiously
<cbaines>In some ways, I'm quite glad that guix packages just list the relevant licenses though, and that I don't have to set out something like that though...
<cbaines>Funnily enough, Debian also uses Expat as a unambiguous short name for a license
<kmicu>For me that’s non‑issue because I know what to do but at the same time I recognize that Expat thing is an unnecessary obstacle for younger newcomers. MIT‑like proliferation is not a thing in 2020, today Expat = Mit.
<cbaines>I too recognise that determining what licenses to put for a package when sending patches could be an obstacle, although I think it's a very important part of packaging something for Guix. Especially determining if the software is free, and what the licensing nature is.
<cbaines>Maybe the best place to help would be the documentation in this specific area. There it could be mentioned that Expat is the unambiguous name Guix uses for the most popular MIT license, with this text.
<srandom>I am modifying gnu/packages/rust.scm under the guix source code to support the new rust. I use guix pull to apply my new source code and test to build it. But a lot of time is wasted on building guix, is there any way to modify gnu/packages/rust.scm quickly?
<kmicu>It’s not about determining the license it’s about the majority of the world using ‘Mit’ word for ‘Expat’, Emacs using frame for window, and so on. That’s outdated nomenclature.
<cbaines>srandom, using the ./pre-inst-env script should help. Have you gone through the ./configure && make process?
<cbaines>kmicu, just because something is popular, doesn't necessarily mean any other approaches are outdated or necessarily less correct.
<kmicu>Fun fact, even licensing lawyers use term ‘mit’, not ‘expat’.
<janneke>kmicu: some may, some may not, in certain situations
<cbaines>I'm not a lawyer, but my impression is that lots of law is about trying to unambiguously see things in context, so you'd always define even common terms.
<kmicu>We should always read the license text. The issue is almost everyone call Expat text ‘Mit’ or a frame concept as ‘window’. I can keep calling windows as frames and use Expat. I don’t mind. Just, personally, don’t see the trade‑off worth it and I will not tell others their usage of ‘mit’ is wrong.
<cbaines>At least in the context of packaging for Guix, I don't think there's a reason to tell people that their usage of 'MIT' is wrong, just that in the context of licenses in Guix, the identifier expat is used for that particular license text.
<cbaines>and I'm guessing that this could be handled better through some documentation, to help those writing packages for the first time.
*kmicu would change Expat name to “Expat (MIT by SPDX)” to make it searchable and silence folks asking ‘where’s the meat‽’.
<jonsger>is it possible to use udev-rules without defining them as variables first?
<kmicu>(or even add spdx field to license record if that’s not costly because even EU uses SPDX)
<PotentialUser-95>nckx: This quote "Suggestions and contributions toward working toward a satisfactory custom initrd and kernel are welcome!"
<mbakke>rndd: I was hoping you were making a similar setup for Guix ;-)
<rndd>mbakke: so, you are interested in erasing your darlings? I appreciate it
<mbakke>I'm not happy about all the state on my Guix systems, that's for sure.
<mbakke>though I'm too attached for such a setup right now :P
<nckx>PotentialUser-95: There's something of a consensus that ‘make-linux-libre’ isn't a good API for users. Same probably goes for the initrd generation.
<nckx>If ‘wet paint’ means ‘this isn't a user API and may break at any moment’, then yes.
<nckx>There is no stable ‘make me custom a kernel’ interface that doesn't require keeping an eye on which phases linux-libre has, & which phases linux-module-build-system blindly assumes a kernel package provides.
<nckx>I realise I'm being a bit vague here but that's because I haven't used make-linux-libre for years which probably proves the point.
<kamil_>mbakke, hi! I've been waiting to tell you that I can't fill a bug report against 'guix system describe' at the moment. I don't have a public email address for this purpose for now.
<rndd>mbakke: i like to put important things in ~/personal then making an archive wich i put on my external drive.
<PotentialUser-95>nckx: I'm entirely unfamiliar with linux-libre. Does it respect the vanilla-linux CONFIG_INITRAMFS_SOURCE?
<mbakke>kamil_: oh OK, I can file one later then :)
<PotentialUser-95>nckx: I'm puzzled because 1) if it does initramfs builds should work - so the quote has me worried. 2) It is an easy way to add prop or gnu incompatible apps.
<nckx>PotentialUser-95: Not one bit. It takes various (statically linked) packages as inputs to create the early user space, and a kernel from which to copy a known list of modules (and their dependency closure).
<nckx>PotentialUser-95: No, Guix builds them for you. The Linux-Libre project releases ‘deblobbing scripts’ that run on the mainline sources. The code above downloads Linux, then applies the freedom, all using Guix on your machine.
<reepca`>is guile's gc smart enough to not collect foreign pointer objects when only the result of pointer-address is still live?
<nckx>I think the Linux-Libre project also releases pre-deblobbed tarballs but we don't use them.
<nckx>PotentialUser-95: If you can read Scheme at all I'd recommend reading that file first. Maybe even if you can't — the comments and structure still explain how things happen.
<nckx>Mh, one more thing: I know far too much about how Guix builds kernels (mainly forced to become so 🙂) but don't know much about the *default* kernel. Some people who do don't frequent IRC, so you might want to ask guix-devel@. Also easier to ask & respond in-depth there.
<PotentialUser-95>nckx: thanks for the pointer to the linux package build 'script' that shed some light. AFAICT it generates a default config `(invoke "make" defconfig)` I'm not familiar with Guile or the others parts so it looks like it could still unset CONFIG_INITRAMFS_SOURCE but it would be a strange thing to do - IMO.
<PotentialUser-95>General question - not linux-kernel related: One approach I had in mind was to try setup reusable config elements/fragments for a package definition. Are there any exampley in the guix package world of how this is best done?
<anadon>My (worthless) opinion is that when upstream drops python 2 support, we drop python 2 support.
<nckx>emys: There's a ‘decision’ in the sense that things are moving to Python 3, and we'll drop broken or unused Python 2 dependencies while we upgrade them naturally.
<nckx>There will be no great rending of python2- packages any time soon.
<emys>so, setuptools is an example, its kind of part of any python buidl chain
<apteryx>emys: I think the concensus was that as long as they don't contain known vulnerabilities, there's no rush to purge them from the tree. But of course where possible we migrate dependencies to Python 3.
<rekado>ryanprior: does the container format allow us to specify a timestamp? Or is the mtime what’s important?
<emys>I am currently packaging a few python packages that need a more recent setuptools release
<nckx>Yeah, what anadon says, with upstream being the projects, not ‘Python upstream’. I'm sure there will be security patches for Python 2 for many years to come.
<emys>I might want to prepare a patch for (b), as a means for discussion as it isn't terribly invasive
<apteryx>emys: b sounds the most reasonable for now
<nckx>The nice thing about Guix is we can micro-manage our dependency graph and work package by package if needs be. I'm not sure if any of those options are better than ‘package the new setuptools, use it in your new packages, move others to it on a case-by-oh-it-works basis’.
<apteryx>but isn't setuptools shipped with Python 3?
<rekado>ryanprior: looks like the oci image spec defines an attribute org.opencontainers.image.created
<nckx>Setuptools shouldn't(™) lead to propagation hell, I think?
<ryanprior>rekado: cool, I've been looking in hopes of finding something like that
<ryanprior>If we adopt that we can hopefully maintain real creation times while keeping images byte-for-byte reproducible?
<emys>apteryx, typically distutils is shipped by python, setuptools builds on top of it, it might be distributed with python, but we always install the most recent one into the virtual environment
<rekado>there’s also a history section in the JSON file format that allows us to store a datestamp and a notice on how it was created
<rekado>we could even include guix describe output and the like
<emys>apteryx, that is at least in typical python+virtualenv setups on debian/centos/rhel
<emys>nckx, what exactly do you mean by propagation hell?
<nckx>emys: That different Python packages in the same profile would propagate incompatible versions of the same dependency. This is more common in Python than other languages because our Python packages rely so heavily on propagation.
<nckx>Setuptools being a (mostly?) build-time-only dependency means it's not normally propagated and avoids that ickiness.
<apteryx>that is the setuptools shipped with Python 3.8.2, a fairly recent release.
<emys>nckx, (version "41.0.1") is declared in python-xyz.scm
<apteryx>I doubt your packages need anything newer.
<nckx>I'm talking only about Guix packaging, by the way, not Python-only things like virtualenvs.
<ryanprior>I was walking a friend through some dev workflows using guix yesterday and he suggested that `guix environment --wach-manifest=m.scm -- cmd` should kill cmd, rebuild profile, and run cmd again on changes to the manifest.
<ryanprior>nckx: one could definitely do that with inotify, watchman, something like that, no doubt. It does seem like a pretty natural extension of `guix environment -m` though, and hopefully not hard to implement as long as there's already a file watcher API in Guile.
<emys>apteryx, its newer and I guess that's how I got the impression we were running on an old version, at least I am glad I can propose my packages for inclusion without having to bump a central package like setuptools, will simplify testing by a lot
<ryanprior>I'm also wanting a `guix alias` like `git alias` so that I can `guix e` instead of typing out environment. Of course I can also do that with Unix® philosophy™ tooling and maybe I should.
<ryanprior>But if `guix alias` were A Thing, then I could tell people "you can run guix alias boom one liner" instead of "here's how you set up a script to handle custom aliases and configure your shell to prefer that etc etc"
<nckx>I guess the difference is: I don't see how it's natural or even an extension at all. Quite the opposite, feels very un- 😛
<ryanprior>Okay, that's fair, my appeal to nature is totally dependent on what seems natural to my frame of reference.
<nckx>One can turn everything into a one-liner with lots of code behind the scenes but this one seems very specific to one very particual use-case, and very brutish (while :; do watch; kill cmd && cmd; done). Then comes, what, --kill-signal=? I dunno..
<nckx>Just dumping my thoughts before going AFK, don't intend to come on too strong.
<ryanprior>What I perhaps should have said is more like "when I run `guix environment -m my.scm -- cmd` I'm signaling an intent for cmd to run in the context of my.scm, which might change, in which case I'd like to also be able to have it follow automatically.
<pkill9>ok, here's something that would be sweet, if you run a command in the shell - including in a chain of pipes - if any of the commands don't exist, guix automaticlaly puts you into a guix environment with the packages providing those binaries, and then runs the shell command
<ryanprior>No worries nckx I always appreciate your feedback!
<pkill9>or, it automatically installs them to the profile
<apteryx>emys: I'm glad I could simplify your life a bit :-)
<ryanprior>pkill9: incidentally how do I find guix packages that contain a binary with some name?
<emys>can I run guix build for all packages defined in a scm file?
<pkill9>ryanprior: other than searching the store, it's not possible atm
<mbakke>I use LVM for my VMs and make the partitions visible with 'kpartx'
<nckx>pkill9: The really sweet thing is that it wouldn't require explicit Guix support, just a ‘command-not-found’ equivalent. The latter will unlock many cool things.
<emys>apteryx, so without specifying setuptools as a dependency it fails to build because it tries to load setuptools
<nikita`>civodul: okay, I agree, wrt the bug you closed. I was fully aware of how much work this is (I mean I have porting Chromium to an unsupported system on my shelf as well). Probably going to run Linux for my Guix contributions then and pick up work again on my own PM.
<nikita`>ultimately porting would've required some message exchange when I would've gotten to the point of building, but also your support
<nikita`>i could vendor the patches, but let's be honest I don't want another www/chromium with close to 90 patches or what it is now
<alextee[m]>i'm trying to make an omni package for zrythm (music production software), and i have a problem loading plugins. plugins already installed in the user's system fail to load because some .so's they depend on are not found. what's the solution to this? i probably need to append the lib paths of the user's system right?
<alextee[m]>er, by omni package i mean what is produced with `guix pack -RR`
<alextee[m]>i get a nice 250mb thing that seems to mostly work, so i'm impressed
<lfam>I've been working on fixing this with ALSA. It hardcodes a search path at build time that is of course bogus for Guix
<alextee[m]>it's my program so i can edit it to do the right thing! :-)
<lfam>What I'm doing for ALSA is making it honor the environment variable GUIX_ALSA_PLUGIN_DIRS
<alextee[m]>i mean it finds the plugins from user-specified paths, but when you load them it says "failed to find .so" or something like that. so those are .so's loaded from the plugins themselves, after the plugins get loaded with dlopen
<alextee[m]>i think you're describing a problem of not finding plugins, that's probably a different problem
<alextee[m]>failed to find .so of the plugin's dependencies * not the plugin itself
<ryanprior>liberdiko: no mention of guix on that page, only of downloading & intalling crx files =D
<rekado>emysion: here’s an example of how to build all packages defined in (gnu packages statistics): guix build -e "(let ((m (resolve-interface '(gnu packages statistics)))) (module-map (lambda (sym var) (module-ref m sym)) m))"
<anadon>Was reading up on the software heritage features, and changing to VCS allows use of SWH which is in line with this prroject's goals. But it seems too obvious to not have been just done already, so I figured there might be a reason.
<kamil_>Excuse my ignorance, but what does VCS mean?
<anadon>sneek: tell kamil_ VCS -> version control system, like git.
<sneek>kamil_, anadon says: VCS -> version control system, like git.
<anadon>sneek: later tell kamil_ VCS -> version control system, like git.
<anadon>This goes back to the devel thread on which is better -- git-fetch or tarballs.
<anadon>I think we need a resolution on that. Given the SWH integration, and the ultimately greater user freedom and choice, I think we need to have preference for using git-fetch over url-fetch.
<anadon>I want my laptop to be back from repair already. Recompiling is slowwww.
<roptat>you'd buy my vote with a bootstrapping argument, not so much with "user-freedom" (I don't see how it gives more freedom)
<roptat>but I'm not convinced you could build gettext from a CVS checkout, because it would depend on the autotools, and don't they depend on gettext? (I might be wrong)
<anadon>roptat: that would fallback on guix's bootstrapped versions of the tools in the end. And I'd say user freedoms since I'd want to supports user augmented builds and packages to their fullest extent. Being able to pick out bits from other branches would be an example which I would support.
<anadon>The bootstrapping thing was all solved in guix's boot-strapping project early on.
<roptat>anadon, we have --with-git-url and --with-branch