IRC channel logs


back to list of logs

*chrislck don't know what's more difficult... guile macros, or guix :(
<nly>hi chrislck
***sneek_ is now known as sneek
<quiliro>roptat: is your repository?
<quiliro>roptat: I see in your readme and no system is an email server
<quiliro>with its TLD a public one
<quiliro>roptat: must be hermes
<quiliro>sneek: later tell roptat I see in that there are a lot of configuration files...I do not quite understand GNU Guile yet...What files should I use for just an email server and what should I change on them for my particular case? I have only domain name, name servers' IP addresses and user names.
<g_bor[m]>Hello guix!
<g_bor[m]>Yesterday I was trying to get graceful shutdown to work from libvirt on a Guix System VM. I managed that by adding elogind-service to the vm config, reconfigure, and reboot.
<g_bor[m]>Do you think that we could modify our elogind-service, so that reboot is not required?
<g_bor[m]>The service starts, but it seems that it does not hook up on acpi.
<tune>nckx: thanks for the help yesterday, I've finally just finished the movie. didn't have any choppiness in the second half so that driver may have helped
<roptat>hi guix!
<sneek>roptat, you have 1 message.
<sneek>roptat, quiliro says: I see in that there are a lot of configuration files...I do not quite understand GNU Guile yet...What files should I use for just an email server and what should I change on them for my particular case? I have only domain name, name servers' IP addresses and user names.
<roptat>sneek, later tell quiliro my mail config is here: but you will be missing the dkimproxy service I forgot to send to guix (I'll do a bit later):
<sneek>Got it.
<roptat>sneek, botsnack
<jonsger>Is this intention that commit 9e6256ba0f32ab12d61c914a3fed879dac881762 is tagged as bootstrap-20190815
<g_bor[m]>roptat: I started to collect issues for guix-home-manager. As of now I see three kind of thing we are willing to manage: read only configuration, that's what home does, persistent state, for example by symlinking to /data, and volatile state, for example by symlinking to /tmp, and letting the system get rid of it on reboot. Is that about correct?
<roptat>g_bor[m], yes
<roptat>although I don't know about volatile storage
<g_bor[m]>Nice. I was thing about putting some caches and other regeneratable state there, that still needs to be writeable.
<allana>Hi, does anyone know of any thorough resources on running GUI apps from guix containers? I am having some difficulty in running icecat from a guix environment, initialized in this way: "guix environment --container --network --share=/tmp/.X11-unix --ad-hoc icecat"
<allana>I have fiddled with DISPLAY and XAUTHORITY environment variables but I am not so certain that I am using the correct values.
<allana>Nevermind, I had to find another Xauthority file on my system. :-)
<g_bor[m]>allana: you might find something useful here:
<allana>g_bor[m]: thanks
<efraim>still undecided about switching out patch against enlightenment from hardcoding to making it a parameter and submitting it upstream
<efraim>I still don't actually know how Nix does enlightenment
<nixo_>Hi civodul, thanks for the help with repology
<civodul>hey nixo_, yw!
<civodul>i actually wanted to see if we could use that file for Software Heritage as well
<nixo_>great! How is the progress with software heritage btw?
<g_bor[m]>civodul: not sending last modified from nginx is easy enough, if we have the headers module.
<civodul>nixo_: on our side i'd like to ensure all the code Guix refers to is actually archived there
<civodul>that's the next step
<civodul>packages.json may allow them to do that automatically
<civodul>we'll see!
<efraim>ok, enlightenment 0.23 pushed to master
<civodul>g_bor[m]: cool! if you want, you can take a look at the config in maintenance.git
<g_bor[m]>civodul: ok, I can have a look at that later. Right now I am in my shop selling stuff. My employees are on vacation :)
<g_bor[m]>civodul: it would be also possible to generate part of nginx configuration during building the site, and include that, but I don't believe that fragmenting configuration this way is really good. Although, it could only define a single variable...
<jlicht>hey guix
<pinoaffe>Hi everyone, I packaged faber (, my goal is to have it supported as a build system for guix, but for now I"m trying to manually use faber to build, which fails because it's unable to find a fitting version of python - 'No matching tool "python" found'
<pinoaffe>does anyone have a clue as to what might be causing this?
<roptat>pinoaffe, our python package only has a python3 binary
<roptat>maybe faber refers to it as "python"
<roptat>civodul, my haiku system freezes too often for it to be useful. haikuporter doesn't even have enough time to build its package cache before the system freezes :(
<pinoaffe>roptat: that sounds likely, would I need to patch faber or could I make guix provide an alias of some sorts?
<roptat>I tihnk you'll need to patch faber
<g_bor[m]>pinoaffe: if that is the issue, we have a wrapper for that I believe. Try to search for it
<g_bor[m]>I believe so...
<g_bor[m]>nly: yes, that's it.
<efraim>I tried to package pypy, and although it says it can be built with cpython the instructions assume you're using pypy...
<pinoaffe>g_bor[m], nly: thanks, that seems to allow it to build :)
<civodul>roptat: oh, you're running Haiku on the metal?
<roptat>yes :)
<civodul>neat :-)
<civodul>evil idea: run it in a VM so freezes are less of a problem
<roptat>I was thinking of that
<roptat>but then I thought maybe I could make a nice bug report to haiku :)
<roptat>so I'll be using this system a bit longer to test things
<roptat>it's also on a computer where I tried to install the hurd once
<roptat>the ethernet driver was supposed to be supported (it was listed on the hurd website) but I was never able to make it work...
<roptat>they are both very nice OSs
<roptat>I'd like to have a guix hurd system on a bfs or similar fs, with haiku's graphical interface
<pinoaffe>I'd love it if hurd got USB support
<civodul>thanks efraim & wigust for reviewing patches!
<civodul>for a while i thought this mailing list had become write-only ;-)
<roptat>what's the status for core-updates?
<civodul>roptat: it's frozen and building!
<civodul>we might even merge it someday
<civodul>at least we've never been this close to that day
<civodul>actually we *have* been closer, but then there was this Terrible Last-Minute Issue
<roptat>I'd like to upgrade our qt package (because more recent versions support esperanto better), but I don't understand the difference between qt (no dependent) and qtbase (500 dependents (only?))
<civodul>qt is deprecated
<civodul>we should remove it whenever possible
<civodul>efraim is our Qt expert
<efraim>it happened by accident
<civodul>but it did happen :-)
<roptat>so do I only have to update qtbase?
<efraim>I have some stashed code on bayfront to update qt to 5.12.4, 5 of the modules fail and I haven't looked at them yet
<roptat>5.13.0 is out now
<efraim>the 5 are qtremoteobjects, qtwebglplugin, qtwayland qtgamepad qtcanvas3d
<roptat>but 5.12 would be enough for esperanto support :)
<efraim>after I messed up the 5.11 upgrade i'm avoiding hte .0 releases
<roptat>I see
<efraim>those 5 apparently don't have any dependants so they could be fixed later
<civodul>roptat: heheh :-)
<efraim>so i'll leave those broken for now and look at pyqt, thats the last bit that needs to build with the qt upgrade
<efraim>and the massive qt itself, but I normally do that last since it borrows snippets from all the others
<roptat>ok, thanks for your work :)
<roptat>tell me if you need help
<efraim>its building now on bayfront, hopefully qtwebkit doesn't kill everything
<rekado_>pinoaffe: it does have USB support — for audio interfaces no less.
<rekado_>(or did I mix this up?)
<rekado_>I did mix it up: it has some USB support via NetBSD rump kernel, and the same mechanism is used for audio.
<xavierm02[m]>Is there a matrix client en guix? The name matrix makes it kind of head to search for...
<nly>if you are emacs user, i remember there was emacs-matrix-* ?
<nixo_>xavierm02[m]: quaternion, emacs-matrix-client
<xavierm02[m]>nixo_: Thanks!
<nixo_>civodul: looking at latest packages.json, zpaq has the "source": {"type":null}, that seems to be wrong (there's a url fetched by url-fetch/zipbomb). Also sbcl-ascii-strings (hg-fetch), which has an unknown source type even under emacs-guix, symmetrica (url-fetch/tarbomb) (and maybe others)
<kkebreau>So I've been sitting on an almost complete "wip-gnome3.32" branch for a while now...
<kkebreau>But GNOME is due to release version 3.34 in less than a month.
<jonsger>kkebreau: is this wip-gnome3.32 branch based on master or core-updates'ß
<kkebreau>Is anyone using the "wip-gnome-upgrades" branch on the server? It doesn't look like it's been used in about a year. If possible, I may just merge my changes there so others can collaborate on newer upgrades.
<kkebreau>jonsger: Yes it is.
<jonsger>kkebreau: master or core-updates?
<kkebreau>Whoops! I misread that. :-P
<roptat>kkebreau, maybe the wisest thing to do is merge gnome-3.32 just after core-updates, then work on gnome-3.34 instead of delaying everything for too long?
<kkebreau>roptat: Probably. Correct me if I'm wrong, but core-updates is likely to merge soon, yes?
<roptat>that's what I've heard
<jonsger>roptat: gnome 3.30 lays in core-updates and master is still 3.28, so the gnome update is already heavily delayed through the delay of core-updates
<roptat>here's what I think: when we merge core-updates, rebase wip-gnome3.32 from master and start evaluating the branch, fix issues and then merge the wip- branch to master without going to a new core-updates
<roptat>then start working on 3.34
<kkebreau>I like this idea.
<mbakke>me too :)
<kkebreau>I'll be back in a few hours...
<nixo_>anybody has problems with btrfs mount flags? At boot, my options are different from the ones I set in the config.scm. If I sudo mount -o remount /home, the options are right
<Minall>Hello guix!
<Minall>Trying to add the module xf86-video-openchrome on my config.scm, makes xorg crash in my next reconfigure
<roptat>can you share your config?
<roptat>and maybe, the content of your xorg log?
<Minall>Right now my xorg is using the fallback modules... when I try to add (modules (list xf86-video-intel)) under xorg-configuration, xorg crashes the next time I boot
<Minall>I assume I should add xf86-video-intel, since my pc uses intel
<roptat>mh... shouldn't that be (modules (cons xf86-video-intell %default-xorg-modules)) or something?
<Minall>I'm not sure, maybe you're right, but as I know, xf86-video-intel is already added right?
<Minall>I see that it is downloaded in the installation....
<roptat>so you don't need to change the modules list?
<roptat>I don't really understand which configuration doesn't work
<roptat>wouldn't (modules (cons xf86-video-openchrome %default-xorg-modules)) work, then?
<Minall>Sorry, my bad, I'm trying to add (modules (cons xf86-video-intel %default-xorg-modules))
<Minall>Would that work?
<nckx>tune: Awesome 🙂
<Minall>roptat: let me try that then
<civodul>efraim: woow you're feeling Rusty today no? ;-)
<civodul>nitpick: some descriptions could be improved
<Minall>¿Is there a package for openjfx?, I can't find it.
<roptat>Minall, there is in my patch series about josm
<roptat>I'm waiting for upstream to fix their git mirror to push an updated version of josm, but I could push the rest of the series
<roptat>it's a version 8 though, not the latest
<roptat>(well, the latest that corresponds to java 8)
<Minall>That could work if I could install openjdk8, but there's no definition for it }
<roptat>that's icedtea@3
<Minall>But is nice to see that someone is working on it!
<roptat>icedtea is for java 6 to 8, then it's openjdk from java 9
<Minall>I'll check it
<efraim>Civodul I have another 300 or so that I need to go through, more if I actually want to build all of them
<civodul>efraim: woow, all from "guix import crates"?
*civodul .oO( Do we have a crate updater? )
<efraim>Mostly, it can be a bit flakey
<Minall`>Hello guix!
<Minall`>I just reconfigured trying to add xf86-video-intel, but it didn't work
<ngz>efraim: Sometimes, the crate importer doesn't work (e.g., for rayon), and I don't know why. In particular, the URL is correct, i.e., if the web browser can download the crate. Did you experience something like this?
<quiliro>Saluton Gikso!
<sneek>quiliro, you have 1 message.
<sneek>quiliro, roptat says: my mail config is here: but you will be missing the dkimproxy service I forgot to send to guix (I'll do a bit later):
<nckx>lfam: Thanks for the dovecot bump. Updating now…
<quiliro>roptat: thank you
<jfred>hmm... so I'm trying to add a path to XDG_DATA_DIRS in Guix System (I managed to get Flatpak running alongside Guix), but Gnome doesn't seem to be loading ~/.profile by default... is there a preferred way to set env vars in a graphical session?
<lfam>rekado: In March 2019 you wrote a patch for the eudev 'exec_prefix' bug <>
<lfam>Mentioned on IRC but no longer available on the paste site:
<lfam>You wouldn't happen to still have this patch, would you?
<csprng>question regarding git-fetch in a package: what's the hash based on? My naive assumption is that it would change as the repository changed, but that didn't seem to be the case when I checked out a branch
<lfam>cpsrng: The Git repo is cloned, checked out to the desired commit, and then the '.git' directory is deleted. Finally, the hash is calculated on the resulting directory
<lfam>You can do `guix hash --recursive --exclude-vcs` to calculate the hash
<csprng>ah, so even subsequent commits to the repository won't change the hash
<csprng>relatedly: the best practice is to use git/tag vs a release tarball?
<lfam>csprng: If the tarball was created by the upstream developers then use the tarball. The dependencies required to unpack it are smaller and simpler than git
<lfam>But Github offers autogenerated tarballs of tagged commits and these tarballs change periodically, breaking our packages
<jlicht>csprng: that depends, but a lot of the major git forges actually regenerate the tagged tarballs from time to time, changing the hashes
<jlicht>^ what lfam is explaining :)
<lfam>So if the upstream team doesn't actually make the tarball themselves, just use git
<lfam>We all have been so annoyed by this issue :)
<jlicht>if upstream properly tags their released versions, you can at least still use the tag as the commit value in git-fetch
<csprng>ok, that makes sense
<lfam>Tags are nice because they are human-readable
<lfam>They can be changed but that doesn't happen as often as the Github auto-generated tarballs being recreated
<lfam>I wonder how the hash transition is Git is going
<civodul>hey lfam
<lfam>Hey civodul
<civodul>lfam: i didn't know they had a plan
<civodul>good that there's one but... it's going to be hard
<lfam>I can't imagine the difficulty
<civodul>i don't understand designs that don't leave space to change crypto functions
<civodul>one of the obvious difficulties is that code all around expects 40-char hex strings as IDs
<lfam>I guess this is a case where the software was hardly designed
<civodul>well yeah :-)
<civodul>i mean Git has obviously a solid design, but this "tiny detail" can break it all
<lfam>Yeah, and everything relies on it working perfectly. If you can change the contents of a Git commit you win the prize
<lfam>Hi Sisyphe[m]
<Sisyphe[m]>lfam: developer-generated tarballs are what appears in the "release" section of the github page ?
*lfam looks for a good example
<Minall>Hello guix!
<Minall>quiliro: Kiel vi Fartas!
<lfam>Sisyphe[m]: Check this page out:
<lfam>Sisyphe[m]: The files 'libgd-2.2.5.tar.gz' and 'libgd-2.2.5.tar.xz' were created by the libgd team
<lfam>Sisyphe[m]: The links called "Source code (zip)" and "Source code (tar.gz)" were created automatically by Github when the tag was pushed
<lfam>These autogenerated files are named for the tag. Usually this means they have a name like "v1.2.3.tar.gz" which is not very descriptive and highlights that the upstream people did not create them
<lfam>The whole issue blew up and was discussed here:
<lfam>Github said they understood the difficulty that it caused but that people should not rely on the autogenerated downloads staying the same over time and to please stop using them when that property is required
<lfam>Also, if you have a project on Github, you can't turn this autogeneration off
<lfam>Does that make sense Sisyphe[m]?
<Sisyphe[m]>yes perfectly ! I would have assumed these tarballs not to change
<lewo>In the nixpkgs fetchFromGitHub function, the sha is computed on the unpacked archive to avoid this kind of issue
<lfam>lewo: Can you link to the implementatioon?
<lewo>But we then loose the content addressable property since the sha of our fixed output derivation in not the sha of what we download...
<lewo>lfam: yep, 1 sec :)
<Sisyphe[m]>naive question: making the tarball of the same content shoudn't produce the same tarball ?
***ChanServ sets mode: +o Sigyn
<lewo>lfam: (fetchzip is used by fetchFromGitHub)
***ChanServ sets mode: +o Sigyn
<nckx>lewo: Indeed, that loss of easy verifiability (no longer ‘just run foosum bar.tgz’, but ‘unpack bar.tgz, then run our proprietary hashing tool on it’) is a major regression IMO.
<lfam>Sisyphe[m]: The contents of the tarball should be the same but the tarball itself may change
<lfam>Sisyphe[m]: Check this message for some details:
<nckx>(No idea if this is a factor in this case but) gzip & tar can both be made to create unreproducible output from the same input if you're not careful.
<lfam>nckx: You mean the archive can unpack to something different from the input?
<nckx>lfam: Oh, no! Just that ‘gzip foo | sha256sum’ can differ from ‘gzip bar | sha256sum’ even when foo and bar have identical contents.
*nckx should've used other words than output & input.
<Sisyphe[m]>lfam: thanks, the real world is way less reproductible than I expected...
<lfam>Okay, phew
<lfam>Sisyphe[m]: Yes, it's true
<lfam>It's a big mess
<nckx>Sorry for everone's spit-take keyboards & screens now.
<lfam>Well look at this nckx:
<nckx>lfam: As in, those xattrs then get written to the file system when extracting?
<lfam>I don't know..
<lfam>Not sure what a PID could mean for a file attribute
*nckx puts away all drinks just in case.
<nckx>But yeah, interesting how all this helpful provenance data added by well-meaning developers (for good reason) is now being purged (for good reason).
<nckx>The times, &c.
<civodul>lewo: interesting
<civodul>the "postFetch" trick, which is run by the daemon as part of the fetchurl builtin IIUC, is a double-edge sword
<civodul>i've been very tempted to have an "eval" builtin or something, where we could evaluate arbitrary Scheme code as part of a derivation
<civodul>that would allow us to have derivations with undeclared dependencies, essentially
<civodul>but that's easy to do Bad Things with that
<lfam>I just installed a new Guix system, pulled, and reconfigured it to be up to date. But when I try to run shepherd for my user it crashes with this message: In procedure stat: No such file or directory: "/run/user/1000/shepherd"
<lfam>The directory doesn't exist, indeed. What is supposed to create it?
<lfam>Shepherd says the elogind service is running
***ChanServ sets mode: +o Sigyn
<lfam>It works when I tell shepherd to use something like '~/.config/shepherd/run' but it seems weird that it doesn't work out of the box
<lewo>civodul: currently, pkgs.fetchFromGitHub is not using buitins.fetchurl (i don't remember why). But builtins.fetchurl has a unpack option and not a generic postFetch, that allows you to unpack the archive, before computing its hash.
<lfam>Ugh, I'm having the "ssh-daemon failed to start" issue again
<lfam>And the /run/user thing is breaking pulseaudio too