<leoprikler>Mine was to add it to native-inputs, the one from jackhill is towards inputs. <leoprikler>So I'm at the same time asking whether my fix was wrong and it should have been inputs. <jackhill>leoprikler, nckx: I didn't have any particular reason for putting it in inputs (and I didn't test cross building). I don't know enough about the schemas. <nckx>leoprikler: I'm with you on native inputs, didn't see jackhill's comment until now, hence confused. <jackhill>Except, the failures were in tests, not build, but I didn't look closely enough to tell if there were used in the test scripts or my the executables under test <nckx>Honestly as long as the test passes and there are no references kept to g-d-s it doesn't actually matter. <leoprikler>The failure indicates, that the test programs want those schemas to exist during their own runtime. <jackhill>ok, no objections from me for native-inputs <nckx>I don't think you did that at all. <jackhill>nckx: :) well, if I hadn't said anything y'all could have just pushed the fix instead of spending all this time talking about it, but I guess the talk results in higher quality even if the end result is the same code as before. And I learned something, so that's worth a lot, thanks! <leoprikler>btw. pre-existing packages have a mix of gsettings-desktop-schemas in {inputs,native-inputs,propagated-inputs} and I'm sure there's a reason for each of them <jackhill>do we know what changed to cause gupnp and appstream-glib to start breaking? A dropped propagation somewhere? <leoprikler>I assume it came from wip-ungrafting, at least the timestamps seem to check out. <leoprikler>(It was merged one day ago and latest failure lies 8 hours in the past.) <leoprikler>However, I don't fully understand it myself and am likely wrong. <leoprikler>okay, gnome just finished building, so it's just those two packages between us and happy users <mhj[m]>Awesome. I'm a user who likes to centralize everything and build from one file, the config scm file. Anyways, I don't use the guix install method to obtain user profiled packages, and I like to keep to a minimum any Nix and Flatpak packages I install. Basically, I just enjoy the fact that Guix is exactly what I'm looking for in an OS :D <apteryx>do we have something like a fail2ban service readily available for Guix System? My sshd is getting hammered (at least it's not accessible via passphrase, but still) <apteryx>The IP is 111.160.23.206, from South Brisbane, Australia (according to whois) <mhj[m]>I just searched for fail2ban in the repos, and I didn't see any package for it. I suppose that's one thing that could be ported? I do recall you can set firewall rules using the IPTables or nftables services tho <mhj[m]>I just don't know of any options to blacklist an IP <leoprikler>mhj[m]: not Guix-specific, but "/sbin/iptables -I INPUT -s 1.2.3.4 -j DROP" <roptat>civodul, I pushed the Slovak translation and modified berlin to automatically redirect to it according to the browser's language <cybersyn>i'm not completely sure what guix-home-manager does, but my vague understanding is that it synchronizes a user's home with their profile? Upon googling I saw its a concept derivative of nix. I asked about using nix to explore possible guix developments, but nobody replied, is there something non-gnu about nix that sets it outside of discussion limits? <leoprikler>guix-home-manager makes your home mostly static for lack of a better term <roptat>cybersyn, there's actually two implementations: guix-home-manager and guix-home, which are very similar <leoprikler>put simply, you manage parts of your home as though they were packages and services <leoprikler>jackhill: for transparency's sake, I've sent v3 to the ML <cybersyn>what are the differences between home-manager and home? <apteryx>mhj[m]: fail2ban is just a script IIRC <vagrantc>gah. something triggered rebuilding the linux-libre tarballs ... :/ *vagrantc wonders if a reasonable compromise would be to use the linux-libre tarballs from fsfla.org on armhf/aarch64 at least <vagrantc>it is just too painful to regenerate with the frequent kernel updates plus whatever dependencies get changed... <leoprikler>wouldn't compiling the kernel afterwards be way worse? <apteryx>vagrantc: as I wrote in the past, it's been discussed and agreed to use the git checkout of linux-libre, which was made specifically for Guix; it's just nobody volunteered to do it yet. <vagrantc>several hours to generate two tarballs, only ~1 hour to build the actual kernel <vagrantc>apteryx: in my experience that wasn't hugely better than the current appraoch <apteryx>it shouldn't take hours unless you're on a 56 k modem :-) <vagrantc>it takes long enough that substitutes are almost never available for aarch64 for the tarballs, let alone the kernels <vagrantc>the tarball patching process takes long enough that it typically times out on aarch64 <apteryx>I meant, when we change to use the Git repo of linux-libre <apteryx>and no longer cleanup the linux sources ourselves <pkill9>why does it take so long to patch the linux source? <vagrantc>apteryx: yeah, that would probably go faster, although it's most disk usage ... ~600MB git repository rather than a <100MB tarball <vagrantc>pkill9: it's not the patching so much as the checking for blobs <roptat>cybersyn, sorry for the lack of response, I'm a bit tired ^^'. home manages a bit more that home-manager right now, though I suspect the goals are similar. home-manager manages files in ~ in terms of "services", and guix-home does a little more than that (I think it can manage user services, ...). home-manager takes the approach of making the whole home-directory a store item (which is a bit inconvenient, but "cleaner"), whereas guix-home targets specific files <vagrantc>i am admittedly running on aarch64 machines, which aren't particularly fast ... but even when running on x86_64 hardware, it still takes unpleasantly long <apteryx>pkill9: you'll want to look at linux-libre scripts. We run the one that cleans the linux sources, and also the check that rescans to make sure no bad signatures were left in <vagrantc>apteryx: i never figured out how to do a truely shallow checkout ... the checkouts always took hundreds of MB of space ... <leoprikler>I think we could solve this issue with faster regexps :P <apteryx>vagrantc: I think that's because linux sources themselves are huge <apteryx>unpack that tarball and you'll see something around 1 GiB <vagrantc>apteryx: that's plausible, nevertheless ... <vagrantc>i guess it's time to ... take it to the list :) <vagrantc>i guess a git checkout of several different versions would deduplicate well in the store ... <vagrantc>i wish there was a way to do a "proxy" so you could just have a cache of the git repository as a local checkout, rather than re-downloading it for the entire store for each version <vagrantc>using the guix hashes should prevent misbehavior there <vagrantc>that would benefit all git based packages significantly <vagrantc>ok, pinebook-pro should work reasonably well on git master now! :) *vagrantc waves goodbye to the wip-pinebook-pro branch <vagrantc>u-boot gives you a working boot menu you can see *on the screen* (as opposed to serial console only) and the kernel also displays *to the screen* and things basically just work <bone-baboon>mariabd is failing to build for me. It fails because of one failing test `perfschema.socket_connect`. <jiby>Hey y'all, guix newbie here. I'm packaging my toy Rust app on Guix, and am surprised: Despite stating #:tests? #f the dev-dependencies are still being fetched? <raghavgururajan>> leoprikler: Hmm, what's the rationale between inputs vs. native-inputs for gsettings-desktop-schemas? <raghavgururajan>If g-d-s only required for tests, then it can be native-inputs. if its referred by package's library, then inputs. <raghavgururajan>> nckx: raghavgururajan: OK. It's just striking that several ‘gnome’ inputs no longer build. <raghavgururajan>All of them gave same error or different. Anyway, I'll take a look tomorrow. :) <jiby>I'd expect dev-dependencies to be only for running tests = unnecessary in my case. I'm expecting to be forgetting an edge case, and curious to know what it is. <raghavgururajan>nckx and leoprikler: Sometimes, the package's test fails with missing schema error. But that missing schema might be its own schema. In that case, the solution is to move 'check after 'install and extended env-var XDG_DATA_DIRS to include [out]/share. *raghavgururajan + zopiclone = 😴️ <Aurora_v_kosmose>Trying to use a local clone of guix behind a dumb http endpoint, getting: guix pull: error: Git error: invalid content-type: 'text/plain; charset=UTF-8' <apteryx>vagrantc: about a cache for git checkouts, yes, that could be nice <apteryx>but with shallow git clones I'm not sure it'd be useful for the majority of cases <apteryx>it'd probably be useful for large repos like that of linux-libre indeed <bone-baboon>Is there a command I can use to get a list of all the packages in a system configuration that depend on a specific package? <vagrantc>apteryx: yes, for smaller repositories it may not matter, but even small repositories with a lot of history would benefit significantly <vagrantc>apteryx: a cache and/or proxy sort of thing... <vagrantc>almost done writing up an email regarding linux-libre source tarballs touching on these issues... <apteryx>leoprikler: nice set of emacs changes landed to master! <apteryx>vagrantc: OK! Hopefully that'll motivate me to bring closure to #43160 (which after much thinking would favor as a resolution to use the Linux-libre git repository directly) <bone-baboon>I just had a friendly reminder by Guix to garbage collect because of low disk space. This is a nice feature. <vagrantc>apteryx: would be nice to get that fixed, yes. <vagrantc>apteryx: though that largely seems to do both things; deblog locally and compare against linux-libre tarballs ? <apteryx>sneek: later tell vagrantc that was the original idea; now the idea is to no longer do our own deblobbing, simply fetching pre-cleaned linux-libre <apteryx>from linux-libre upstream, as we used to (the reason we had stopped was that their tarballs was volatile; their git repo was setup expressly for Guix) <inklesspen>Hi, I have just installed Guix on top of "Debian Buster" (really Raspberry Pi OS, but it's _mostly_ buster-ish) and I've spent the last couple of hours trying to get something working that I think _should_ be possible. I'm used to tools like python-build (https://github.com/pyenv/pyenv/tree/master/plugins/python-build), GNU Stow, direnv, and Python's venv system. <inklesspen>Specifically, I have an app I'm working on that requires both Python 3.9 and a more recent version of pango than what is available in the buster repo, so I thought, hey, maybe guix can help me. <inklesspen>But guix doesn't have Python 3.9; it just has 3.8. (Looks like 3.9 will be in the next release, but I haven't figured out how to get that now.) Normally, I would try using python-build to install it somewhere that doesn't conflict with whatever Python is available in package management, but that doesn't work well under Guix, and Python virtualenvs don't quite work right either, it seems... <inklesspen>I'm informed that guix environments can do a lot of the things virtualenvs can do, but I can't figure out how to pip install an arbitrary Python package inside one such that I can import it when running Python. (Yes, I know, Guix has a handy-dandy way to make a Guix package out of a Python package, but I'm still in the middle of hacking things together and I'm not ready to formalize everything.) All I can do is install in the --user directory, which is <inklesspen>any advice on (a) install Python packages inside a guix environment and/or (b) install Python 3.9, would be very welcome. thanks! <Noclip>inklesspen: Just installing python somehow isn't what guix is made for. If you setup guix environment correctly it should of course be possible to install build/install python 3.9 inside of it but then guix won't be aware of that python installation. ***sneek_ is now known as sneek
<inklesspen>i honestly don't care if guix is "aware" of it or not. i just want to get python 3.9 such that i can build a c extension that uses guix's cairo and pango and also i can install packages using pip. <Noclip>inklesspen: So you also don't want to package your project for guix? <inklesspen>i need you to please understand that i have been using guix for all of five hours and i have been very confused the whole time. the project is still in the prototyping stages. i am trying to install the dependencies so i can test my prototype. <inklesspen>my understanding is that packaging a project for guix is something that comes _much_ later in the process <Noclip>inklesspen: Which 3.9 do you want? <merazi>I think I'm drowning in a glass of water, but I'm really lost ;( <Noclip>inklesspen: Building phase succeded, hopefully ready soon. <Noclip>inklesspen: Here is the command to build python 3.9.4 "the guix way": <Noclip>inklesspen: It's still not done on my machine so I can't fully say if it will work. <inklesspen>but i still will need to figure out how i can do the equivalent of 'pip install -e .' inside a guix environment, and have it do something useful and not wrong. <Noclip>inklesspen: You can't (or at least shouldn't) install something from inside the guix environment. <inklesspen>ok, so how do i develop a python package in a guix system? <Noclip>You should instead tell guix to create an environment with that software already installed in it. <inklesspen>but while writing it i also want to run portions of it to test <Noclip>Guix will then build/install that package and create an environment where the package is available. <inklesspen>the usual way to do this is to pip install -e ., which installs the current working directory in editable form (so that changes to the current working directory will get picked up by the python interpreter) <Noclip><inklesspen "the software does not yet exist"> Guix will build it then before creating the environment. <inklesspen>because i am still in the process of writing it. <inklesspen>and guix is not yet, as far as i am aware, able to write my source code for me. <Noclip>inklesspen: That is the command you are searching for: <Noclip><inklesspen "and guix is not yet, as far as i"> Yea, that feature is still work in progress ... <inklesspen>btw i had to do --with-source on my machine, not --with-sources <leoprikler>raghavgururajan: thanks for the detailed info. Do you happen to know whether the affected packages (appstream-glib, gupnp) would also work with the "before check" phase you described <Noclip><inklesspen "btw i had to do --with-source on"> Ahh sorry, I misstyped that. <Noclip>By the way, it's still building ... <inklesspen>but i still need the ability to do 'setup.py develop' or 'pip install -e' for my code under development. i cannot sit through guix building a new environment every time i want to test an iteration of my code. <leoprikler>if you invoke the command twice with the same parameters and same channels, it'll produce the same output and you can quickly switch into the environment <Noclip>inklesspen: You can run the guix build or the guix environment command after each other, run just one of them or both at the same time. <inklesspen>do you seriously rebuild the environment every time you want to iteratively test a program you're writing? <Noclip>Just don't abort them before they are finished otherwise you will need to start from 0 again! <leoprikler>I personally have some software project, in which I absolutely always rebuild the environment whenever dependencies rebuild. <inklesspen>i'm talking about the source code of your project. <leoprikler>You don't need to rebuild the environment when only the source code changes. <leoprikler>The environment only depends on the inputs => as long as those are the same, you're fine. <inklesspen>let's say i am developing a python package. it would be bad practice to try running the source files directly, like "python mypackage/src/foo.py". instead, you should install the package in "editable mode", which basically adds a python package that just points at your source code. then i run "python -m mypackage.foo" <inklesspen>i have been trying to explain this for several minutes now. <Noclip>inklesspen: "(Looks like 3.9 will be in the next release, but I haven't figured out how to get that now.)" <Noclip>We need to get that package definition, that will hopefully work then! <inklesspen>it is not really "installing" in the sense that installing a markdown library is installing. it is just putting a virtual python package on the pythonpath so that i can start an interpreter and import the module i am writing. <leoprikler>Hmm, we Guile people prefer ./pre-inst-env scripts for that <inklesspen>i have found a lot of references on "Here is how to turn a finished python package into a guix package" but i have found _nothing_ on "here is how to develop a python package from scratch" <leoprikler>./pre-inst-env would bind PYTHONPATH (and what other variables you have) for one command invocation only. <leoprikler>so with a normal pip setup, you could write one, that points to build/whatever <leoprikler>(I'm not too sure, what happens with the newer setup, but IIUC that one is more hackable already, so no problem) <leoprikler>I've also seen "python" packages, that build with meson, with a "meson run" to run them. <leoprikler>This is not a matter that requires stateful anything. All you need is to temporarily bind some environment variables. <Noclip>leoprikler: Wouldn't running guix environment without --ad-hoc be what inklesspen means? (Assuming there would be a package definition for his work in progress software.) <inklesspen>(her, not his. and why do i need a package definition for a work in progress program i am still writing?) <leoprikler>That would set you up for development, but you still need a little snippet to add your developed package to PYTHONPATH. <PurpleSym>inklesspen: Editable mode works fine for me inside a Guix environment. <leoprikler>inklesspen: You don't. You can also construct your environment with --ad-hoc python python-xyz python-abc ... <leoprikler>But it makes sense to write a guix.scm, that you can version control and easily share with others. <Noclip>Oh no, I tried to keep any he/she/his/her out of my text but then forgot that half way trough ... in anonymous chats this is always a bit difficult. <Noclip>inklesspen: I assume writing a package definition for guix as early as possible will save you some work later. <Noclip>leoprikler: Mhh, I wasn't really aware that this exists, thanks! <Noclip>(I'm not a native english speaker.) <leoprikler>Neither am I, but the trans community has made some noise about it and I find their arguments hold water. <inklesspen>(personally i find ve/ver/vis (as used by Greg Egan in several of his books) to be more harmonious to the ear, but practically speaking singular they has won the day) <inklesspen>ah, back in the day he was one of the scifi writers you could expect to have recognized in *nix channels. but the world moves on. <Noclip>Ah in 1992 Greg wrote a novel called "Quarantine". Greetings from 2021 xDD <Rovanion>Does anyone happen to know how to install the `ecrm1200' latex font? <Rovanion>texlive-fonts-latex does not contain it. <irfus>uh, so updating packages, 'tdlib' has been in "check phase" running tests for several hours <irfus>is this normal for this package? Is there a convenient way to not run the tests while building? <irfus>argh, I see mention of this in recent logs. So this is *normal* -_- <leoprikler>irfus it's a bug that was caused recently, --without-tests should fix it *raghavgururajan checks CI for build-failures related to g-d-s. *raghavgururajan forgot that he is still a CI noob <raghavgururajan>nckx or leoprikler: Is there a way to make CI list build-failures based on some criteria? <Noclip>raghavgururajan: Can't you list all failures and filter them with something like grep? <raghavgururajan>On I remember leoprikler mentioned gupnp. Let me look into that first. <Noclip>raghavgururajan: The only reason I see to not do it that way would be if listing all failures would take too much time or resources. <leoprikler>raghavgururajan: sadly no, that would take some very advanced AI <Ikosit>Is it normal, that emacs doesn't use the env variables from the shell it was started from? Bc it seems i can't use it with guix-environment <jbv1[m]>hi guix ! A question: how can I make utf-8 locale available during tests for my package ? <jbv1[m]>I have tried (setenv "GUIX_LOCPATH" (string-append (assoc-ref %build-inputs "glibc-locales") "/lib/locale")) but it does not work <leoprikler>jbv1[m]: Guix should assume a UTF-8 locale if you build with gnu-build-system or anything derived from it. <leoprikler>Ikosit: I recently made a commit with that effect, but IIRC it should prefix variables. Did I make a mistake? <jbv1[m]>hmm it is what I am using (trying to update julia to 1.6) <leoprikler>Also emacs should work fine even in pure environments. I tested that :( <jbv1[m]>the line that fails is "setlocale(LC_CTYPE, "en_US.UTF-8")" (in a c part of julia) <leoprikler>we effectively do the same in guile code, what is going wrong in julia? <jbv1[m]>no clue... but that means that I should not try to waste time playing with environment variables <tissevert>still haven't had time to test the rc but I look forward to that ! <PurpleSym>Is it somehow possible to match newlines in substitute*? <leoprikler>Sadly no, you'll have to write your own matcher for that or use diffs. ***pflanze is now known as tanze
***tanze is now known as tinga
<apteryx>roptat: It seems the gettext autogenerated po/guix/Makefile (from Makevars) will run guix.pot-update because: all-yes: stamp-po and stamp-po: $(srcdir)/$(DOMAIN).pot <apteryx>wonder if we can somehow control that from Makevars ***Akk is now known as Guest51631
<apteryx>so gettext wants to create the .pot file when its missing, that's why it runs $(MAKE) $(DOMAIN).pot-update on the first make invocation <apteryx>their doc suggests two schemes are acceptable for versionning .po files: with or without the .pot file. So one easy but not ideal solution would probably be to version the .pot file <Guest51631>I have been thinking on switching to guix from void for sometime now. One of my major issues with fsf approved distros is that they do not support non free blob drivers and because i use intel wireless, my wifi doesnt work. is there any way to get it to work in guix atleast <leoprikler>Could it be, that guile-json became a necessary component of Guix? I believe we only use it for SWH, but I can't seem to write a correct package description for Wisp currently. <leoprikler>Guest51631: You can absolutely get Guix to install non-free software, but as a matter of policy, we don't encourage you to do so and won't give you support. <Noclip>Guest51631: You could use the default (partly non-free) kernel instead of the libre one. That would give you the needed blob drivers. <apteryx>Guest51631: you won't get support here to have proprietary software to work with Guix; the common solution to that problem is to buy one of the cheap USB dongle available that works with free drivers; could that be a reasonable solution for you? <Ikosit>And in fact it's an feature (not a bug) of doom emacs <roptat>apteryx, I don't really know how that Makefile is generated, but if you find a way to prevent rebuilding the pot files on first make invocation (while still being able to generate them on demand), that's great <sneek>Welcome back roptat, you have 1 message! <Ikosit>leoprikler: On installing doom it asks if it should generate an envar file with the current env variables <Ikosit>"This is useful in cases where you cannot guarantee that Emacs (or the daemon) <Ikosit>will be launched from the correct environment (e.g. on MacOS or through certain <leoprikler>I think in Guix we have better tools to manage environments, also those files are likely to get stale. <roptat>apteryx, yeah that patch is to prevent generating changes under po/doc only, it doesn't take care of po/gix <leoprikler>Should we disable that feature or at least discourage its use? <Noclip><leoprikler "Guest51631: You can absolutely g"> Would giving support for non-free software in this chat as a non-maintainer break any rule/policy? <leoprikler>Even as much as mentioning which projects exist out there is bending our rules. You won't get banned from IRC for doing so (once or twice), but we certainly don't want you to do it. <apteryx>roptat: OK! That's probably useful once po/guix is taken care of also :-) <apteryx>the problem stems from the make ending up running 'make guix.pot-update' under po/guix <Ikosit><leoprikler "Should we disable that feature o"> Was this a reply to me? <leoprikler>yep, should we disable (by default) envvar files in our doom package? <Ikosit>Bc, doom is essentially just an emacs configuration <Noclip><leoprikler "Even as much as mentioning which"> Ok, that seems a bit extreme to me. Can you give me a link to that rule? <leoprikler>Ikosit: we have emacs-doom-themes and emacs-doom-modeline at least. <Noclip>leoprikler: Aren't those rules only applying for the official distro maintainers? <leoprikler>As far as I understand it, when it comes to advertisements for certain kinds of software, they very much apply to the channel as a whole. <leoprikler>I don't think anyone wants to see this become an advertisement for all kinds of non-free software barely made runnable on Guix with a lot of Wine. <Noclip>leoprikler: I don't think you have a reason to be afraid of this xD <nckx>Noclip: They apply to anyone participating in community channels, from maintainers to PotentialUsers. <roptat>apteryx, actually that patch is incorrect, it has other side-effects. Instead I think we should simply decouple po files from pot files: we'd have a doc-pot-update (useful for weblate) but no doc-po-update anymore, since po updates come from weblate (it has never been useful for the TP either actually) <nckx>raghavgururajan: Hi! <the solution is to move 'check after 'install and extended env-var XDG_DATA_DIR> do you mean a simple SETENV during the tests only, or actually wrapping the installed executables? <Noclip><nckx "Noclip: They apply to anyone par"> Ok, good to know. I wasn't fully aware of this before. <Noclip>nckx: Isn't this in conflict with the code of conduct? *nckx scooby-doos confusedly <Noclip>For example: "Being respectful of differing viewpoints and experiences" <Noclip>"Gracefully accepting constructive criticism" <nckx><Ok, good to know. I wasn't fully aware of this before> Part of me reacts ‘yeah, we should note that in the topic’, a larger part thinks the topic is already huge & nobody reads it anyway. It would be there only to point at ‘see, we told you’ and that's not needed here. <nckx>Noclip: Can you elaborate on how not promoting software we consider harmful to users conflicts with that? I genuinely don't see it. <Noclip><nckx "<Ok, good to know. I wasn't full"> Yea, those thoughts seem reasonable to me. *nckx → AFK but will catch up. <mhj[m]>Hi all, good day! How're y'all doing? Anyways, just a quick question. I have one of those USB dongles. It's a 8188eu wireless dongle. In any case, when I plugged it in, despite it supposedly being a totally free driver, the libre kernel Guix uses rejected it. Was it recently declared non-free or something? <Noclip>nckx: I think you would have to change the code of conduct in the following way for this: <Noclip>"Being respectful of differing viewpoints and experiences [as long as they don't criticize software freedoms]" <Noclip>Same for "Gracefully accepting constructive criticism" <bone-baboon>I would appreciate some help completing the setup of a substitute server. When I try to pull from a substitute server I have set up I get a authentication error. I would like to get this working so that some of the computers I have Guix installed on with smaller system resources can take advantage of the build from source work of a computer with relatively more CPU and RAM. Here is further information on what I have done <roptat>mhj[m], how did the kernel reject it? did you see some kind of message? <mhj[m]>Yeah, lemme put it in again and I'll paste the dmesg output <Noclip>nckx: So let's say I would be a fan of non-free software (I'm not!) and would say something like "I think the non-free guix channel xyz is awesome because it contains so much cool non-free software." <cbaines>bone-baboon, a substitute server is for serving substitutes, guix publish doesn't support serving Git repositories (which I guess is what guix pull is expecting) <mhj[m]>Weird, cuz on Wikipedia, they list it as a free driver <mhj[m]>That's what I was going by when I bought it <Noclip>nckx: I think such a case would definitely count as viewpoint and eventually also as constructive criticism and so should be protected by the code of conduct. <roptat>mhj[m], the driver might be free, but it seems to require a non-free firmware <mhj[m]>Ahhh, thanks for the clarification! <roptat>or their is a free firmware that's not part of linux (and therefore linux-libre) <mhj[m]>I guess I'll use h-node as a guide from now on, thanks for sharing the link to that site <Noclip>nckx: (As constructive criticism I understand every criticism which is delivered with a somewhat reasonable argumentation and without offensive/insulting language.) <leoprikler>Noclip: it's not constructive criticism, because Guix is (partly) founded on the stance, that non-free software is evil (forgive my harsh choice of words, I'm a bit exhausted) <mhj[m]>leoprikler: What anime ya into? For me it's mecha and slice-of-life <Noclip>leoprikler: "that non-free software is evil" This is the viewpoint of the fsf, right? So it applys "Being respectful of differing viewpoints and experiences" ... *Ikosit watches almost all anime <Ikosit>or rather all genres, apart from horror <Ikosit>mhj: What's your favorite anime? <mhj[m]>Hmm, it's hard to point to just one. Maybe FullMetal Alchemist: Brotherhood or Girls Last Tour Ikosit <Ikosit>I never heard of girls last tour before <bone-baboon>cbaines: So this highlights that I do not have a good understanding of what guix pull does. <mhj[m]>Girls Last Tour is basically about these 2 girls trying to survive what amounts to the slow end of the world <Ikosit>At the moment AOT is my favorite <Ikosit>At second place is maybe Love Is War <mhj[m]>I've seen Attack on Titan, most of the first season that is. Haven't seen Love is War yet. <Ikosit>Love is War literally Comedy on 200% <Ikosit>And AOT just gets better with every season *Ikosit has to stop recommending ppl anime <mhj[m]>Oh yeah, and my third favorite anime would be Gundam Unicorn. It nicely pieces together the time between the original Gundam and Zeta I think? Also Gundam Thunderbolt and Gundam the Origin are good too :D <Ikosit>Lol, the first Gundam is from 1979 <leoprikler>There are some good contenders this season, but I feel it's going to be a close race between Zombie Land Saga Revenge and Aoi Yuuki bullies the slime. <mhj[m]>Speaking of Aoi Yuuki, new Madoka movie is gonna be hype <Ikosit>leoprikler: But at least in my perception this season is very weaker that the last <Ikosit>maybe not in quantity, but in quality <leoprikler>But honestly, I'm so happy that Zombie Land Saga got a sequel, I won't complain. <Ikosit>Guess i should check that anime out as well <Ikosit>But i'm the most hypped about ⒿⓄⒿⓄ 6, AOT 4-2 and Love is War <Ikosit>All of those could potentially air this year <leoprikler>Also if you're into Mecha SSSS.Dynazenon is a thing this season. <leoprikler>I'm also looking forward to more Radiant (not this season, but hopefully this year). <bone-baboon>cbaines: So I looked an the substitutes section of the manual again. I just tried `guix system --dry-run --substitute-url=http://<substitute-server-ip>:<port> reconfigure configuration.scm` this tells me that it is going to build a lot of software and what I want to do is just download it from my substitute server. I deliberately set it up so that both computers have the same list of packages in their system configuration <bone-baboon>is because my substitute server is not able to finish reconfiguring itself because of bug#48151. It also warns me that I should do a guix pull. <bone-baboon>When I run `guix pull --no-substitutes --dry-run` it starts build a lot of software that I would like it to download from my substitute server. <bone-baboon>So I am now further ahead than I have been so far with setting up a substitute server. Looking at the terminal I ran guix publish in I can see many lines of "GET /<hash>.narinfo` that was caused by `guix system --dry-run --substitute-url=http://<substitute-server-ip>:<port> reconfigure configuration.scm`. <roptat>bone-baboon, did you authorize your substitute server's key? <leoprikler>Can someone explain "warning: connection security to hg.sr.ht is disabled per current settings; communication is susceptible to eavesdropping and tampering" <leoprikler>I don't see that string anywhere in Guix, is it a Guile warning? <bone-baboon>roptat: I have run `guix archive --authorize < <substitute-server-public-key>` on the computer that is trying to download from my substitute server. The substitute server's public key is in /etc/guix/acl of the computer that is trying to download from the substitute server. <roptat>maybe you don't have the same version of guix on both sides, so some derivations are missing on your substitute server? <Aurora_v_kosmose>The key required for the guix-install.sh script appears to have changed while the manual documentation didn't update. <bone-baboon>So I think the mariadb bug#48151 that is stopping my substitute server from reconfiguring may be the issue. To verify this is there a command I can run to find out all the packages in a system configuration that depend on mariadb? Then I could comment out those packages in the substitute server's configuration and reconfigure with `--no-substitutes`. Then comment out the same packages in the configuration on the system th <bone-baboon>from the substitute server and reconfigure using `--substitute-url`. <cbaines>bone-baboon, you can test substituting something from one machine to the other with the guix build command. First, find something in the store which is present on the machine running guix publish, and absent on the machine you want to fetch substitutes from <cbaines>bone-baboon, then run guix build --substitute-urls=... /gnu/store/... on the machine you want to try fetching it <leoprikler>BlackMug: I've already pinged the author of the commit, that seems to break stuff <nckx>It might actually be fixed now. <BlackMug>btw i want to ask, if X package failed to be built will Guix keep moving and build other packages and leave the one with error to the end? <BlackMug>or all the process will fail until every upgrade is correctly downloaded,built... <leoprikler>BlackMug: it might possibly build unrelated packages, but it won't complete the operation <BlackMug>since guix is on rolling upgrade it would be very bad to fail the entire process of upgrading 10 packages just because one irrelevant failed <leoprikler>BlackMug: there is --do-not-upgrade for that case <leoprikler>also you can always construct (ad-hoc) environments <BlackMug>there is no in guix if x failed then dont upgrade and keep moving? <BlackMug>like for e.g icedove failed but i have other software waiting for upgrade <BlackMug>if we gonna wait each time 3-4 days because X package maintainer done something wrong <BlackMug>how we will ever make full system upgrade with too many packages on rolling bases? <BlackMug>unless manually user gonna do things which give very bad usability <leoprikler>again, for user profiles, you can do --do-not-upgrade <leoprikler>for system profiles it's more complicated, but in either case you can also use inferiors (to an extent) <BlackMug>leoprikler yeah i saw what you said before but you are making users suffer for package maintainers mistakes <leoprikler>We try to resolve such issues as quickly as possible, please cut us some slack :) <BlackMug>yes but im thinking about a feature which will reduce the impact of this issue when it happens <BlackMug>i mean automated thing which make the user happy <BlackMug>x failed , leave and keep the old version , continue upgrading the rest <BlackMug>and only the effected package with error issue will be kept until upstream fixing it <leoprikler>I don't think you will arrive at a good solution. Perhaps UI-wise you can try to build the most packages, but tbh I don't find this meaningful. <leoprikler>We do have `guix weather`, which tells you whether a package has already been built on CI. <leoprikler>this is going to be used for a "channels-with-substitutes-available", which guarantees, that you'll be happy with (a subset of) your packages <BlackMug>this solution for yeah ok fine i will do x,y,z then i will have less headache <BlackMug>but if guix targeting end user,average new one <BlackMug>you can tell 100 user who are suffering from the same thing yeah well do this to solve the default behavior <BlackMug>for normal user like what the hell why i do this why its not default? <BlackMug>anyway i appreciate your solutions but if i should be honest to make this project better these arent solutions <BlackMug>we can say yeah it is a workaround but not a real solution <leoprikler>I don't buy any speculation about the "normal user" that still takes the command line interface as a requirement. <BlackMug>what is normal use want? guix install x , guix upgrade x right? <leoprikler>It'll be a little difficult to fit them all into a lecture hall during a pandemic, but I absolutely can. <BlackMug>if guix distro fail to give that as always 100% (or trying to make it by solutions) then this distro wont ever be 100% working <BlackMug>guix install x , guix upgrade x working and if not it doesnt paralyze all my packages upgrade <leoprikler>In my personal use case (GNOME + emacs + some small packages), failure has been rather rare in the past 2 years. <BlackMug>thats even crazy from security standing point <BlackMug>ok im xfce user of guix since like 3 months or so i wouldnt say its rare i already reported many of issues <nckx>BlackMug: You're not paralysed: ‘--do-not-upgrade icedove’ does what you want. Returning success after doing only a random subset of things the user requested, is wrong. Returning failure but modifying their profile into a state they didn't ask for is also wrong. I'm not aware of any package manager that deliberately exhibits such broken behaviour. <nckx>...not really an argument anyway: regardless, Guix shouldn't. 😛 <leoprikler>nckx: Well, traditional distros leave your hard disk in a broken state <leoprikler>In which half of the packages are installed, half of them aren't, and some packages are broken. <BlackMug>nckx because guix act differently than what other package managers doing so its bad comparison <nckx>Sure, hence ‘deliberately’. <leoprikler>I've had this with Debian, I've had it with Gentoo. <BlackMug>i wouldnt compare guix to apt , to different things <nckx>BlackMug: Guix is a transactional package manager, this would make it not so? <BlackMug>> You're not paralysed: ‘--do-not-upgrade icedove’ <-- is this a message in the error will be produced if the process of upgrade failed? <BlackMug>or you expect every user to jump to read documentations and come here to tell you his suffer? <nckx>Now you're moving goalposts. If you want a hint, say so. That's different than defaulting to broken behaviour. <nckx>Silently skipping failed packages is not. <leoprikler>Also, we have command auto-completion and --help <BlackMug>hmm why silently skipping the package failure build? show the exact same errors but dont prohibit other packages from getting upgrades and handled by guix automatically <- i dont find this bad unless there is something bad im not aware of it <leoprikler>Let's say you wanted to jump from Icecat 3 to 85. <leoprikler>Oops, the build failed, guess you're stuck on 3 then, deal with it lmao. <apteryx>roptat: what kind of side effects do you see with your translated manuals patch? <leoprikler>The current state is: "Holy fuck, why does this not build? Here's a log! Read it!" <leoprikler>No one will read it if you continue to build other packages. <BlackMug>same as now when i try to upgrade with fail package to upgrade <BlackMug>from this side nothing is needed to change <leoprikler>"Yeah, so I know you asked for X, Y and Z, but I kinda forgot about Y and Z is really not possible this semester…" <leoprikler>Fail early and fail hard is a good model. It helps prevent bugs further down the line. <nckx>BlackMug: For example, which exit status should ‘guix upgrade foo bar ding dong’ return after randomly upgrading a few but not all of those packages in the profile? <leoprikler>If you have to manually invoke --do-not-upgrade=icecat --do-not-upgrade=linux-libre --do-not-upgrade=libreoffice --do-not-upgrade=this-package-that-keeps-failing-since-2014, maybe not you but *someone* will be motivated to change things. <nckx>(0.5 of course, but no, stupid Unix.) <BlackMug>leoprikler not sure how this is a contradiction to what im saying as im not talking about the error message as it can be kept the same <BlackMug>nckx everything can be kept the same as #48140 error showing <leoprikler>48140 is a huge bug, that would fuck up half of your system anyway <BlackMug>but instead of cutting all other fine to upgrade packages due to this error just make them upgraded while showing this error <leoprikler>There is no sane way to account for it other than fixing it. <nckx>BlackMug: What can be kept the same as what? <BlackMug>leoprikler yeah leave that bad package as it is no body said or talked to fix it in any other way except by waiting for the maintainer <BlackMug>nckx the error package that has issue of building and whatever rely on it which is icedove <BlackMug>why these kept back from upgrading while the issue is in icedove <leoprikler>The bad package is the code, that downloads all your packages. <leoprikler>(Well, this is somewhat exaggerated, some downloaders worked fine, but still) <BlackMug>so its not icedove specific issue? (i mean only effecting it) <nckx>BlackMug: I don't understand, sorry. I asked which exit code should be returned, that is how you define success and failure. Does ‘guix pull && guix upgrade icecat dong && icecat’ launch a known-vulnerable icecat or an up-to-date one? <bone-baboon>nckx: I would like to reconfigure a substitute server but it is running into a mariadb bug (bug#48151). Would `guix system --no-substitutes --do-not-upgrade=mariadb reconfigure configuration.scm` allow my substitute server to complete it's reconfiguration? <nckx>No, bone-baboon. System profiles don't work that way. You can't mix & match & here take this old thing I found & shove it in there anyway & stuff. Sorry. <bone-baboon>In this case mariadb is a dependency of some package(s). I am not sure which one yet. <nckx>I was unable to actually view your log due to #48160, let me try again. *nckx foolishly closed the window then never got it to work again. <bone-baboon>nckx: I will attach compressed logs in the future. Thanks for the suggestion. *nckx tries to remember debbugs URL format. <nckx>No problem bone-baboon. Your mail just tested an edge case 😉 <bone-baboon>Is build failures the reason why the offical Guix substitute server does not provide all the packages and users sometimes need to build their own? <BlackMug>nckx improvement to it can be: please report the issue and if you want to proceed use --do-not-upgrade icedove *samplet is getting up to speed on bug #48152 (guix build download) <bone-baboon>How does the official substitute server work around packages that do not build successfully? <nckx>bone-baboon: <Is build failures> Yes. Clients poll substitute servers as an optimisation and fall back to local builds. <apteryx>nckx: if by 'work' you mean display a page, yes <nckx>bone-baboon: It doesn't work around them. They are marked as failed, and that's the end. <BlackMug>nckx what i have suggested in my previous speech: --do-not-upgrade should be handled by guix package manager automatically whenever there is a failure to x package , and after finishing all other packages upgrade (icecat,tor..etc) will show the error message normally shown in https://issues.guix.gnu.org/issue/48140/attachment/0/1 <bone-baboon>nckx: So the official substitute server is not doing a system reconfigure. It is instead doing something like guix build sequentially on a list of packages? I am just trying to figure out how I should be managing my build server. <nckx>BlackMug: I already said that's a good idea. Guix can display a hint and even give the ‘--do-not-upgrade’ command line to use. That's not what you were advocating above, and I never got an answer to my exit status question. <ruffni>i'm trying to define and install a package. guix replies: `command "unzip" failed with status 127`. i can unzip the path given without a hassle. what am i missing? <nckx>ruffni: Add unzip to native-inputs. 127 means command not found. <BlackMug>nckx then sorry i might missed understanding your question, can you ask it again <nckx>bone-baboon: Exactly. The build server does run Guix System, but it doesn't reconfigure itself on each commit. There are ‘system tests’ that test full systems, and they will fail if a dependency did. <nckx>The machine is configured by hand by admins. If it fails, they get to fix a package like everyone else :) <nckx>BlackMug: Your suggestion above was that ‘guix upgrade ding dong’ would upgrade ding even if dong failed to build, is that correct? My question was what ‘guix upgrade ding dong; echo $?’ would print in that scenario. <nckx>It's easy to define for ‘--do-not-upgrade dong’. <iskarian>what is the proper way to make a .patch file for a package? <nckx>iskarian: Do you mean a patch against a package's source code, or a patch to add a new package definition to Guix itself? <BlackMug>nckx correct that was my suggestion, ding upgraded from version 1.0 to 2.0, dong failed to build with error message blah thus not upgraded (--do-not-upgrade) <BlackMug>is this considered problem in what im describing/saying? <samplet>cvs-fetch works with Mathieu’s commits. <sneek>Welcome back samplet, you have 1 message! <sneek>samplet, civodul says: yay for Disarchive support! \o/ <apteryx>roptat: question: Why do PO files change when 'updating' them? Shouldn't this kind of update happen at the time we download new translations and be commited along? If that was the case, would running po-update not cause any spurrious changes in the tree (e.g., nothing to do) ? <samplet>We don’t have any packages that use android-repo-fetch, and svn-fetch does not fall back on download-nar, so it can stay as is. <samplet>Does anyone know something I can download with android-repo-fetch (off the top of your head)? *samplet goes off looking for adb <ruffni>if a Makefile does not define a `install` target, how do i install the package in guix? manually copy it somewhere (replacing the install phase)? <BlackMug>i cant make this working: guix --upgrade . --do-not-upgrade icedove <BlackMug>i want to make every package upgraded except icedove <mroh>BlackMug: `guix package --do-not-upgrade=icedove -u` <bone-baboon>I have run `guix pull --no-substitutes` on a substitute server and then `guix pull --substitute-urls=<my-substitute-server>` on a computer that I want to download substitutes from my substitute server. I was able to download some substitutes which is good. But it also started building packages which suprised me. Why would it be building packages? Example of packages being built instead of using substitutes include: cyrus- <bone-baboon>openldap and curl. My motivation for using a substitute server was to avoid building at all on low resource computers and have them get substitutes from my substitute server which I can make sure it has built all the packages they require. <bone-baboon>Maybe I need to start sequentially building all the packages I use on the substitute server with guix build. <apteryx>bone-baboon: do these machines share the exact same Guix version? <apteryx>or rather, since this is about guix pull, you'd want to guix pull to the same commit that your substitute server has pulled to <bone-baboon>apteryx: Guix describe show that they have different commits. What is a good way to get them to have the exact same Guix version or commit? <apteryx>the most strict way would be by using the channel mechanism; you could version your channels file <apteryx>and deploy that file to have it used on your multiple machines <apteryx>since that file is programmable, you could also query the guix commit of your substitute server programmatically and use that <bone-baboon>apteryx: So I would make channel for my substitute server and my computers downloading from it would use it as their only channel. Then my substitute server can stay up to date with `guix pull --no-substitutes`. Something like that? <apteryx>you don't need to make an actual channel, you can use the default guix channel (which is the master branch of the savannah repo), like so: (list (channel (inherit %default-guix-channel) (commit "1b792e8b5275dc010c53d91062082340431204f2"))) <leoprikler>ruffni: there are some utilities in copy-build-system but it's mostly just moving stuff around <apteryx>all that does is ensure that 'guix pull' will use commit 1b792e8b5275dc010c53d91062082340431204f2 <apteryx>putting that file on all your machines at ~/.config/guix/channels.scm will ensure they 'guix pull' to the same commit <bone-baboon>apteryx: Thank you for clarifying that. Is the commit I should be using is the one I see in the output of guix describe on my substitute server? <apteryx>that would be a good starting point, yes <ruffni>leoprikler: the package compilies with gnu-build-system. should i remove the 'install' phase and add a phase where the binary gets copied/moved to './bin'? <bone-baboon>Is it correct that for a substitute serever to serve a package to a client it just needs to have built the package and does not need to have that package installed? <apteryx>it only need to have that very package in its store <roptat>apteryx, I'm not sure I understand your question <roptat>update-po updates the po files according to the pot file. If a string has changed, it will mark it fuzzy and change the English version, if it was removed, it will comment it out, and if a string is added, it adds it without a translation to the po file <roptat>but that's not needed with our weblate workflow now (and I think it was not needed either for the TP) <roptat>so let's just drop any po-update target we have and not update them except by downloading them from weblate, wdyt? <roptat>as for the patch you re-linked this morning, it not only prevents po/doc to be updated (which we want), it also prevents us from having a rule that builds the translated manuals <roptat>I think it's better to not build the po files from the pot, as po files are not generated files (contrary to pot files). We don't want to regenerate them all the time <roptat>and we don't want to modify them, as this is the role of translators and weblate <leoprikler>ruffni (replace 'install (lambda (...) [move package to /bin])) is fine <roptat>apteryx, I think I found the right fix for po/guix: Add PO_DEPENDS_ON_POT = no in Makevars (testing now in a clean tree, seems to be working) <bone-baboon>In ~/.config/guix/channels.scm I have specified the commit my substitute server shows with guix describe as per apteryx helpful suggestion above. When I run `guix pull --substitute-urls=<my-substitute-server>` it is getting many substitutes from my server but it is still building sereral packages that are in the store of the substitute server's store including: apr, apr-util and boost (it is still building there may be mo <bone-baboon>some packages which never use a substitute and instead always build from source? ***stikonas_ is now known as stikonas
<roptat>bone-baboon, some derivation are marked as not substitutable, but apr, apr-util and boost are substitutable <roptat>maybe they're "baking"? I thought that was something with berlin's setup that doesn't happen with a simpler guix publish <bone-baboon>Maybe this is an issue with the substitute servers cache. Is there a way to force the substitute server to populate it's cache with everything that is in it's store? <roptat>apteryx, bah, wrong guess, it didn't work as expected, though that was quiet <roptat>bone-baboon, substitutes, but not sure that's the case <roptat>when you ask a substitute to berlin for the first time, it will bake it (create the compressed nar and cache it), which can take some time, so it will answer something like "I have it, but not now" and guix will build the package instead <roptat>not a good behavior I think, because it usually takes more time to build the package than bake it on berlin <bone-baboon>roptat: Is there an option to wait for a package substitute to become available in the cache? Could it output for the client that the substitute's cache is being prepared? <roptat>bone-baboon, no, there's no such option <bdju>package build failure for icedove <apteryx>roptat: eh, I had tried that too :-) <apteryx>(PO_DEPENDS_ON_POT = no in Makevars, after reading about it in their docs) <apteryx>roptat: re your earlier reply; my question may well be have been confusing, as I don't yet a good understanding of the gettext system (I'm trying to fix this by reading its manual) :-). Thanks for attempting to answer it, it does help. My observation is that when the .pot file(s) are missing, the gettext autogenerated (via autoconf) build system will run rebuilds the po files if the pot files <apteryx>changed (which they do, since they didn't exist in the first place) <apteryx>seems to come from that rule in the generated po/guix/Makefile: $(POFILES): $(srcdir)/$(DOMAIN).pot <roptat>apteryx, I think that's because we use gettext-0.18.1 (from 6 years ago) instead of a more recent (0.19.1 from 4 years ago has PO_DEPENDS_ON_POT, 0.18.1 doesn't) <roptat>but for some reason I try to change the version in configure.ac to 0.20.1 (that's what gettext --version tells me), but that fails saying my gettext is older <roptat>ah, updating to 0.19.1 seems to work <bone-baboon>I think I got the substitutes server serving all the requested packages by setting `--cache-bypass-threshold=<size-substitute-server-hard-drive>`. Are these always built?: profile.drv, guix-command.drv, guix-extra-modules.drv, guix-system-tests-modules.drv, guix-packages-base-modules.drv, guix-cli-modules.drv, guix-system-modules.drv, guix-daemon.drv, inferior-script.scm.drv and profile.drv <zzappie>hey guix! how do commands like "guix system vm" decide which guix revision will be inside the vm? What my host "guix describe" output vm "guix describe" output and current master are three different things... <ineff>Hello everyone, new guix user here, I got a (silly?) question: in nix using the command nix-env -qs is possible to query the status of a package, in particular it's possible to verify if there is a substitute for the package, is there a similar option for guix? <darth-cheney>hey all, been running guix system for a little less than a week and just realized that I have no sound! <darth-cheney>Are there general things to know about getting sound to work? What packages should I have installed? *zzappie oops I droped out for a minute <jlicht>darth-cheney: Are you using %desktop-services in your operating-system declaration? Do you know if you have pulse-audio running? <roelj>I'm trying to generate a "docker-image", but it fails with "In procedure readdir: Cannot allocate memory". I'm not a foreign distro (Fedora). Do I need to set up something special to make this work? <roelj>zzappie: Unlikely.. I have 135G of free RAM :) <roelj>But it could be that the VM it tries to create doesn't have enough memory.. How can I specify this? <roelj>zzappie: I feel very privileged about the RAM indeed <zzappie>roelj: I checked system.scm script source it seems like 256M is hardcoded <cybersyn>i'm experiencing something a bit strange where my terminal isn't printing any information during a reconfiguration, making it appear to be frozen, but then if i check in the system monitoring tool "top" i can see that the buildings are happening. I've reset my computer, but the issue persists. has anyone experienced something similar before? <roelj>zzappie: Thanks so much for checking it out! :) I'm running with a customized invocation of system-docker-image that passed "#:memory-size 4096" to see if that will work. <zzappie>roelj: If youre comfortable with doing it from the repl you can use system-docker-image procedure and pass it different memory-size <roelj>zzappie: Oh, doing it from the REPL is a good suggestion.. I now just hacked it in system.scm and use the pre-inst-env script to invoke it.