<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. <rekado>one of the features is resilience against changes in Guix; note that this is also possible with specification->package or the JSON format <kamil_>Is there a way to pin the kernel version, without holding packages back? <kamil_>Don't inferiors pin *all* packages on the system to a certain commit? <mbakke>kamil_: only the packages you specify, i.e. (kernel (lookup-inferior-packages inferior "linux-libre@5.4.3")) <kamil_>mbakke, that's awesome. Thanks a lot! <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 linux-libre@5.4` fetches the list of CVEs for the 5.4.41; is there a way around it? `$ guix lint -c cve linux-libre@5.4.31` 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 linux-libre@5.4' <kamil_>mbakke, I'll try this out, and report back <kamil_>mbakke, Sadly, it doesn't work :( This would go to make a great feature--being able to scan older versions of packages for CVEs <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)) <kamil_>mbakke, 'checking linux-libre@5.4.41 [CVE]...' <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 <kamil_>mbakke, also, what is calling (@ (guix lint) check-vulnerabilities) in a system configuration exactly do? <mbakke>kamil_: you can check /run/current-system/provenance (or guix system describe) to figure out which revision your 5.4.31 kernel was built with <mbakke>kamil_: (check-vulnerabilities PACKAGE) does the same as 'guix lint -c cve package', i.e. print a warning on the console if any vulnerabilities are found <kamil_>I think I see the problem. 'guix describe' prints out the commit of the latest generation, not the one I'm currently booted into. <mbakke>kamil_: indeed, 'guix describe' prints what you have 'guix pull'ed <mbakke>try guix system describe instead :-) <kamil_>oh, I'm sorry, I didn't notice "system" in the command ^^' <kamil_>mbakke, which line do I specifically look for? The `kernel:` one only reveals the location of the kernel package in /gnu/store <mbakke>kamil_: look for the channel that created the system generation <kamil_>'guix system describe' prints out details for the 5th generation, whilst I'm currently on the 1st one. That's odd. <mbakke>oh, it describes the latest generation, not the current :/ <mbakke>kamil_: try 'cat /run/current-system/provenance' instead <raghavgururajan>nckx: Just double-checking if you received corrected message regarding dwm/st. It is only st (0.8.2 to 0.8.3). Thanks! <mbakke>kamil_: can you file a bug about 'guix system describe' not acting on the current generation? <kamil_>mbakke, 'cat /run/current-system/provenance' is only telling me '(provenance (version 0) (channels) (configuation-file "/gnu/store/xxxx-coniguration.scm")) <mbakke>kamil_: oh, I guess that was the very first generation, which was not made after having 'guix pull'ed <mbakke>kamil_: you can use 'guix time-machine --commit=d62c9b2671be55ae0305bebfda17b595f33797f2' in that case which corresponds to the 1.1.0 tag *mbakke -> zzZz, good luck & good night <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 <atw>I feel pretty � about that <ssb>hi! I did "guix system build -r mygcroot myconfig.scm", then "guix gc", but then the same guix system build re-downloaded half of the substitutes again. Is this expected? <anadon>OK, first round of bug spam is done. <srandom>ssb, Suggest guix gc -F size (disk space you need) <pkill9>ssb: i don't think it should have redownloaded the substitutes if you registered a garbage collector root for the guix system build <pkill9>i think guix needs to stop running so many services as root <ssb>srandom, pkill9: thanks, trying to figure out if build deps are kept or how to register them as gc roots ***apteryx is now known as Guest35258
***apteryx_ is now known as apteryx
<rekado_>pkill9: could you please open bug reports for those services you’d like to run as different users? This should be rather easy to fix. <srandom>How should I manually specify the toolchain version used in the build-system in the package definition? <srandom>I am using cargo-build-system to compile a project, but it requires a higher version of the toolchain <alextee[m]>do most popular distros support user namespaces? <emys>hi, I got a quiestion on package (guix licenses), it doesn't contain "MIT" <rekado_>I think they are still disabled by default on Debian and RHEL. <rekado_>emys: it’s likely the Expat license, or possibly the X11 license. <rekado_>(there is no single MIT license, contrary to common belief) <emys>a bit weird to encode it as Expat though when the project declares it as MIT on PyPI <cbaines>It's not really an insistence on Expat, or at least I don't see it as that. Just a preference for unambigious names. <cbaines>As has been said, MIT have used different licenses for software, so there's not one unambiguous MIT license. <kmicu>There’s is nothing ambigious in practice in 2020. Mit is Expat almost always. <srandom>alextee[m], Almost all Linux distributions support user namespaces <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) <emys>I am trying to lint a package definition I have been working on in a separate repo, now I am preparing a patch <emys>./pre-inst-env guix lint --load-path=$PWD python-venusian <emys>Error Throw to key `srfi-34' with args `(#<condition &store-connection-error [file: "/usr/local/var/guix/daemon-socket/socket" errno: 2] 7f737eec7570>)'. <bricewge>emys: Are you using Guix System or a foreign distro? <emys>bricewge, on top of debian-testing <rekado_>emys: you configured without passing localstatedir <rekado_>do “./configure --localstatedir=/var” <bricewge>rekado_: Is it /var on debian too? More broadly is it the most used location on foreign distro? <emys>localstate dir /var worked <jonsger>how do people change their display brightness as non-root user? <rekado_>bricewge: it’s /var because that’s where the Guix database is. <rekado_>when the installer script is used it will also be /var. <rekado_>jonsger: I’m using GNOME and this used to just work before the core-updates merge. <jonsger>I'm just too stupid to read the archwiki :P <bricewge>jonsger: I use brightnessctl. Which kind of screen do you need to dimexternal or built-in? <sammich><jonsger "how do people change their displ"> I use light and added a udev rule to chown /sys/class/backlight/.../brightness to use hte video group <bricewge>jonsger: Just add to your service (udev-rules-service 'backlight brightnessctl #:groups '("video" "input")) and add yourself to the groups. <bricewge>If you want to control an external monitor you'll just need to load the kernel module ddcci-driver-linux, and it'll appear in the same class that amk talked about <janneke>jonsger: that's helping -- i've been doing that manually :-/ <emys>can debuggs deal with patches sent in multiple mails? like sendmail does using [PATCH ...] indices? <emys>like I have 2 commits I want to contribute <emys>and would like to submit them using git send-email <emys>and when I sent it as a test run tomyself there are 3 mails (cover letter, patch 1 and patch 2) <emys>and I wondered if this is ok for the patch mailing list <cbaines>emys, once you've got a bug number, you can use git send-email to send to that bug <cbaines>emys, at least the way I normally do it is manually send the cover letter to guix-patches@gnu.org <cbaines>then use git send-email to send to XXXXX@debbugs.gnu.org, where XXXXX is the bug number <emys>aha, do you use git send-email to send the first mail then / coverletter only? <cbaines>no, I just normally copy the cover letter in to my mail client and send it from there <reepca`>so open-pipe* unconditionally closes all but the three main file descriptors -.- <cbaines>reepca`, is this in relation to the Guile Guix daemon? <reepca`>gotta get a thread-safe way to start child processes, for builders <cbaines>is that a child process of the daemon, or the process to actually do the build? <reepca`>process to actually do the build. Only other child processes AFAIK would be substituters and offloaders <cbaines>right, and what's the issue with thread safety? <reepca`>the issue is that forking in a multi-threaded program means the child can only use async-safe functions until the exec <reepca`>and that's not something we can really control from guile very easily <reepca`>and it kinda wrecks our call-with-container interface <reepca`>the plan currently is to replace it with / add eval-with-container instead, which is decidedly less pleasant, but can pass an sexp to be evaluated to a child guile process <cbaines>that was my attempt to make it possible to do channel/inferior stuff with the inferior process running in a "container" <cbaines>and what's the plan regarding using threads in the daemon? Is this instead of having a process per connection like the current implementation? <reepca`>the plan is to use guile-fibers for a hybrid kernel/user thread approach <reepca`>e.g. 4-core cpu => 4 kernel threads, <number of connections + 1> user threads <cbaines>Right, I do feel for you. I've spent my entire morning fighting with fibers <cbaines>and I think I've only just got the upper hand <reepca`>aye, I've spent quite a bit of time reviewing the 1.0.0 code <reepca`>I must say #:drain? is rather misleading <reepca`>turns out it only considers the "main" scheduler when deciding whether there's pending work <reepca`>so if you do (run-fibers (lambda () (spawn-fiber (lambda () (display "hi!\n")) #:parallel? #t)) #:drain? #t), you'll only see the output sometimes <cbaines>my struggle this morning has been about how to run two fibers web servers in one process <Shufei>Howdy do. Is anyone around for a quick help please? <cbaines>I don't know, but I'd say what you'd like help with at least <Shufei>Getting error : “Git error: ssl error: received early EOF” when doing a Guix pull. <Shufei>It will pull for a while and then just stop. <srandom>You can use git to manually pull to the local and then guix pull --url=/path/to/guix <cbaines>Is this the first time you've run guix pull as this user? <Shufei>I’m a total newbie I’m afraid. It’s a personal compy, Guix on top of Debian. <Shufei>Oh, thanks heaps, that is nice I shall try a mirror or local. <cbaines>I'd recommend trying to get to the bottom of why guix pull isn't working <cbaines>I don't think there's any issue with the authoritative Git repository at the moment <Shufei>I do have rather slow internet, so it can cause such issues with git and curl and such. I’m hoping that is it. <cbaines>The repository is rather large, so it could be that for the first guix pull, it might take a few tries <cbaines>Once it's worked once though, the repository is cached, so it shouldn't take as long afterwards <Shufei>Hehe, yes, it is taking time, but I’m patient. <cbaines>I wonder if it would be possible to do a shallow clone to populate the cached checkout initially... <Shufei>How would I set it to shallow under Guix? Same syntax as straight up git? <cbaines>I don't think that's an option at the moment <cbaines>I was just wondering if it was a possibility though... <Shufei>Hum, I shall keep abreast then, if this doesn’t work. It’s still slowly pulling, reeeeling it in. <jonsger>do we have a PDF viewer supporting formulars? I know of okular, but that is missing from Guix <cbaines>Shufei, what do you see if you run ls .cache/guix/checkouts/ <cbaines>or rather ls ~/.cache/guix/checkouts/ ***Shufei_ is now known as Shufei
<mbakke>jonsger: I have a patch for Okular somewhere if you want to try it. <cbaines>Shufei, well, that's where the repository should appear once it exists <Shufei>Hum... Rebooting for luck, will give it a go again then file a forum post on shallow pull. <nckx>Welcome, Shufei. Guix over slow/unreliable networks is… still much more fragile than it should be. Sorry about that. <rndd>hi everyone! is it possible to delete my user home directory and recreate it? <Shufei>Haha, no worries, it’s a brave new world for me, and so far I love the idea. <rndd>so, all junk will be erased <nckx>rndd: Guix is fine with that & will re-create it at activation (boot) time unless there are any uncaught bugs. I'm less sure old man unix will let you do it while the system's running. *nckx not going to try this one out. <rndd>nckx: so, you mean, i can simply rm -rf ~/ then reboot and ~/ will be created? <nckx>That's what should happen. <nckx>Heh. No promises, but the code is there. <janneke>rndd: any good stuff would also be erased... <PotentialUser-95>Hi I've just become aware of guix and wonder if I can pose a few questions about the possible use case - building linux-kernels <rndd>janneke: everything sould be burned <nckx>PotentialUser-95: Welcome & ask away (just avoid explicitly proprietary issues). <nckx>I build a kernel with Guix every hour because debugging is fun. <PotentialUser-95>nckx: Great thanks. Both cookbook and blog entry close with a paragraph that makes it sound like initrd builds might be wet-paint. True? <rndd>mbakke: nope. don't look for nixos posts <nckx>PotentialUser-95: Not entirely sure what you mean. <nckx>I don't build my own custom initrd however. <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>AFAIK it doesn't look at .config at all. <PotentialUser-95>nckx: is there a user I can look out for that might know authoritatively? <nckx>I'm not sure if respecting the kernel's CONFIG_INITRAMFS_SOURCE even makes sense. <nckx>(As in: I don't think it does but am willing to be convinced.) <nckx>PotentialUser-95: It's a ‘deblobbed’ version of mainline Linux, without blobs or support to load them. <nckx>It restricts a bit too much at the moment (like loading free firmware) but that's in fact considered a bug. <PotentialUser-95>nckx: Okay, so who builds these kernels, and it sounds like they don't use guix? <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. ***reepca` is now known as reepca
<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? <roptat>it's been a while I haven't been on IRC ***rekado_ is now known as rekado
<roptat>(it's for a font, so maybe it's even considered non-functional data?) <mbakke>PotentialUser-95: depends on what you are trying to do, but gnu/packages/cmake.scm has some variables that are re-used between the various versions <bricewge>I keep running into backtraces that start from “guix/ui.scm” and directly end up in Guile's “ice-9” without any relevant information about where the actual issue <bricewge>How do you deal with such backtraces? Is it a bug? <mbakke>bricewge: I've also seen failures from guix/ui.scm that were "hiding" the real problem, probably a bug <cbaines>I think I had some success in just commenting out the exception handling code in (guix ui) once... I can't remember the details though <bricewge>A few times already I managed to bypass that code by using guix repl, but it was tedious... <bricewge>I wanted to know if someone had a more straight forward method <emys>cbaines, I sent an email to guix-patches@gnu.org about 5 hours ago and haven't since received back a debbug ticket confirmation, is it expected to take time? <cbaines>if it's the first time you've emailed guix-patches@gnu.org, it might be stuck in moderation... <cbaines>I'm not sure how the mailing lists are configured <emys>it would be the second time <emys>the mail was distributed via patches <nckx>emys: It's not stuck in moderation. <nckx>Debbugs sometimes decides to take an hour off <pkill9>here is a prototype demonstration of a launcher I want to make: <pkill9>guix environment --ad-hoc bemenu -- $(guix build $(guix package -A | awk '{print $1}' | bemenu --list 10 --no-overlap --ignorecase --prompt Run: --prefix \>))/bin/* <pkill9>assuming there's only one binary <pkill9>it gives a menu where you select a package, then it builds and runs the binary in that package <pkill9>so you can select any available package like it's installed, and run it as if it's installed, and do the guix thing of getting it automatically <pkill9>ever more removing the concept of 'installing' a package <pkill9>more like 'syncing' a package with <rekado>bricewge: it would be good to have a test case so that we can see why the backtrace is swallowed <nckx>pkill9: C'mon, 2020 that bad boy. ‘Cloud-run’ your ‘apps’! <rekado>instead of “awk” you could use “cut -f1” <rekado>dunno how much memory you save this way, but you’ll need all the extra memory for running Guix ;) <Blackbeard>nckx: this semester I had a class about cloud computing. It was meant to be about legal stuff, like the contracts and so on. But instead we literally were told the same thing. <Blackbeard>That cloud computing in 'better' and how to buy this types of services and we should convince the companies we work for to move there... <Blackbeard>The thing that pissed me off the most was the book. Written by a professor of the most respected univeristy here in mexico. Sponsored by Microsoft. <Blackbeard>I just found it funny that yeah, they do teach that in 2020 you should use the cloud <nckx>s/computing/thinking/g sometimes helps convince non-techies how dystopian things are about to get, but even then you get the shrugs. Some seem to welcome it. ‘Finally! Thinking's hard work.’ <nckx>Since Guix is part of the solution, if not a full-blown life raft, I choose to deem it marginally on-topic 😉 *nckx back to ‘work’ though. <Blackbeard>nckx: He is clearly a sold out and I get really angry he has another book on Electronic Voting, he recommends using proprietary software on those machines. Specially the OS <Blackbeard>Because as the code is secret that means it is 'more secure' and 'harder to hack' so voting machines should run windows over GNU/Linux <anadon>He's...provably wrong by theory and real world practice. <Blackbeard>Yes.. but it is sad that somebody so respected teaches such terrible things <bricewge>Blackbeard: Teaching such things surely help to become someone respectable... ***familia_ is now known as familia
<ryanprior>It kills me that Docker reports my images from Guix as "created 50 years ago" 😂 <ryanprior>Is there any option to make `guix pack` use real timestamps if I actually want to remember when I created each image? <ryanprior>(it appears from my research thus far the answer is no) <anadon>submit a bug report to docker lol <emys>have guix packagers made any decision on Python 2 for the future? I still see python2 packages in the tree, but lots of python packages are not maintained anymore for python 2 <emys>this will cause problems in the future <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. <nckx>emys: An example of what? <emys>options would be (a) drop python2 entirely, (b) bump up python-setuptools and keep python2-setuptools at the last release level (c) keep the common denominator <emys>(c) is not an option at all I think <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. <apteryx>emys: guix environment --pure --ad-hoc python@3 -- python3 -c 'import setuptools; print(setuptools.__version__)' --> 412.0 <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. <emys>apteryx, xarray needed "setuptools >= 41.2" <ryanprior>Anybody want to tell me that already exists or gas me up to try and implement it as a prototype? <emys>and wouldn't install with guix without me providing an own description of that package <emys>wonder what happened there <nckx>emys: First, try substituting that to relax the requirement. Many of those are bogus. It might work fine with an older version. <apteryx>emys: >= 41.2 should be OK with 41.2.0 <emys>possibly the python-setuptools definition in python-xyz is older (?) and I pulled it in <apteryx>yes, you shouldn't include the python-setuptools package itself <apteryx>I think it's use is for when the main Python release on master starts to get dated, and a newer setuptools is needed for some packages. <nckx>ryanprior: My (new and improved corona)beard says that should be done using Unix® philosophy™ tooling, not Guix, but I don't know if that's realistic. notify-watch && foo? <apteryx>currently the setuptools in Python itself is newer than the standalone package <emys>apteryx, but then imho it should have a tag to its name like either python-setuptools-next or python-setuptools-oldstable or something <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 <pkill9>ryanprior: there was talk on the mailing list about build servers providing a list of files <pkill9>I hope guix gets that functionality <apteryx>emys: not through the API, I'm afraid, but you can hack away with awk or grep and pass the list to guix build <pkill9>then I can make those magic things <ryanprior>pkill9: have you seen the prototype of install-less npm where all packages implicitly exist and when you `import` something from them it installs them on the fly? <apteryx>there might be something smart that can be done to retreive all the packages from a given module, but I don't know it. <pkill9>no ryanprior, I don't know much of anything about npm world <apteryx>the easier thing to do is to filter based on a prefix, e.g., 'python-'. <pkill9>other than that it's a mess, lol <ryanprior>I saw a tweet the other day that made me stop and think for a few minutes about npm and guix, let me find it <rekado>emys: yes, you can. “guix build -e” supports arbitrary expressions. <kamil_>I broke my Guix installation in QEMU during a system reconfigure by pressing CTRL+C to cancel transaction. I thought it was perfectly okay to do that in Nix and Guix >.> <rekado>it is okay to cancel a reconfiguration <mbakke>I've borked both NixOS and Guix by cancelling at the 'installing bootloader' stage :-/ <kamil_>GRUB can't find a neccessary file now <bricewge>Hum, cant this step be made atomic too? Or just ignore signals during bootloader installation to avoid such issue? <rekado>let’s discuss in a bug report to bug-guix@gnu.org <kamil_>Off to rewrite my config. Thankfully, it was pretty minimal, so I can re-make it from my memory <mbakke>I don't think it can be made atomic, but ignoring signals might help. <kamil_>(unless I learn how to access QEMU images) <mbakke>kamil_: you can also fetch it from the file system below /var/guix/profiles/system/configuration.scm (if you can mount the disk) <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>alextee[m]: Which plugins? <lfam>Does the calling program have a way to configure the search path at runtime? <alextee[m]>running with LD_LIBRARY_PATH=/usr/lib on archlinux seems to solve this. is this the right way to do it? <alextee[m]>lfam: the library search paths? no. is there a way to do that with C? i can try <lfam>Different programs do different things <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 <lfam>I think it's a similar problem, but happening in a different location <lfam>Is this plugin from Guix? <lfam>I'm not sure you can mix these things, but I don't know what `guix pack` does <alextee[m]>and the user installs zrythm from a tarball produced with guix pack <lfam>I didn't think it was possible to use libraries linked against a different libc <alextee[m]>well, LD_LIBRARY_PATH=/usr/lib seems to do it here <lfam>I think the plugin ecosystem should have a specific way to configure these lookups <lfam>LD_LIBRARY_PATH is a big hammer <alextee[m]>i guess you'd basically pass this before you do dlopen() somewhere <alextee[m]>so i can only do it for plugins, instead of the whole program <alextee[m]>also have this problem (unrelated to plugins) when running without LD_LIBRARY_PATH: <alextee[m]>missing fonts maybe, but i thought gtk includes the default gnome fonts <lfam>alextee[m]: Please report it on the bug tracker. Search for existing bugs first. I think it's a regression in pango <ryanprior>How do you install an extension (like ublock origin) on ungoogled chromium? <ryanprior>Do you use the native method (download & installing crx files) or can we package a browser extension in guix? <Blackbeard>ryanprior: check the github page, there is a link with instructions <ryanprior>I don't see anything about extensions in Guix, and I don't see any extensions in `guix package -A chrom`, so I intuit the answer is there's no way yet to use Guix to install extensions <alextee[m]>i guess if i added a propagated-input for cantarrel fonts it would work? let me try <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))" <bricewge>alextee: I mean I have the exact same issue with lightdm-gtk-greeter, lprndn reproduced it and opened that issue. <rekado>or you could use (module-map (lambda (sym var) (variable-ref var)) (resolve-interface '(gnu packages statistics))) <bricewge>ryanprior: That not guixy for sure, but that's how I managed to install ublock origin <bricewge>ryanprior: I can't find a ublock package in Guix either <ryanprior>It's going on my list of things to research :) <ryanprior>I imagine I'll have to figure out how to write a profile hook to link to all the plugins from a standard place, and then possibly patch the ungoogled chromium package to look in that place <anadon>OK, `git pull` broke for https remotes. Installing curl doesn't fix it. What do I do? <bricewge>anadon: What about installing nss-certs? <anadon>`fatal: unable to find remote helper for 'https'` <anadon>No change in behavior, confermed that GIT_EXEC_PATH is set. <anadon>it is set to /home/anadon/.guix-profile/etc/ssl/certs/ca-certificates.crt <bricewge>It's fine, that path should contains nss-certs certificates <anadon>bricewge: symbolic link to /gnu/store/yjprf993p3li25wv3kxm09q051r5lcdx-ca-certificate-bundle/etc/ssl/certs/ca-certificates.crt <anadon>Installing 'git:send-email' did not imply installing git. <emys>rekado, thanks for that example <jonsger>anadon: I have something similiar. git is installed via config.scm and git:send-mail via profile. Then you can't clone/pull/fetch via https <lispmacs>I needed to try maxima with sbcl backend instead of gcl. Isn't there some kind of quick and easy trick to replace an input of a package? <nckx>ptibedo: Having looked up what that is: it hasn't been packaged for Guix yet. So ‘not, until someone packages it’. <nckx>Unless it's a ‘mode’ that can be unlocked from Gnome 3, but it seems to be its own package now. <nckx>ptibedo: Gnome being Gnome it might not be trivial to *integrate*, but it's probably not too hard to *package* if you want to get the ball rolling with a patch. <ptibedo>You ask what I try packaging the gnome-flashback ? <nckx>I suggest it. People will be more likely to help you get something working, if there's something to get working. <nckx>Of course we're here to help you package it too. <ptibedo>I found the documentation guix in French. I will try. <rekado>ptibedo: please note that we’re a bit behind with Gnome, so when you package it make sure to pick a version that matches the rest of Gnome in Guix. <nckx>If English gives you trouble, help-guix <at> gnu.org accepts mails in French. Of course English will get you more eyeballs. <anadon>rekado: Should I try to move gnu-gettext from tarballs to VCS? <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. <roptat>anadon, aren't gnu tarballs already saved in SWH? <anadon>Wait, you don't have the chat log <kamil_>I had to reboot to apply a kernel update, and change a setting in the UEFI <pkill9>i thought guix already falls back to swh <sneek>Welcome back kamil_, you have 1 message! <sneek>kamil_, anadon says: VCS -> version control system, like git. <anadon>pkill9: only for packages which use `git-fetch`. <roptat>I thought I saw it on url-fetch too <anadon> It was an intended feature which never got finished. <roptat>I see, (guix swh) is only imported in (guix git-download) <anadon>I'm working on updating python-argon2-cffi now, but I'll go back and make the switch over to VCS on gettext for the next patch. <roptat>any change to gettext will have to go to core-updates anyway, so you have at least a few months to prepare a patch ^^ <roptat>but it'd be best to support swh fallback in url-fetch <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