IRC channel logs


back to list of logs

<nckx>I don't think I'm reading between the lines (much :-) to think you don't like this package (in a maintenance/security sense), and you're probably right, too. The code is the worst example of Perl.
<ulfvonbelow>FWIW I've been using the ddclient service all this time and still am
<ulfvonbelow>a while back I had to specify a particular commit to get it working though
<nckx>I haven't noticed any problems either, but my IP changes only very infrequently.
<mirai>nckx: I did try to get the service up to speed at some point
<nckx>Seems like your patches were mere days too early:
<nckx>The dangers of productivity!
<ulfvonbelow>although to be fair the api for the service I use is dead simple and hasn't really changed, so even if I had to switch from ddclient, it'd be pretty easy to just use curl
<mirai>but got fed up with the config format that essentially is a sequence of commands (so something like 'daemon','foo','nodaemon','daemon') is “perfectly valid”
<mirai>coupled with the rather “hopeless” codebase (in kinder terms, you'd rather do a rewrite than maintain it) and the (now reverted) archival you can see what my enthusiasm is for it :-)
<nckx>It's palpable over TCP!
<piptown>when trying to switch the login manager from GDM to another login manager. How do I accomplish this?
<sneek>Welcome back piptown, you have 1 message!
<sneek>piptown, nckx says: Hm... 'source' implies to me that you perhaps forgot to make it executable?
<apteryx>has there been CUPS regressions recently?
<apteryx>someone complains their printer is not working (again)
<apteryx>maybe since PAM support has been reinstated for CUPS; cups-minimal can't work (as it lacks PAM)
<viaken>nckx: I'm trying to work out how best to keep my Guix configs tidy. Do you keep your home/system/packages all in the same repo?
<viaken>I understand you don't want to share your channel, but I figured asking about organization was ok?
<gnucode>hmmm...shh-ing into my VPS with 1 GB of ram...guix pull seems to fail. I wonder if the low memory is the problem.
<nckx>viaken: I keep everything in a single channel, with nckx/packages, nckx/system, etc. Pretty straightforward. I don't use Guix Home (yet?).
<nckx>gnucode: Seems exceedingly likely, especially if you don't have swap. Using -{M,c}1 might mitigate it at the expense of speed if this thing has multiple cores.
<nckx>ACTION -> zzz
<gnucode>I might not have swap enabled actually...
<piptown>Upon initial installation of guix, I chose to go with Substitutes for packages. How can I change this build things locally?
<piptown>also  I bought this laptop just to run guix. do y'all think it would have a problem compiling source code?
<gnucode>piptown: That should be just fine.
<gnucode>I would upgrade to max amount of RAM.
<gnucode>8GB is the minimum I like to have for any laptop/desktop.
<gnucode>I have a thinkpad t400, which is pretty close to the same thing as the X200.
<piptown>gnucode: ok I'll do that at some point. How can I change my system to not use substitutes?
<gnucode>piptown May I ask why you do not want substitues?
<gnucode>I personally would not recommend that. You will have a really hard time compiling firefox or libreoffice.
<gnucode>I tried disabling substitutes once...never again.
<gnucode>I think you need at least 16 Gigs of RAM to compile firefox...
<viaken>piptown: You can check builds against the substitutes with `guix challenge`, skip them for a specific build/install with the `--no-substitutes` flag. I don't know the correct way to disable them system wide, but moving /etc/guix/acl does the trick.
<aarcov>piptown: if you're wanting to verify packages and build from source as a matter of principle, you might be able to hunt through ebay or your local equivalent and find a desktop/tower system with more ram and use it to build the packages from source and host your own private substitute server. I can say that I have had issues with some VM's when I didn't give them enough ram
<piptown>hey how do add bspwm to my config.scm?
<PotentialUser-58>I installed guix in ubuntu 22.04 by running installation script in regular user ($ sudo /PATH/TO/ but directory ".guix-profile" locate at /root/.guix-profile and I could not use guix in current user without sudo. what wrong with my installation?
<aldum>if you installed it with sudo, you did not install as regular user
<PotentialUser-58>But it should install with root which mention in manual. How to install as regular user? I have another archlinux machine and I ran with same command ($ sudo /PATH/TO/ in regular user account and it installed as regular user. What's the difference? Shouldn't be the same with same?
<PotentialUser-58>[1692247633.357]: [ INFO ] Linking the root user's profile
<PotentialUser-58>[1692247633.360]: [ PASS ] activated root profile at /root/.config/guix/current
<aldum>on arch, you can install from AUR
<PotentialUser-58>This is the log of my installation in ubuntu
<PotentialUser-58>That's correct, but I ran the installation script, it work well
<nckx>The script doesn't install .guix-profile, does it?
<nckx>It provides a bootstrap guix in /usr that does so when you first install something.
<nckx>The /root link is created because it's how the daemon is kept up to date (on a foreign distro, you are expected to pull as root once in a while, in addition to regular users). That's the only reason it exists and it's an implementation detail you shouldn't worry too much about.
<PotentialUser-58>It seems to be the problem of sway wm, it works the same as arch machine in tty and gnome. However, my arch machine also running sway, I still not know what's wrong about that. (Archlinux .config/guix both existed in root and regular user but ubuntu only exist in root)
<civodul>Hello Guix!
<xd1le>o/ civodul
<hulten>I have a static IP address configured, but now the service 'networking' cannot load.
<hulten>I do not mind 'networking' is not loaded, but CUPS minds.
<hulten>Can I tell the service 'cups' that it does not need 'networking'?
<nckx>The static-networking service should provision 'networking though?
<jab>morning guix!
<jab>friendly reminder: I have access to a Talos II through my friend. So if there is some guix package that you might me to try to build on power, then please let me know!
<jab`>morning guix!
<minima>hi, i have a gexp where a command expects some env variables to be set; this minimum example doesn't work is it because i'm using bash for the example or am i using setenv wrong?
<minima>the actual gexp would use another executable but i've started thinking that my env variable doesn't get set - so i thought of that minimal example with bash
<gcarlos>where I can download a prebuilt database for use with guix locate?
<civodul>gcarlos: hi! for now there's no such database; the goal is to eventually distribute one from ci.guix for example
<gcarlos>cool, it might be so helpful
<civodul>yeah, definitely
<gcarlos>how can I use things like nconfig and menuconfig from inside a container? It seems that I've no terminfo at all available, so I get this: "error opening terminal: unknow"
<gcarlos>and the TERM is set to dumb
<dthompson>civodul: hey it would be "real nice" if guile-next could be updated sometime soon now that everything that guile-hoot needs is in guile main. what do we need to consider before updating it?
<efraim>gcarlos: try adding ncurses to the list of packages
<gcarlos>efraim: it already is in my manifest, but this error is for menuconfig. For nconfig i can't even build, I get a missing library error "ld: cannot find -ltinfow: No such file or directory", this is why I asked before about guix locate, I don't know what package provide it (ncurses-with-tinfo seems to provide libtinfo, not libtinfow)
<mwette>there is a ncurses-with-tinfo (via
<minima>hi, i'm (naively) trying this command to play with nmcli `guix shell --no-cwd --container --network bash-minimal network-manager -- bash' - but when i then lunch nmcli from the shell i'm told `Error: Could not create NMClient object: Could not connect: No such file or directory.'
<jpoiret>minima: network manager communicates via dbus, you'll have to share some stuff with the container
<minima>jpoiret: ah right, i see, thanks
<jpoiret>ah, and in general, network-manager needs a system daemon to be running
<jpoiret>so if you don't have nm configured on your computer already, most likely it won't work
<minima>jpoiret: hm i see...
<minima>qemu and a full OS definition might make more sense for this bit of experimenting that i'm working on then
<razlix77>hello o/
<razlix77>totally not getting why (local-file "../../some.file") works in most places but not for keepalived :(
<razlix77>here is wht I'm trying
<apteryx>gcarlos: export TERM=xterm
<cbaines>dthompson, I think guile-next can be updated easily, there's nothing to consider
<apteryx>is working? it should be building stuff, it seems
<apteryx>but it's idling
<dthompson>cbaines: great! just wanted to make sure.
<dthompson>(I forget these sorts of things all the time)
<andreas-e>apteryx, roptat: Same for lieserl, actually.
<ngz>Hello, Guix.
<andreas-e>Hello, ngz!
<apteryx>cbaines: I'm curious, when will the 'elogind-updates' branch shown at be deleted? It's merged and gone from savannah
<cbaines>apteryx, are you sure it's gone from savannah?
<apteryx>ah, you are right
<apteryx>it's still there
<apteryx>no more
<cbaines>cool, the news has already reached
<cbaines>so QA should update shortly
<civodul>apteryx: i've restarted cuirass-remote-worker on overdrive1, in case it helps (it was up and running according to the log, but who knows)
<apteryx>this machine is using wireguard to stay connected, right?
<apteryx>(to be reached by berlin)
<minima>hi i'm trying to inherit from an operating system definition, like this: but when i get to build the image i get an error `inherit: unbound variable'
<minima>ah obviously, i'm overwriting `operating-system', which i guess is bad, i'll try with more sensible var names
<civodul>apteryx: yes, it's runs WireGuard; it could be that the remote-worker/server got out of sync for some reason
<apteryx>civodul: is your home IPv4 dynamic?
<apteryx>(changing every now and then)
<apteryx>(otherwise I'd have suggested to use the recently added (monitor-ip? #t) option to guard against loosing the link)
<apteryx>ACTION notices monitor-ips-internal, which should read monitor-ips-interVal
<apteryx>Guix now has a larger package collection than Fedora 36, takes the 5th spot, accordingy to
<apteryx>is there a 115.X release for both icecat and thunderbird we could update to?
<civodul>apteryx: re repology, wo0t!
<civodul>though... how long this can be sustained is an open question...
<apteryx>we'll need bots, like NixOS, and efforts on the tooling
<apteryx>civodul: overdrive1 is building stuff now, thanks
<apteryx>for keepassxc/yubikey users wanting to use them together:
<jab>apteryx: wow! That's incredible that we beat fedora!
<apteryx>jab: yes! makes we wonder if the data of is really accurate w.r.t. fedora
<jab>hmmm. I hope it is.
<civodul>i think Fedora is moving high-level things to Flatpak
<civodul>which could partly explain that
<civodul>also, they certainly don't have zillions of Haskell/TeX/R packages
<jab>and they don't have a lot of package varients do they?
<mirai>fedora flatpaks usually still have a rpm counterpart
<civodul>jab: yeah probably few variants too
<andreas-e>I have been reviewing a package that puts libraries into lib64/. Is that okay, or should we manually move them to lib/? (It is based on cmake, and I do not know if there is an easy way to force lib/)
<apteryx>it may be; Red Hat is quite selective in general to keep their scope limited
<apteryx>andreas-e: I was able to restart lieserl's cuirass-remote-worker: ssh, then sudo herd restart cuirass-remote-worker
<apteryx>from berlin
<apteryx>it'd be useful if we could see which architectures each machine supports on the cuirass web pages
<apteryx>currently you have to remember
<andreas-e>apteryx: Good to hear this! And it now builds packages. I will remember that it is that easy.
<podiki>hi guix!
<apteryx>cbaines: another QA question; the numbers don't look too bad for, but the 'Succeeding' column numbers are all 0s. That means that it hasn't started being built yet, right?
<andreas-e>apteryx, civodul: But overdrive1 has now disappeared from the workers page.
<cbaines>apteryx, yep, I think QA hasn't even submitted builds yet (you can see that by following the "View comparison" link)
<cbaines> has 98% substitute availability for some recent revisions (just prior to the elogind update), so the ~8% missing substitute availability for the qt-updates branch looks to correspond with those 1935 changed packages.
<cbaines>(that's all for x86_64-linux)
<civodul>andreas-e: i think it's a bug (now fixed) in Cuirass, whereby remote-worker wouldn't notice worker pings in a timely fashion, and thus mark them as unavailable
<civodul>it's still up and running though
<apteryx>ah, so it just needs a reconfigure/reboot?
<andreas-e>It is back on the workers page (without showing package builds, but this is sometimes a bit behind).
<andreas-e>apteryx: I agree it would be nice to show the architectures, but they are also easy to memorise: hydra-* is x86, *p9 is powerpc-9, and all the weird names are ARM.
<elpogo>where does guix pull store the clone of the guix repo?
<andreas-e>You can also click on the machine names and see their architectures (plus a zabbix error message).
<civodul>andreas-e: i'm skeptical about the "texlivebin" trick (removing hyphens), looks like it could lead to interesting issues down the road
<andreas-e>elpogo: I think in $HOME/.cache/guix/checkouts
<andreas-e>civodul: Well, one should ever only install either "texlive" or a mixture of packages from the modular "texlive-*". Hm, ngz just modified things so that texlive and texlive-biber are compatible. Maybe they modified the profile hook, and the trick is not needed any more?
<didi>Have guix Emacs 29?
<elpogo>ty andreas-e . you saved me a lot of bandwidth
<apteryx>andreas-e: haha!
<andreas-e>didi: There is emacs-next, which is at 29.0.92.
<podiki>emacs 29 progress:
<podiki>building, so you could locally use these patches and get (some) substitutes for instance
<podiki>didi: ^
<apteryx>cbaines: well done with communicating the status of QA via user messages such as "Builds for new patch series suspended as master branch substitute availability is low for: armhf-linux i686-linux "
<apteryx>it's useful
<andreas-e>cbaines: What is it based on? i686 is green on ci by being just above 80%.
<cbaines>apteryx, thanks
<cbaines>andreas-e, it's based on the substitute availability for the master branch
<cbaines>the idea is to have QA wait until the master branch is in an OK state before submitting more builds for patches
<andreas-e>We need more build machines...
<cbaines>indeed, although given how few we currently have going, even one or two more machines would make so much difference
<apteryx>answering a previous question, yes there's a 115.x ESR for both firefox and thunderbird, so we could try upgrading to them
<didi>andreas-e, podiki: Thank you.
<ngz>andreas-e: yes, I modified the profile hook, which used to be triggered by a gross condition.
<podiki>build machines meaning everything but x86-64 or that included?
<ngz>andreas-e: However, I (!) still frown upon anyone mixing monolithic and modular packages ;)
<andreas-e>ngz: Yes, we should not mix them. But maybe the texlive-biber package is a useful exception. Since I am not actually using it currently, I do not really know.
<cbaines>podiki, that included, the bordeaux build farm only has 3 build machines for x86_64-linux/i686-linux, so it struggles with keeping up with master and building packages for patches and branches
<andreas-e>The safest bet will still be to install *either* texlive *or* a collection of texlive-* packages.
<andreas-e>ngz: I did not know about the texlive "systems" and "collections". Are the collections a complete partition of the packages? And the systems a partition of the collections?
<ngz>andreas-e: If we were to keep `texlive' around, I think a better fix would be to compile the "biber" executable right from the source (this is what texlive-biber does). But I think we should get rid of `texlive' as soon as possible.
<ngz>andreas-e: schemes are bundles of collections. collections are bundles of packages. I think collections are complete partitions of the packages, although I'm cannot certify it there's no intersection between them.
<andreas-e>texlive is about the amount of complexity I can muster... I do not feel comfortable to work on the modular thing. Indeed as soon as we have all the packages, the monolithic texlive could go away.
<andreas-e>Sorry, I meant "schemes", not "systems", indeed.
<ngz>Right now our modular TeX Live covers between 50% (pessimistically) and 51% (optimistically) of the packages.
<andreas-e>So the plan would be to package all packages, and then to create metapackages with the collections that pull in all the packages as propagated-inputs? And then schemes with collections as propagated inputs?
<ngz>It's not difficult to add packages, the importer does a good job. It's just tedious.
<ngz>Actually, I import recursively collections. I add the packages, with the collection at the end. This way, I can try to build the collection and check if every package in it builds before pushing.
<ngz>At the moment, there are only 4 collections missing: collection-bibtexextra (I'm on it), collection-fontsextra, collection-latexextra (this one is a beast with 1000+ packages), and collection-publishers.
<ngz>I'm not counting collection-texworks, which is about a Windows-only binary.
<ngz>Once these collections are complete, we can add `texlive-scheme-full', which propagates all collections, and declare TeX Live complete.
<ngz>(I already added all other schemes)
<apteryx>ngz: thanks for you work toward that goal!
<apteryx>you should consider joining the tex team :-)
<ngz>He he
<andreas-e>ngz: That sounds very nifty!
<ngz>There are a lot of things that I do not know about TeX, for example, I'm still clueless about LuaTeX. I don't know if it works properly (I expect it to work as well as in the monolithic TeX Live, but how well?)
<andreas-e>apteryx: Probably ngz should take the lead!
<apteryx>tex is too large to know it all
<andreas-e>Currently only rekado is mentioned as a tex team member.
<apteryx>i'm sure you already know more than most of us
<ngz>Then we're doomed ;)
<andreas-e>If the framework is correct, then there is no reason it should not work in the modular setting also.
<apteryx>can I cause a build that fails post install phase to preserve its incomplete /gnu/store/ output? that'd make debugging much easier
<apteryx>otherwise I have to rebuild the thing using a custom prefix, and tediously rewrite many of the build flags to point there (qtbase)
<ngz>andreas-e: True, but there is a suspicious file, namely "texmfcnf.lua" that should probably be tweaked but isn't. There are also reports of strange behaviour from LuaTeX.
<apteryx>configure flags*
<andreas-e>cbaines: harbourfront will remain in operation until towards the end of the year. Whatever this means, but in any case beyond end of August.
<cbaines>andreas-e, that's good :) although we should still get on with working out what to do next regarding build machines
<dthompson>anyone else getting errors running make on master? for me `MAKEINFO doc/` fails
<andreas-e>cbaines: We shall have to try setting up guix and the builders on our openshift instance.
<apteryx>dthompson: time to 'guix pull', I think
<apteryx>I've recently patched po4a to support partial menu entries
<andreas-e>dthompson: I get the following error on aarch64:HELP2MAN doc/guix-copy.1
<andreas-e>help2man: can't get `--help' info from guix copy
<dthompson>apteryx: within the last few days?
<apteryx>yesterday or such
<dthompson>will pull
<andreas-e>Annoying, but everything else still compiles.
<apteryx>or you could try within ./pre-inst-env
<cbaines>andreas-e, cool! I have used the dynamic authentication I added to more easily support that use case for hurd builds, so it should still work which is good :)
<apteryx>(with your local git checkout having the patched po4a)
<andreas-e>Does anyone have a clue on my lib64/ question above? Is it okay to keep it, or should it be renamed to lib/?
<apteryx>there's no lib64 in guix as each derivation/outputs are already architecture specific. It should be lib, me thinks.
<apteryx>it's probably configurable, you can refer to 'info cmake'
<apteryx>also tooling such as relocatable guix pack wrappers will expect libraries under /lib, not /lib64
<andreas-e>apteryx: Thanks, this is also what I thought. Concerning cmake, I will try to have a look. I find it much more intimidating than the autotools... But maybe this is just a question of being used to one or the other.
<viaken>I'm a little puzzled about putting a small shell script on the filesystem. I can splat it down with (extra-special-files (plain-file)), but then it's not executable? Is there a better way to go about this?
<hako>program-file ?
<cbaines>I'm not sure that'll work for a shell script hako
<hako>okay, then... invoking bash in program-file to run the script?
<viaken>Yeah, that might work. Or I can try actually using Guile. :) It's not a complicated thing.
<andreas-e>apteryx: I just saw that we are about a year behind with calibre releases. They went from 5.44 to 6.0, and one of the changes is that support for 32 bit architectures has been dropped, supposedly because Qt@6 does not support them. This is weird, I do not see this restriction in our qtbase package, for instance.
<andreas-e>Hm, Qt says they do not ship prebuilt binaries for 32 bit, but that they can still be compiled by hand.
<mirai>what package provides epstopdf and pdflatex?
<ngraves>Hi guix ! Is there a way to reload the load-path - if the underlying files have changed - in a guile script ? Thanks !
<andreas-e>mirai: pdflatex is in texlive (the big monolithic package), and should be in some other texlive-... package as well.
<mirai> /gnu/store/534c6kvw8kp5d5hqbp1qxqq7mjva46fv-texlive-scheme-basic-66594 is empty to me
<andreas-e>It just propagates other packages.
<mirai>`tree /gnu/store/z98df6svjzrym5hka2nijyfzb1wxxsk4-texlive-updmap.cfg-59745/` doesn't contain any bin/ directory
<mirai>this is from the wrapped dblatex script
<mirai>so dblatex isn't really seeing pdflatex & co.
<andreas-e>mirai: This looks like an error in the dblatex wrapping. pdflatex comes from the texlive-bin package, which is not a direct input of the dblatex package.
<andreas-e>Maybe you could file a bug.
<apteryx>andreas-e: I think they mean by "official" support.
<apteryx>I'd be surprised if debian didn't build Qt 6 for i686
<andreas-e>Maybe that is it.
<andreas-e>I just tried to update calibre to 6.0. It would require us to add python-pyqt@6, and to carefully juggle the variable names if we also need it @5.
<apteryx>as Qt 6 gains traction, it'd be nice to standardize all Qt 5 packages *variables* to end with '-5'
<andreas-e>Indeed. PyQt is bit special. We have python-pyqt5-sip, for instance; the 5 comes from the PyPi name.
<andreas-e>So here it is also in the name string.
<apteryx>I wonder if with the HTML updater ability to rewrite versions in URLs (#65230), if we could drop the limitation of not updating packages whose release is on github and other forges (the '(not (member host hosting-sites)' code in (guix gnu-maintenance))
<apteryx>ah, no. This page e.g. is not reachable:
<apteryx>would break the mechanism.
<pret7>heya! is there any good way to test a substitute server?
<pret7>I have a substitute server, and I think it works, and guix weather works
<pret7>but when I try and do a build of a package I know it has it still builds locally
<attila_lendvai_>pret7, last time i had this problem the signing key of the server was not installed
<pret7>that's in my guix-service-type
<pret7>in system.scm
<pret7>is there any way to check that its working?
<pret7>I will say, running guix repl, then ,use (guix) still shows only the default ones in %default-substitute-urls, but I think that's expected
<pret7>how can I check what that variable is in the guile that's running guix?
<pret7>and the %default-authorized-guix-keys variable
<pret7>interesting. guix weather only checks and
<pret7>ah that's a bug ok