***stikonas_ is now known as stikonas
<mprodrigues>hello, I've recently installed a guix system on a remote machine so I can experiment with it <mprodrigues>I have encountered an issue when I try to connect to this machine using emacs tramp <leoprikler>charles`: you can, but it will probably print something else from what you're expecting <mprodrigues>tramp basically cant find any commands because they are not in the stadard /bin or /usr/bin locations <mprodrigues>did anyone experience something similar and have some pointers on how I can make tramp see the guix paths of the current profile? <leoprikler>mprodrigues: that is to be expected. I suppose you can't simply source the remote's /etc/profile upon "login"? <mprodrigues>if I spawn a shell with tramp and run source /etc/profile indeed it seems to solve, but then it only works for this shell, I still cant open a file with "C-x C-f" for example <mprodrigues>but thanks for your pointer, seems I only need to set tramp-remote-path ***cdegroot__ is now known as cdegroot
***scs is now known as Guest72788
***cdegroot_ is now known as cdegroot
<Whyvn>does it matter the order of guix package -u, or guix system reconfigure? Currently I am guix pull -> -u -> reconfigure -> gc <lfam>`guix package --upgrade` has no effect on either `guix pull` or `guix system` <lfam>`guix pull` updates (or rolls-back) the set of available packages, services, and other things like that. So, it comes first <Whyvn>does upgrade download the new kernel or does system do that? I guess thats my mine concern with the order of using guix system. <lfam>`guix system` controls the system, which includes the kernel. `guix package` is strictly something used by a user to control the packages they have installed themselves (remember, Guix can do per-user package management, in addition to the "system" packages from config.scm) <lfam>There's not really any reason to "install" a kernel using `guix package` <lfam>It would not become the kernel that your system used <Whyvn>ok, thank you for clarifcation. wasnt sure what was dependent on each other when dealing with upgrading. <lfam>You're welcome! It's different from old-school distros <lfam>Feel free to ask for further clarifications ***iyzsong-- is now known as iyzsong-w
***scs is now known as Guest39650
***iyzsong-- is now known as iyzsong-w
***scs is now known as Guest25016
<clacke>I am running Guix as a sidecar on Ubuntu <clacke>How can Guix programs understand my IBus input methods configured in Ubuntu? <clacke>I have tried installing ibus on the guix side as well, and `ibus list-engine` with that ibus correctly lists my system-installed engines <echosa>Hey, all! I installed guix as a package manager on top of Pop!_OS. I can't figure out how to run guix programs with `sudo`. For example, I installed powertop through guix. Powertop requires root privileges, but when I `sudo powertop` I get "sudo: powertop: command not found". <ison>echosa: Probably because the root users $PATH doesn't include your users guix profile. Try sudo -E to preserve the environment. <clacke>sudo -E works of course, but I feel better not inheriting my whole env into a root shell -- sometimes some application will write to a file in my home directory as root if it gets a variable pointing there <clacke>sorry for that mega quote, didn't realize it would transfer over to IRC <lle-bout>clacke: otherwise use GNU Guix within your root provide and install it there <clacke>`sudo --preserve-env=PATH` in that case. thanks, never looked for that! <clacke>`sudo -i guix environment --ad-hoc powertop -- powertop` works too, there are many ways! <clacke>nobody on the channel today ran into IME issues with sidecar Guix? <lle-bout>clacke: what is IME exactly? Fonts or RU/ZH input/ <efraim>Give it a bit, Europe is still waking up <lle-bout>efraim: Tor has issued a CVE but not showing up in my feed still, weird! <clacke>yeah, not fonts, that part I've solved, just install all the fonts again on guix side <clacke>it's about entering Chinese characters and unicode emoji <lle-bout>seems there's a bit of a bottleneck in disclosing the details here <lle-bout>clacke: don't know at all :-/ - it's possible that works work at all in GNU Guix, we don't have many users for these things AFAICT, how does it work? what package does it involve? <lle-bout>it's possible that it doesnt work at all * <PotentialUser-41>Friends, I found the Bottles app in the Guix Wishlist, I do not know how to package, please package! <rekado>PotentialUser-41: being on the wishlist means that someone wants the package, but it doesn’t mean anyone here will package it upon request. <rekado>(I also think this package will cause some controversy, being that one of its primary purposes is to download non-free software.) <rekado>when there is no schedule nothing can be too late. <leoprikler>I think lle-bout would disagree: We can patch CVEs too late :P <lle-bout>leoprikler: blah we're doing our best as a grouped whole <lle-bout>if things arent being done naturally most likely it means we would be burnt out if we started adding schedule or policy <lle-bout>leoprikler: don't take my emails wrong :-) - I just wished to transfer some info around there so we can all have an idea in mind, not to try to enforce some policy or make everyone burnt out <leoprikler>FWIW moving packages, that haven't received updates for years to guix-history sounds like a workable solution <lle-bout>I feel like sometimes GNU Guix puts lots of load on itself by accepting all packages in like that <lle-bout>At the same time it's good, but maybe some people want to be able to make the distinction between "this is a maintained package" vs "this is kind of abandonned" <lle-bout>I think there could be a simple metric: when was that package was last updated, in "guix show" <lle-bout>And then we could even query by date like show every package without updates in 1 year? Then go over them see if we can do something <lle-bout>Or if they're just perfect and don't need updates <rekado>lle-bout: there are quite a few packages that don’t get updates for over a year (like axoloti-patcher); but having a lint check to find packages that might need attention could be good. <leoprikler>Yeah, I feel like there's certainly clashing metrics here so I don't know how good tooling can be here <lle-bout>It's not a perfect metric, but may help draw attention to things <lle-bout>We will have false positives because obviously some things don't get updates and it's normal <leoprikler>btw. where was the guix history channel stored again? <lle-bout>Maybe we can combine Scheme code parsing with git-blame and generate data, not sure how it could be implemented here in a non-expensive way <leoprikler>I remember reading about it when it came to reproducible papers <lle-bout>It's nonofficial though.. maybe something official would be great <lle-bout>So instead of removing mongodb recently we could've moved it there <lle-bout>The last version under SSPL with known security issues <rekado>lle-bout: the guix git project that Magali worked on during Outreachy could be a starting point. <lle-bout>well after all, I think we don't need this. time-machine is enough. we should just remove. <lle-bout>rekado: but yes this could be used to help people find old packages's revisions in time-machine <lle-bout>So one can list or search through removed packages <efraim>I could see moving openssl 1.0 there but I'm not sure mongodb is worth it <rekado>time-machine is great, but it’s not necessarily composable <rekado>say you’ve got a Python environment and you want to add a package to it that has been removed <lle-bout>rekado: composable how? also inferiors can be some kind of time-machine? <rekado>guix time-machine will get you the package built with that old Python <rekado>and this may not be usable in your current environment <lle-bout>Well at some point if a package and it's dependencies are removed, it can be heavy work to actually make the package work with latest GNU Guix at all times <lle-bout>Maybe we can have "inferior" input like use input from old-guix in new-guix? <lle-bout>But that's quite an heavy backwards and forward compatibility requirement <rekado>for some package definitions “lifting” them might be possible, but it’s very different from what the time machine does. <rekado>lifting just the package definition ignores the meaning of the symbols used. <rekado>one of the key ideas of Guix package definitions is that they are “live” values that — when fully evaluated — give you the complete package graph. <pinoaffe>hi folks, I'm trying my hand at packaging copasi, but there's a linking error at the end of the build phase of one of its dependencies (libcombine), and I don't know why - could someone take a look? <pkill9>does anyone have a setup on laptops that doesn't use netowrkmanager <leoprikler>pinoaffe: looks like some dependency is not linked in correctly. Does the libary need to be linked statically? Perhaps dynamic linking would help here. <pkill9>does connman work better for you? <pkill9>i'm getting random disconnects with networkmanager <pkill9>though idk if that' snetworkmanager's fault <efraim>It integrates better with enlightenment I think and I'm pretty sure it's more light weight <lle-bout>also I wonder, can we upgrade network-manager without breaking compat? ***iyzsong- is now known as iyzsong
***MidAutumnHotaru1 is now known as MidAutumnHotaru
<PurpleSym>Is there a function to get a list of all submodules for a certain module? I know about `module-submodules`, but it only works if the submodules are loaded already it seems. <civodul>PurpleSym: hi! in general it only works if submodules are loaded, yes <civodul>but see (guix discovery), which might have tools you're looking for <civodul>iyzsong: the FTP client gets stuck on EPSV when running "guix refresh gnutls"; does that ring a bell? <lle-bout>civodul, iyzsong: the story was that the GNU FTP administrator would need to do something <lle-bout>It's possible nobody has actually reached to the GNU FTP administrator <lle-bout>FTP is kind of deprecated anyway, shouldnt we strive to use newer protocols is they exist? <leoprikler>and jgart recently removed it from the Guix wishlist (potentially for that reason) <fnstudio>hi, i seem to have problems with an emacs package (jedi, specifically "M-x jedi:install-server"); i think this is due to jedi trying to write in "/home/user/.guix-profile/share/emacs/site-lisp/" <fnstudio>anyone that has encountered something vaguely similar? <leoprikler>packages trying to write to their install directories do exist; can you somehow change that directory through a clever custom-set? <fnstudio>leoprikler: yes, that should be possible, let me try <cdegroot>Is there a clean way to set your default profile to a store profile? I'm toying with keeping two of my "daily driver" machines in sync; `guix copy` of an updated profile works wonderfully, but then I'm manually making the symlinks in /var/guix (running Guix under Ubuntu, slowly moving software over) <efraim>I set both machines to use each other for substitutes and keep them in sync using 'guix describe' to pul the same commit and a manifest to install the same software <cdegroot>That's what I tried first, but my network and Guix' networking libs don't like each other. If I use the other box (I tried in both directions) as a substitute server (using `publish`) then the client will pull one, maybe two, packages before bailing out with an error. <cdegroot>(I'm also itching to add Avahi discovery to the Guix daemon to automate that, but first it needs to work lol) <cdegroot>So I was gonna use this as a stop-gap measure until I get a bit of time to go into the code base and figure out why the networking client seems to be a tad brittle/sensitive. <cdegroot>(I probably could still do the same pull/update dance after a copy, but why all the trouble if I'm two symlinks away from what I need? ;-) ) <leoprikler>cdegroot: the "bailing out" is a known problem, that will hopefully be fixed soon <leoprikler>The solution proposed by efraim is indeed the canonical one, you just need to work around with bash's while or until to make it work currently. <cybersyn>build of guix-cli is failing on guix pull, has anyone else had a similar issue? <roptat>cybersyn, I just pulled successfully <roptat>sounds like there's been some network issues recently, so maybe try again? <pineapples>I'm trying to switch to Icecat but it can't install the Multi-Account container addon from Mozilla's official addon repository. Does anyone know why this is the case? <pineapples>roptat: I got around 5 bad reponses during my last guix pull.. yeah.. No wonder why unattended updates fail to complete <civodul>"guix time-machine -- describe" works for me! <civodul>if it works for me, i conclude there's no problem :-) <civodul>just pushed the 'generic-html' update for "guix refresh", lemme know if it doesn't refresh as well as you'd like! <rekado>do you remember which French ISP had reproducibly poor connections to ci.guix.gnu.org? ICMP is no longer filtered for ci.guix.gnu.org, so it would be nice if affected people could try again to see if this change makes any difference in connection speed. *efraim has never lived in France <cybersyn>i started using doom-emacs about a month ago and have to say i'm pretty impressed. will be interesting to see what sort of "opinionated" community configurations of guix might arise in the future. <roptat>rekado, I can now send ping from from all over the world with my botnet, er... the atlas network :) <roptat>(you can sort by AS, free is 12322) <roptat>there's one measurement from renater that failed completely <roptat>interestingly, one of the probes was in french polynesia, and it's terrible, 300ms <roptat>is the search from cuirass not working as advertised? I'm trying to look for "status:failed" and there's no result <cdegroot>leoprikler thanks, if it's a known problem I'll exercise some patience :). Or figure out how I can help - I value contributing over complaining. <zimoun>On 1a26584 from today, “guix weather“ is always failing with «In procedure %origin-patches-real: Wrong type argument: #<package libtirpc@1.2.5 gnu/packages/onc-rpc.scm:38 7f721f9d50a0>». Is something wrong? ***leoprikler_ is now known as leoprikler
<civodul>zimoun: what package shows up in the stack trace? <civodul>"guix weather libtirpc" works for me, for example <zimoun>civodul: «package-derivation _ #<package libtirpc-hurd@1.2.5 gnu/packages/onc-rpc.scm:78 7ff163be1000>» if it is what you mean <zimoun>civodul: BTW, ‘guix weather libtirpc’ works for me too. Bu not plain ‘guix weather’. <fnstudio>i've this vague memory of having solved this already a few days ago, but i now forgot how :( <fnstudio>i've thrown a few extra packages at it, eg python-certifi, python-cryptography, openssl, but none of those helped <lfam>fnstudio: It's likely that you need to set some environment variables to tell Python where to find the certificate store <nckx>rekado: I don't know if I've asked explicitly: does the MDC hand out IPv6 addresses at all? <fnstudio>lfam: oh, i see, i don't remember having done that, so probably i didn't actually get to the end of it the other day... :) <nckx>Unblocking ICMP let me set up ye classic HE tunnel, but it still won't work. Probably because protocol 41 is blocked. <lfam>fnstudio: I don't know how Python finds the certificates, but it doesn't seem that Python itself depends on them, so I assume that the "system" (aka you) have to set something up <nckx>I think. It's been years since I've had to resort to that; my debugging's rusty. <fnstudio>lfam: right... now guix edit urllib3 does mention something about urllib3[secure], but i've tried all those dependencies and they also didn't work, so i suppose it's like you say, a missing underlying setting *lle-bout opens their RSS reader to process CVE entries <mschilli>Hello. First time here. Usually I bother rekado directly by mail but I figured if there are more people that might be able help, why not give it a shot first. ;-) <lfam>linux-libre isn't out yet <mschilli>I am a total beginner in guix packaging and have no other experience with scheme. <mschilli>But I try to package what I find missing and learn along the way. <mschilli>Now I reached a dead end. Is this a good channel to ask for specific advice? <mschilli>Great! So the package in question is dead simple: It is basically a single perl script with no further dependencies but a perl interpreter. <mschilli>So all I need is to i) download the source (provided as a zip over HTTP), ii) unpack the source, iii) copy the perl script to a place where it ends up on PATH, iv) patch the shebang, and v) make the script executable. <mschilli>Since I want to learn, I started by reading documentaion and builing up from there. <mschilli>I use `url-fetch` to download the zip and got the sha256 via `guix download`. <mschilli>Next, I tried to use the copy-build-system to 'install' the script. <mschilli>I added the script to the install-plan with `bin/` as the target. <mschilli>Testing it out, I my first attempt via guix-build, I hit a 127 during the unpack. <lfam>mschilli: Did you add the 'unzip' program to the native-inputs of your package definition? <lfam>IIRC, unzip is not available by default <mschilli>That was exactly the solution I came up with! :-) <mschilli> 8 (primitive-load "/gnu/store/skzq51yc5aksk64ra6lkjd1pskp…") <mschilli> 838:2 6 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #) <mschilli> 1736:10 5 (with-exception-handler _ _ #:unwind? _ # _) <mschilli> 857:16 4 (every1 #<procedure 7ffff4b3e820 at guix/build/gnu-bui…> …) <mschilli>I tried the the pastebin suggested by the web client and it failed, then I ended up closing the wrong tab. My bad. <efraim>mschilli: switch it from url-fetch to url-fetch/zipbomb <mschilli>If I am guessing correctly, my issue is that the zip does not conain any subdirectories. <efraim>yep, zipbomb will repack it so that it will have a directory to chdir into <mschilli>So I figured I need to find a way to skip the chdir. <mschilli>I got past the point by via the zipbomb. Where is that documented? I completely missed that. <lfam>I see that it's not documented in the manual <lfam>It should be added to the manual section "origin Reference" <mschilli>It also appears that the copy-build-system does the shebang patching for me already. So all I need to do is make sure the script ends up executable as well. <mschilli>If that didn't happen automagically, I guess I'll figure it out. <lfam>That's what this channel is for <mschilli>Everything appears to be working now. Glad I got this close by myself. Overall the documentation is great. <lle-bout>apteryx: hey! what's your email? trying to figure out who you are here and by email <lfam>We'll need to add the zipbomb and tarbomb variants to the manual, mschilli. Thanks for highlighting their omission <lle-bout>lfam: I see :-) Didnt think they could list their IRC nick there too <mschilli>So if this is in some sort of official issue tracker, I guess it can be closed referring to those variants. <lfam>lle-bout: It just tends to happen that people use the same nickname here <lle-bout>lfam: pygments upgrade we have a python2-pygments package on an older version left vulnerable <charles`>How would I go about editing sddm-configuration to accept more options? <lfam>lle-bout: Is the python 2 variant used by anything? <lfam>Does `guix lint -c cve` show it? <lle-bout>lfam: it doesnt work on python-, go- or rust- packages now, the linter <lle-bout>lfam: it's because there's a prefix basically, so it doesnt look up the actual name but the prefixed name <lfam>In general, we need to decide on and announce a specific timeline for removing Python 2 things <lfam>Specifically for this package, I would ignore it <lfam>If it weren't used by anything, I would remove it <fnstudio>i think i got to a minimum example where python doesn't work with ssl certs in a pure env: guix environment --pure --ad-hoc python python-wrapper python-certifi -- python -c "import certifi; certifi.where()" <fnstudio>this returns nothing, which is not what one would expect <lfam>fnstudio: So, in general, programs should use an environment variable to look up certificates. <lfam>They shouldn't depend on a "certificates package" directly, because certificates expire, and so we want to be able to update the certificate store without rebuilding packages that do TLS <lfam>This usually means something like $SSL_CERT_DIR=/etc/ssl/certs <fnstudio>lfam: yeah, not an expert here, but yes, it does feel like it should accept an env var... <lfam>Zooming out, if Guix packages are finding certificates from that python-certifi package, that's (going to be) a problem <lfam>We don't want our packages to "expire" <lfam>So, concretely, you could try including nss-certs in your pure environment <lfam>nss-certs is the default certificate store package in Guix <lfam>It's maintained by Mozilla <fnstudio>lfam: right, i think i see the point, one can manually set a ca-cert in urllib, if i understand it correctly, but not with certifi; nss-certs doesn't seem to help, per se, but i suppose i can do nss-certs plus manually passing the path to urllib3 <lfam>I recommend learning how this is supposed to happen for Python <fnstudio>lfam: you already helped a lot! thanks!! <lle-bout>flatwhatson: hey, I get errors like invalid specification for sudo with tramp on your Emacs in your channel, not sure if you know <nckx>charles`: You'd set up your own local git repository, if you haven't done so yet (documented in the manual, something like ‘building from git’). Then you'd edit gnu/services/sddm.scm to include the new options, commit it, and send it to guix-patches at gnu.org 😉 <nckx>That should keep you busy until I've finished dinner o/ <lfam>charles`: Once you have the development repo set up and working, you can test changes to services with something like `./pre-inst-env guix system vm-image doc/os-config-lightweight-desktop.texi` <lfam>That file is one of the example operating system configurations included in our repo <lfam>However, you'd need to adjust it to use SDDM instead of GDM, assuming you want to test changes to the SDDM service <charles`>then I need to install that vm-image in a vm to test? <lfam>So, you'd just launch it with QEMU, as described in that manual section <efraim>vm-image returns a shell script, you'll (likely) need to run it with sudo and to add '-m 1G' or so to the end to make sure there's enough memory allocated to it <charles`>thanks. I don't see os-config-lightweight-desktop.texi though <lfam>charles`: Did you build the repo yet? <lfam>That should create the file <lfam>efraim: No, vm-image doesn't create a shell script <lfam>You're thinking of `guix system vm` <lfam>vm-image creates a qcow2 file, which is a QEMU VM image format <maddo>aside from politics, is there an up-to-date list of differences between nix(os) and guix(system) <maddo>like, nix has home-manager etc... <lfam>charles`: The file may exist before building, at 'gnu/system/examples/lightweight-desktop.tmpl'. But, you'll need to build the repo to test your changes <lfam>maddo: At this point, it's easier to list the similarities <maddo>since I can't find as many resources about guix that I do find about nix <lfam>If you have some specific questions, we could answer those. But in general, Guix is a totally different operating system from Nix <lfam>There's very little in common <lle-bout>maddo: Guix's not a fork of Nix, rather a functional distro like Nix but that's mostly it <maddo>While I do have some knowledge about nix, my understanding of guix is rather limited and I wanted to see if I could jump ship (as an avid emacs user, guile is far more appealing and the guix interface for emacs is admittedly yummy) <maddo>for example, nix is about to introduce the concept of flakes, mostly discarding channels, while I understand that guix has channels (but they seem different compared to nix) <lle-bout>maddo: actually flakes look like GNU Guix Inferiors <lfam>Yeah, but that's the only part, and a relatively unimportant one <lfam>I mean, yes, it's "important", but not to the experience of using Guix <lle-bout>It provides the security model of a functional package manager <lfam>guix-daemon / nix-daemon <lfam>The thing that handles building <lfam>It was forked from Nix in 2012 <lle-bout>Rather, handles creating sandboxes, the build is still handled by GNU Guix/GNU Guile code ***zimoun` is now known as zimoun
<lle-bout>lfam: sqlite security patching I am looking at <maddo>could you explain further about flakes being a guix inferior? My understanding of flakes in nix terms is that they're basically what you could already do using niv, but on a system level <lle-bout>maddo: inferiors are not exactly like flakes but it seems they have overlapping functionality <lfam>Nice, lle-bout. I'm sure you know that sqlite is used by Guix, so we have a good test case built-in <lle-bout>maddo: the idea of pinning to certain version of GNU Guix is kind of what inferior can do <lle-bout>It allows composition of different versions of GNU Guix <charles`>after building, trying to build image, I get "guix system: error: failed to connect to `/usr/local/var/guix/daemon-socket/socket': no such file or directory" <roptat>I noticed our python was 2-3 times slower than ubuntu's, any idea why it would be the case? <lfam>charles`: You forgot to configure the build with `./configure --localstatedir=/var` <charles`>fyi it says vm-image is depricated, use image instead <lfam>Yeah, but the online manual still refers to vm-image, so I suggested it <efraim>roptat: there's special magic when it comes to compiling python to be quick <efraim>I hear fedora's python config is worth looking at <lfam>I have an old abandoned Git branch that builds Python with "--with-lto" and "--enable-optimizations" <efraim>honestly I wish I knew, it has something to do with certain bits shared or static but I can't remember at all <lfam>roptat: I don't remember, it's from 2017 <lfam>There must have been a reason for it <roptat>well, I have some changes for python I want to push to core-updates anyway, so I can try those options too <lfam>I'd guess that "enabling optimizations" is something we should look into :) <lfam>And we should also look at what Fedora does. They are usually good about these things <roptat>right, it's disabled by default, but described as "stable" <lfam>And, Python is sloooow for me in Guix <lle-bout>lfam: there is this new feature in Glibc: HWCAPS, allowing to ship specialized functions for different pieces of hardware so you don't get the worse common denominator <lle-bout>There's also a feature in GCC that can have symbols depending on certain CPUID features like SSE, AVX2, AVX512, .. <lfam>As long as it doesn't optimize things for the build machines, but instead generically, that's okay for Guix <lle-bout>We could do so for select packages that would be great to optimize <pkill9>has anyone run guix on alpine linux? <lfam>We've had to turn off machine-specific build-time optimizations for several packages <lle-bout>lfam: yes it's generic, basically it creates binaries that can target many archs <lfam>I guess we should profile it, when we start working on core-updates (after the release?) <lle-bout>duplicating code with fallbacks to most compatible available <lfam>There is a set of architectural features that are considered the required lowest common denominator for Guix. I'm not sure where they are documented. We have to be careful about not accidentally changing those <lfam>It means that we don't require some newer features <lfam>It's a good question to ask Mark Weaver, since he tended that stuff previously <lle-bout>lfam: of course we wont, this GCC thing I am talking about is specially for creating binaries that can autodetect at runtime what features can be used and pregenerated machine code for different CPU features available and use them <lfam>It would be good to document those requirements in the manual, though, if they aren't already <lfam>It may be a bit of implicit knowledge that's in danger of being lost, idk *vagrantc cheers for runtime feature detection <efraim>it looks like there's something about flatpackage for python <pkill9>what would be good is that guix alternative of use-flags, combined with grafts, so you could enable all the runtime optimisations of all the core software like python, and graft them onto every package <efraim>looks like one for interactive use and one for scripting? or something like that <bdju>which package has the drill command? ldns didn't seem to ***smartineng2 is now known as smartineng
<nckx>bdju: ‘guix show ldns’ shows a drill output, does it not have it? <cbaines>I haven't looked at the actual changes, but the Guix Data Service seemed happy processing them <bdju>nckx: ah, thanks. didn't notice it was a separate output <lfam>roptat and I discussed the UI of multiple outputs recently. <lfam>I should find the chat and send it to guix-devel <efraim>the link to the other change proposal IIRC is also worth reading <nckx>IWBN for ‘guix search’ to highlight the search term(s) as well. <nckx>Don't worry, I'm sure it will be a nice mess to thread WORD all the way to the actual PAGER invocation :) ***daniel is now known as Guest28141
<fnstudio>lfam: as we said before, my issue with python and the certs (from earlier today) had more to do with python rather than guix, but i was able to make it work; i added nss-certs and openssl as dependencies and that did it <fnstudio>(just in case someone stumbles upon the chat log in the future) <bone-baboon>`guix search getmail` says that getmail has no dependencies. Is that correct? I would have expected it to have dependencies (Python for example). <lle-bout>lfam: is it a good idea to graft sqlite from 3.31.1 to 3.35.2? <lfam>I'm skeptical lle-bout, but it's not impossible <lfam>I would expect sqlite to announce ABI changes, given it's importance and their good development practices <lle-bout>lfam: yes? I am thinking sqlite3 has unchanged ABI since a while? <lle-bout>ABI or file format changes would mean new major version? <lfam>I don't know their versioning scheme <lfam>I also am wondering... why would we do that? <lfam>Graft such a major update <lle-bout>it's not that major though, it dates back 6-8 months <lfam>Well, if it works, then it works, and if it doesn't work, then it won't work <lfam>We should test it, if it's what we want to do <lle-bout>we could also backport/apply patches but extra maintenance load, couldnt find other distros maintaining our version <lle-bout>lfam: of course testing is always happening <lfam>Something to check is if these bugs apply to our version <lfam>Like, maybe some of the bugs were introduced after 3.31.1 <lfam>We can also look at what we've done in the past <lfam>That can help us make judgements about the "safety" of grafting big updates of a package <lfam>So, if we've done this with sqlite before, and our tests of this graft are successful, we can feel confident about it <roptat>lfam, efraim so I managed to build python with --with-lto, --enable-optimizations, --with-computed-gotos and -fno-semantic-interposition, and I ran two "fast" benchmarks. the first is 17.9 ms -> 13.7 ms and the second is 241 ms -> 164 ms, I can run more benchmarks, but I think it already shows we get a big improvement :) <roptat>that's for python on core-updates, with my patch to remove some output in both case <lfam>I thought I noticed earlier today that Fedora doesn't use enable-optimizations. Do you know if that's correct? <lfam>If so, it would be good to understand why <lfam>Or, at least to understand the trade-offs of this option <lle-bout>lfam: CVE-2020-13630 and CVE-2020-13434 look important to fix to me <lle-bout>the rest are a risk for system availability which is still important <roptat>apparently it's to preserve debug information <roptat>oh wow! it's faster, but it's also 21MB bigger! <lfam>Now I think I misread that file earlier. I see line 781 <bavier[m]>roptat: nice experiment, and good results too! :) <lfam>That's not a big deal, since there are typically no more than 2 copies of Python on disk <lfam>The only time there will be more is during python update transition periods <roptat>mh... weird the .exe are still installed <roptat>but they're not in the source anymore, so I suppose it somehow built them <lfam>Wild guess... caching of source tarball in /gnu/store? <roptat>no, I changed the snippet, so that can't be it <roptat>and -S gives be a tarball with no .exe <lfam>Maybe hidden in a compressed file? <lfam>If not... we should steal their magic Windows compiler :) <lfam>It could also be some tricky inheritance, perhaps. The Python graph is quite tangled <roptat>well, guix build -S python should give me the source used to build python, right? <roptat>however tangly the dependency graph might be <lfam>(All my suggestions are of the type "it's not using the code you think it's using") <Noisytoot>lfam: If the format had changed, the first part would change (3 -> 4) <lfam>These are wild guesses, since I don't know what your changes look like, roptat <lfam>Yeah, I figure the format won't change Noisytoot <roptat>ha! Lib/ensurepip/_bundled/setuptools-41.2.0-py2.py3-none-any.whl <Noisytoot>lfam: The second number changing means that it breaks forward compatibility by adding new features <roptat>so it contains a bundled copy of setuptools, which contains the .exe <roptat>I wonder if we can generate it ourselves <cbaines>zimoun, if you were having problems with guix weather, it might work better now <roptat>apparently, --with-lto is the reason for the increase in size <roptat>with all the other flags, but without lto, I get 15.4 and 200 for the previous benchmarks, which is in between <lfam>Might be nice to comment the --with-lto part of the package definition with something like "; 20% size increase" <roptat>so, no size increase and ~15-20% speedup <lfam>And how much of a speedup with the size increase? <lfam>It also be nice to check if Python packages also increase in size <lfam>If it was just the interpreter, I'd say the increase is negligible because, like I said, there's only one or two copies on disk, ever <lfam>Oh wait, I forgot about the wrapper packages <lfam>So, 2 to 4 copies on disk <lfam>Well, I always think storage is really cheap <lfam>My opinion, for what it's worth, is that that's worth it <lfam>And there you have the worst English sentence ever written <roptat>ok, I'll send a patch for that, then <roptat>I'm trying to use (guix build syscalls) in the snippet, but that doesn't seem to work <roptat>no code for module (guix build syscalls) <roptat>I've put it in the modules field of the origin record <lfam>Not sure, but is it imported in the file itself? <lfam>Sounds like a complex snippet! <leoprikler>lfam, nah that price goes to "Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo" <lfam>No English speaker can understand it <roptat>ok, how can I use unzip from the snippet? <bavier[m]>roptat: there's a "patch-inputs" field that you can add input packages to. <leoprikler>I had some fun with Weichen Weichen weichen Weichen weichen Weichen weichen Weichen and other German examples in the meantime :) <bavier[m]>but, actually, I think "unzip" is already part of the standard patch-inputs, so you may be able to just call it. <roptat>indeed, but unzip still gives me no such file <roptat>well, I can't use %standard-patch-inputs either because it's not exported, so I just added that to a phase <Whyvn>I am trying to setup iptables in my config.scm, I followed the example in the networking servies, but it seems with the REJECT line included at the end, non of the previous ports work. Can anyone see anything wrong with my config declration? http://paste.debian.net/1189776/ <zimoun>cbaines: Indeed. Thanks, ‘guix weather’ seems to work better. <flatwhatson>sneek: later tell lle-bout I've heard minor rumblings about guix vs tramp paths, but don't use it myself and haven't had any proper reports. Happy to help investigate, either here or as a github issue. It's possibly a regression of guix vs master, not specifically related to native-comp. <zimoun>roptat: checking the substitute avaibility on master, I note that some ocaml4.07 are missing but build. Idem for some maven. <bone-baboon>After every system regonfiguration the output says "shepherd: Service term-auto could not be started." Running `sudo herd restart term-auto` results in "Service term-auto could not be started.". Serching the Guix manual for the term "term-auto" has no matches. I also do not see it in the Base Services section of the manual. What is "term-auto"? <nckx>Generic serial port terminal listener IIRC (no fixed TTY number like ‘term-tty2’, hence ‘auto’). <bone-baboon>I am not using a serial port right now so it is probably okay if that service can not start. <nckx>It's common for it to ‘fail’ in such cases & it's completely harmless. Someone mentioned making it silent (or at least less noisy) then, but that's obviously low-priority. <Noisytoot>According to /whois lle-bout is not here, so why is sneek saying it now? <cbaines>I think because sneek wasn't told to tell them later <sneek>Noisytoot, you have 1 message! <nckx>sneek: tell Noisytoot I'm not talking to them because they dissed Jessica last period. <sneek>Noisytoot, nckx says: I'm not talking to them because they dissed Jessica last period. <flatwhatson>seems like the kind of feature that exists mainly to satisfy the developer's sense of symmetry <nckx>That implies an earlier, too. <Noisytoot>sneek: tell nckx Isn't that the same as talking directly? <sneek>nckx, Noisytoot says: Isn't that the same as talking directly? <nckx>sneek: earlier tell past nckx: Don't push that one commit, it's buggy. <sneek>past, nckx says: nckx: Don't push that one commit, it's buggy. ***jx97 is now known as jx96
<nckx>I concur. What it does matters more than which language it's in (or translates to).