<nckx>OK, so that definitely does not depend on unprivileged user ns'es. <nckx>null_radix[m]: I'm not proud of that command but it'll do 😉 <null_radix[m]>im sill curois how this works, just digging into (gnu services base), tbh i had not heard of EUDEV, and was confused becuase `man udev` seems to suggest the locations for rules are fixed <vagrantc>nckx: i don't think i knew the existance of check-system before <nckx>It's probably not relevant for you (unless Debian has some strict every-upstream-test-suite-must-pass policy), since ‘check’ should suffice to test Guix the package manager. <vagrantc>nckx: well, it's relevent for me, in that i mostly run Guix System, i guess :) <nckx>It would be relevant if someone uses Debian's Guix to ‘guix system init’ something, but I don't know if that's common. <nckx>vagrantc: Oh, I thought this was in the context of packaging, never mind 🙂 <vagrantc>by the time the debian packages were mature enough to actually use ... i'm pretty much a fan of guix :) <vagrantc>one of the use-cases i wanted a debian package for was to be able to install it and use "guix system init" on, say, armhf or arm64 systems <vagrantc>never much liked the installer script, so i always installed the guix binary stuff by hand ... but a debian package would give a starting point that's easier for me to work with <vagrantc>hmm... gdisk isn't packaged for guix ... <nckx>I've always done the sam. <nckx>vagrantc: It is, the project & package name is gptfdisk. <vagrantc>are partition uuid's supported in file-system definitions? <nckx>The GPT ones? No, since they're not part of a file system (and just generally not supported at this time). <Blackbeard>but I am not sure if those are exactly related to what you are looking for <lfam>I forgot about the info-guix ML <nckx>To be quite honest, I think the existence info-guix was simply forgotten. <dissoc3>i have guix running with stumpwm. Im trying to configure multiple monitors but if I run arandr/xrandr it closes and brings me back to gdm. is there something I should be doing with gdm to configure monitor layouts? <plasma41>The release announcement for guix 0.16.0 (https://lists.gnu.org/archive/html/info-guix/2018-12/msg00000.html) listed what versions of the autotools were used to bootstrap the distribution source tarball. Non of the release announcement for releases since then have contained this information. What versions of the autotools bootstrapped the 1.0.0, 1.0.1, 1.1.0 releases? <plasma41>s/Non of the release announcement/None of the release announcements/ <jgarte>Blackbeard: thanks! I am interested knowing what the current state of packaging node/npm javascript packages in guix is? Is there a best practice? <vagrantc>the bootstrap set has been massively reduced <vagrantc>plasma41: so i'm not sure there is any autotools used in the bootstrap <nckx>plasma41: 2.69. Note that Guix uses its ‘own’ packages for that too, not whatever random autotools happened to be on the releasers machine at the time. <Blackbeard>dissoc3: what do you want to do ? Can I see the xrandr command? <plasma41>Different bootstrap. I'm asking about the versions of the autotools used to create the configure and other generated files in the source tarball. <Blackbeard>jgarte: I've not packaged anything from npm. But I can try to help you if you wanna try to package <jgarte>Yes, I'd love to help out with packaging <jgarte>I have a bucketlist of packages I would like to package <jgarte>I'm trying to wrap my head around the node build system in /guix/build-system/node.scm <jgarte>I installed the binary on arch linux <nckx>plasma41: Why would I not understand that? So am I. <Blackbeard>jgarte: the videos are really nice, if you want to give them a look <plasma41>For example, according to https://lists.gnu.org/archive/html/info-guix/2018-12/msg00000.html the final documentation and manpages in the distribution source tarballs were generated with Makeinfo 6.5 and Help2man 1.47.8 and the configure and Makefile.in files were generated with Autoconf 2.69 and Automake 1.16.1. I'd like to know what versions of those programmed were used for each of the 1.0.0, 1.0.1, and 1.1.0 releases. <jgarte>Blackbeard: thanks for the link. I've gone through ambrevar's packaging tutorial so far <lfam>plasma41: You probably won't get an answer here tonight because it's very late at night for the person who did the release <lfam>I'm not sure but I'd expect it to be the programs provided in Guix at the time / commit of the release <nckx>plasma41: The versions of those packages in Guix. autoconf 2.69, help2man 1.47.13, automake 1.16.2. <nckx>I cannot make this much clearer. <nckx>Check out (or pull) Guix 1.1.0, look at the versions of the packages you are interested in. <nckx>You can verify this by looking at the 1.1.0 sourceball if you don't trust random nckxes on the Internet. <plasma41>nckx: Would it be the tagged git commit or the one immediately prior? Which describes the state of the machine actually creating the tarballs? <reepca>hmm, python-jedi fails to build due to a test failure <vagrantc>ok, successfully booted guix on rockpro64-rk3399 ... though there are issues with linux-libre-arm64-generic and missing cgroup features used by elogind... <lfam>plasma41: You should check the 'release' target of Makefile.am to see exactly how it works <jgarte>Blackbeard: Just watching the videos now. They are great! I'm at part one of packaging <jgarte>nnn is out of date. I would like to update that <Blackbeard>jgarte: that shouldn't be hard. It seems like it is a good way to stact <jgarte>nnn is up to date in nixpkgs so I would like guix to be the same <Blackbeard>jgarte: wonderful. Watch the videos and let me know if you need any help. <jgarte>Blackbeard: I'll be right back. Almost done watching them. <jgarte>Blackbeard: All most set up. waiting for "make" to finish <jgarte>Blackbeard: Almost set up. waiting for "make" to finish <jgarte>Blackbeard: still compiling .go files in /gnu/packages/ (%68 done) <Blackbeard>jgarte: no worries, have you looked the definition of nnn already? <jgarte>Blackbeard: hmmm 404 error not found <jgarte>Blackbeard: I found an alternate link <jgarte>Blackbeard: at 86% (I have an old Thinkpad T400 :) <Blackbeard>jgarte: that's alright, why don't you start by copying the definition of nnn in an empty file <Blackbeard>jgarte: have you read the cookbook on the tutorial in the blog? <lfam>Looks like ISC's versioning scheme has changed since the last time I paid attention <jgarte>Blackbeard: Yes, but I have not assimilated it all yet <lfam>Maybe we can remove 'bind-release-type' and 'bind-release-version' from the isc-dhcp package <jgarte>Blackbeard: Ok, I've edited the nnn package and changed the version to 3.1 in the definition <jgarte>trying to download the base32 sha to paste it in now <jgarte>the base32 is incorrect in that definition <jgarte>unfortunately (or fortunately I did the whole process thus far in eshell) and my original user environment variables are not setup in the dev environment for emacs <jgarte>so dired or find-file does not work in the dev environment <jgarte>I just opened a shell outside the environment to do the editing/pasting/etc... <Blackbeard>It is ok. So far I had not been using the tar file but the hash and used git-fetch <Blackbeard>jgarte: I am not sure which one is preferred, but I like git-fetch more <jgarte>Should I change the nnn package definition to use git-fetch instead of url-fetch? <jgarte>Blackbeard: My guix environment cannot find git even with ./pre-inst-env I'm trying to create a git branch <jgarte>Blackbeard: I can setup a git branch outside of the guix environment but inside the environment the git binary is not available <jgarte>Blackbeard: $ ./pre-inst-env git checkout -b nnn-update./pre-inst-env: line 62: exec: git: not found <ecbrown>guix environment guix --ad-hoc git strace texinfo <Blackbeard>jgarte: wait, can you paste your definition please ? <jgarte>ecbrown: thanks ecbrown. Once I have built the environment with "guix environment --ad-hoc" can I add packages that I forgot to add via "guix package -i" ? <jgarte>In others words what is the correct way to "append" packages to an environment after its' creation? <apteryx>well, I'm not sure in the end. It seems to affect a mix of GnuPG from master (to become 2.3) and 2.2, rather than say, 2.2 only. Not sure. <lfam>apteryx: I think it should be working "out of the box" on Guix since commit e5b44b06b3fb19c897fb3e430bd41941905e101f <lfam>apteryx: Are there more reports of problems? <lfam>Or is this some other problem? <lfam>Blackbeard: It's recommended to install adwaita-icon-theme or hicolor-icon-theme, or maybe some other one <Blackbeard>lfam: but as a package if I want to add a cursor theme <lfam>Like, you want to package a new cursor theme? <apteryx>lfam: Not yet more reports of problems, no. I'm stuggling to debug this. <jgarte>Blackbeard: git is not working in the environment so I cannot create a branch in it. Should I run "guix package -i git" to add it to the environment? <lfam>Blackbeard: Hm... not sure! Where are adwaita-icon-theme and hicolor-icon-theme? <lfam>apteryx: It looks... confusing <apteryx>I started gpg-agent with: 'gpg-agent --debug-pinentry --debug 1024 --server', but it's dead quite when issuing 'echo test | gpg --clear-sign'. That later command prints: gpg: signing failed: No pinentry <apteryx>s/That later command/The later command/ <lfam>And you have a pinentry package installed, apteryx? <jgarte>Blackbeard: git is not found in the environment that I set up with "guix environment". With or without ./pre-inst-env <jgarte>I definitely have git installed on my machine it just can't be found once I run "guix environment" <lfam>jgarte: That's expected jgarte. `guix environment` works by changing environment variables such as $PATH, which is how your shell finds programs like git <lfam>Blackbeard: It's up to you where to put it. Whatever makes sense to you <Blackbeard>arc-theme and arc-icon-theme are on gnome.org too <Blackbeard>I wonder if there should be a module eye-candy.scm hahahha <jgarte>Blackbeard: does the above command append git to the environment I already created? <jgarte>Blackbeard: or does it create a whole new environment? <apteryx>lfam: but I've tried ruling out the new patch to auto-find pinentry, by installing the older version 2.2.19. It didn't solve the issue, sadly. <lfam>apteryx: It sounds like you need to pass --yes, which is an amazing option <jgarte>Blackbeard: yes, it appends git to the current environment? Wasn't sure which of my questions you were saying yes to <Blackbeard>jgarte: I am pretty sure it is the same. But I am not 100% sure <lfam>I can't tell from the upstream bug discussion if the underlying problem is that gnupg is actually failing to find pinentry, or if that error message is incorrect. You could use strace to find out <Blackbeard>Sorry matrix lags and you asked the second question before my message went out <lfam>Blackbeard, jgarte: When using --pure, every time you do `guix environment` it starts from scratch <jgarte>Blackbeard: no worries just trying to clarify <apteryx>there are two things which I did which might have led to this: 1) stow a version config of my .gnupg directory (it creates symlinks of configs such as gpg-agent.conf to a git versioned directory). or 2) update my profile and system to latest Guix. <jgarte>Blackbeard: thanks for all the help thus far <jgarte>lfam: thanks for the info. That's good to know. <lfam>It's fun to run `env` after `guix environment ...` to see what it does <apteryx>I vaguely remember GnuPG not liking symlinks in the past, perhaps i should get this out of the equation as a start. <lfam>You might need to add it to a --pure environment with '--ad-hoc coreutils' <lfam>Eventually you will know these things too <dissoc3>Blackbeard: sorry for delay. you asked what xrandr command i was running. I was just using what was generated by arandr <lfam>`guix environment` used to work in a more transparent way, because it would make PATH variables like PATH=/gnu/store/...-curl:/gnu/store/...-gnutls:/gnu/store/...-bash <lfam>But now it creates a profile and makes that your PATH, so you don't see all the store items unless you look into the profile <lfam>But, it's still easy to poke around <dissoc3>i tried to write an xorg.conf file and shove it in (extra-config ...) but that didnt work. would that even work? <pkill9>it should work, that's it's purpose <jgarte>lfam: so running guix environment without --pure will append packages to the current environment and profile? <Blackbeard>dissoc3: ok lets go from the start. What do you want to do? <Blackbeard>jgarte: you should use --pure for guix patches ! <lfam>Yes, --pure is the way to go in most cases <jgarte>So should I just build the whole environment over again and include git this time? <dissoc3>Blackbeard: so i have 7 monitors. right now im just trying to get 4 to work with one video card (nvidia 960) using stumpwm. stump loads and 4 monitors work but they are not arranged how I want. So i tried using arandr and every time i try to apply the new arrangement it logs me out and takes me back to gdm. <jgarte>If someone follows the video tutorials they will get to the part that says to make a branch and be stuck without git in the development environment <dissoc3>Blackbeard: i also tried to write a xorg.conf file but then gdm wouldnt even load <jgarte>Should the guix environment command in the video tutorial be updated to mention to install git? <lfam>jgarte: You only need to be in the development environment while building Guix. You can leave it while writing code and using Git <jgarte>@3:16 of packaging tutorial video (part two) <lfam>For example, I am rarely spending much time in the development environment. Only when I am done writing some code and want to test it do I enter the environment <lfam>Another way to handle this would be to use two terminal windows, one for coding and version control, the other for building Guix <jgarte>lfam: Ohh ok. I didn't realize that. I was trying to do coding and building in the development environment <apteryx>lfam: I logged out... Back in... And, bam, pinentry works. <jgarte>lfam: that's very helpful information to know *apteryx wasted 2 hours on nothing <apteryx>haha! Yes, there was probably some stale environment variable captured at my previous login, that caused an issue after reconfiguring my profile. <lfam>There are three hard problems in computer science: Naming things, cache invalidation, off-by-one errors, and environment variables <jgarte>:lfam how can I test that I am in the development environment <jgarte>:lfam is there a quick way/trick to know? <jgarte>I've closed and opened so many terminals now that I am not sure I am still in it <Blackbeard>dissoc3: what happens if you run xrandr commands inside a shell <Blackbeard>(run-shell-command "xrandr --output HDMI-1 --mode 1360x768") <dissoc3>Blackbeard: good idea. i will try that <Blackbeard>jgarte: I use the videos, I never had a problem with git :/ I don't know why you are having this problem <Blackbeard>jgarte: I recommend using emacs-magit, but that is just a preference hahaha <jgarte>Blackbeard: I think it is because I was trying to use git inside the container and the environment variables where not setup for it <Blackbeard>jgarte: yes I saw it but I never had trouble to run git inside the [env] without the ./pre-Inst-env <jgarte>Is there something like this built into guix to let you know if your current terminal is in a guix environment or not? <jgarte>Blackbeard: maybe it has something to do with eshell (I am using emacs' eshell to follow the tutorial) <dissoc3>Blackbeard: from the terminal the same outcome. <jgarte>I would have used zsh or something else but I didn't realize it until the whole environment was setup and didn't want to start over again <apteryx>do we do something about embedded fonts in Qt applications? <Blackbeard>jgarte: don't worry about it too much for now. Just make sure everything works <jgarte>I think I've answered my above question: ls "$GUIX_ENVIRONMENT/bin" <dissoc3>Blackbeard: I tried to use slim but I failed at that <Blackbeard>jgarte: my eshell line changes color when inside an env <dissoc3>Blackbeard: initially I just wanted to run startx but for whatever reason that seems really hard? <jgarte>Blackbeard: hmmm I think mine is not setup to do that. Will look into it. Thanks! <Blackbeard>jgarte: but did you succeeded at building the package ? Or is it still running , <jgarte>I just started it it now with guix package -i nnn <jgarte>where the nnn package definition lives <jgarte>But it says that it will install nnn 3.1 so I guess that is good news <jgarte>Just waiting for the compilation process to finish <apteryx>wow, google-font-noto weighs 736 MiB <sirgazil>I just pulled, reconfigured the system with my GNOME + GDM configuration, and GDM doesn't start. <Blackbeard>dissoc3: but what is the xrandr command you ran? <sirgazil>I see "New session c1 of user gdm", then some other messages, and then "Removed session c1" <jgarte>Is my environment not pure any longer because I ran the prior command? <jgarte>Blackbeard: I did watch the third video but I forgot that detail. Sorry <sirgazil>I continue to have a bad experience with Guix releases :( <bavier`>sirgazil: I've had issues with gdm failing to start in the past <bavier`>I seem to have fixed it, lemme see if I can remember how <Blackbeard>jgarte: I wrote down everything in the videos so I can easily follow what I have to do next <jgarte>Blackbeard: I should have done that. I will make an ordered list for myself. Thank you! ***calher is now known as KE0VVT
<bavier`>sirgazil: sorry, I'm not sure exactly what "fixed" that issue for me; I did recently remove the "spice-vdagent-service" <Blackbeard>lfam: do you know if there had been any work on packaging searx <lfam>Yes, check messages from January and February 2017 on guix-devel <sirgazil>bavier`: I don't have that service in my configuration. Thanks for taking a look anyways. <jgarte>Blackbeard: I will try packaging nnn tomorrow again and will report here if I run into any issues after running through the steps of the tutorial. Thanks for all your help. <sirgazil>in "/var/log/debug" I see "Apr 15 22:39:14 localhost gdm: Child process -538 was already dead." <Veera>sirgazil: filed a bug report #40652 <Veera>sirgazil: happened to me since april 11 <sneek>Welcome back guix-vits, you have 1 message! <sneek>guix-vits, nckx says: I see I sent it too late ☹ Sorry 'bout that; mail troubles. (Client, not server, the actual mails are safe.) <Veera>sirgazil: Is there anyway to debug gdm atleast gdm logs; I can't enable the debug option! <Veera>sirgazil: I can't trace where and when the change happened. Git log does not says much. <apteryx>lfam: ah! now I get my pinentry for GPG keys access, but not for SSH keys access (I use 'enable-ssh-support' in my gpg-agent.conf). <apteryx>lfam: ah, got it. After using GNU Stow to deploy my versioned '.gnupg' config, some SSH keys were missing from under ~/.gnupg/private-keys-v1.d. I could reimport them in my private keyring using 'ssh-add path/to/ssh-key', and encrypting it with a passphrase. <apteryx>raghav-gururajan: I've merged the remaining cosmetic patch and closed the linphone tracker. Congrats! <apteryx>linphone crashes when trying to click on the orange top right icon with the error: qrc:/ui/modules/Common/Form/DroppableTextArea.qml:3:1: module "QtQuick.Dialogs" is not installed <Veera>Hey Why are not replies to my submitted bug#40652 are coming to my mailbox? <rekado_>Veera: did you use the web interface? <rekado_>I saw an email queued up there, but it didn’t get through <rekado_>I have a few appointments today, but will check on this later <Veera>rekado_: where is the web interface? <rekado_>it’s at issues.guix.gnu.org but it’s currently in read-only mode and frozen to address a problem. <rekado_>hmm, cuirass is kinda slow, even when running it locally. <rekado_>some database queries take 17+ seconds. <rekado_>this explains why the pagination is configured to have only 10 items per page. <rekado_>heh, the index on the builds table has been lost <starcrATI>While trying to reconfigure my system, the build for etc.drv failed ... the log says ERROR: In procedure symlink: File exists ***apteryx is now known as Guest40532
***apteryx_ is now known as apteryx
<dftxbs3e>civodul, yay release! :-) - hope to resume work on powerpc64[le] soon.. I work at an hospital and with the crisis my time is 100% there. <bricewge>Hey dftxbs3e, hope you are doing okay on the front-line <dftxbs3e>bricewge, I'm only in a computing department so I'm OK :-) <bricewge>starcrATI: I had a look and I have no idea where it can come from, sorry <civodul>hey dftxbs3e, good luck with your work! <bricewge>starcrATI: Can it be rottlog-service-type? <bricewge>It has been added to %base-services, try removing it maybe it's duplicated. <rekado_>hmm, “guix gc” is very slow on ci.guix.gnu.org <rekado_>it spends a lot of time trying to delete unused links <rekado_>maybe at the size of the store on ci.guix.gnu.org deduplication at the disk level would be better <sirmacik>btw. anybody used inotify from guile? ;x <civodul>rekado_: "deleting unused links" has always been slow :-/ <rekado_>civodul: the draft looks good to me. I don’t really have any bioinfo news other than the mentioned R packages. <civodul>oh wait, i can add GWL under "Packages" <rekado_>(even though I haven’t been able to even look at the GWL since going back to work) <ecbrown>i'm a big R user, and notice that there are many r-* pacakges. i guess my question is, should i bother "flooding" guix with contributions from the many of 10,000+ packages of cran? <ecbrown>(sorry for interupting current convo) <rekado_>ecbrown: I have a Guile script for mass imports <ecbrown>rekado_: i'm willing to help, just wonder there are numerous packages where i suspect libs from guix proper are needed <rekado_>the big problems with R packages are that the declared inputs on CRAN are sometimes bogus and that the descriptions often need a bit of work. <ecbrown>i used the importer to great effect, e.g. r-brms <dhanvanthri>Hey guys, I'm just trying to get cdda with tiles working straight from the binary, I'm using pkill9's fhs service, and I basically just stole the relevant parts of their config from their the gitlab page. I'm getting the following error, and I have NO idea how to diagnost/solve this problem <dhanvanthri>\guix system: error: getting status of /gnu/store/.links/026z1vrprv88zrwg5qp5ak0z5dfg2ig2syq306ib8w7snc90kggw: Bad message <dhanvanthri>This is when trying to do sudo guix system reconfigure btw <ecbrown>rekado_: oh, yes, i mean, was referring to occasions where r package install will give: "you need to install such and suchf rom apt/yum" <rekado_>ecbrown: I guess we should coordinate our efforts, e.g. by bringing the discussion to guix-patches@gnu.org <dhanvanthri>civodul: That's the literal paste that I get back as an error <ecbrown>no problem. oh, thanks for r-tidyverse. saves a world of headache. and rstan <rekado_>ecbrown: yeah, in those cases it’s just a matter of figuring out what library is needed. <dhanvanthri>civodul: Btw, tyvm ludo. This is an amazing piece of software. <rekado_>ecbrown: I had some WIP for ROOT, but it’s very difficult <rekado_>so not all R packages can easily be added, but most of them are not that difficult <rekado_>some CRAN and Bioconductor packages have non-free licenses, which is a big problem. <ecbrown>ok, so i will plan to edit them in emacs and lint them <rekado_>especially for the CRAN packages the licenses are sometimes unclear because the code was ported from S. <rekado_>when you have a bunch of packages that you want to claim please announce this on guix-patches@gnu.org (and put me in Cc) <rekado_>this way we can avoid stepping on each others toes <civodul>dhanvanthri: is that on NFS or something? <dhanvanthri>civodul: What is NFS? If that's a filesystem, this is just ext4 <civodul>ah ok (NFS is a "network file system") <civodul>then i don't see how stat(2) can return EBADMSG <rekado_>dhanvanthri: NFS is Network File System; it’s used when you mount a remote file system (from an NFS server) on your local system. <rekado_>we have 600+ million inodes in /gnu on ci.guix.gnu.org <dhanvanthri>civodul: Yeah, I only have a single thing mounted, and it's my whole filesystem and it's local and ext4 <rekado_>oops, “main: Assertion `count < MAX_ENTRIES' failed.” *rekado_ increases MAX_ENTRIES <efraim>I feel like I'd have less machine-usage conflicts and fewer gc sessions if I work on the ppc bootstrap from an aarch64 board ... <ecbrown>guix package -i icedtea works for me <ecbrown>if i type: guix environment icedtea -- javac -version <efraim>wouldn't it be 'guix environment --ad-hoc icedtea:jdk -- javac -version' <efraim>or whatever the later versions of java are called instaed of icedtea <rekado_>for later versions use the openjdk package <efraim>i knew it wasn't called java, couldn't remember the actual name though <efraim>the static guile I copied to my ppc box worked, so now to actually update the guix tree there and try building <kraai>When I try to add a calendar in GNOME Calendar, it crashes. When I try to debug it with gdb, it doesn't look like there's any debug information. How can I get debug information? *ecbrown just rolled a docker + restrserve <ecbrown>(with a bunch of other stuff to predict out of h2o) <ecbrown>making these docker images like cookies, up arrow edit return <civodul>ecbrown: who well would "guix pack" suit your needs? <ecbrown>i am using that now, guix pack -f docker -C none ... <ecbrown>then load that docker file any darned place <ecbrown>i'm going to set up a battery of these behind nginx <ecbrown>it's kind of sick what you can do with a 64-core threadripper :-) <ecbrown>also just runs in a container, or any other abstraction. but glad to have this in guix cuz it gives options <civodul>cool, i thought you were using a Dockerfile or something <civodul>"the default channel requires some github account setup" ?! <civodul>someone with a Reddit account should reply <efraim>I responded a few hours ago and I found their thread on help-guix. I don't feel like the two mesh at all <efraim>I figured they mixed up 'guix refresh' and 'guix pul && guix upgrade' <civodul>that means they didn't read the manual nor --help <civodul>perhaps "refresh" is a confusing name <efraim>not sure if it's a bug or not, memory usage "shot up" to ~1.5G while compiling crates-io.scm and then it doesn't look like it was released <efraim>then gain I checked with 'free -m' so it's hardly a real test <civodul>maybe "guix help" should separate developer commands from "user" commands <civodul>efraim: it's quite possible i'm afraid :-/ <efraim>I was going to suggest that or "this is a developer command" but we didnt' want to separate users from developers <civodul>in the manual we try to be clear about the intended audience of a command though <efraim>still guile-2.2. It's using the Debian packaged libraries for compiling the guix repo *efraim is working *slowly* on 32-bit powerpc <civodul>though there's still a lot of room for improvement <efraim>I wanted to look into building guix/base16 and the like and dropping the stack and then compiling the pacakges and build systems and then only afterward compiling the system and scripts <efraim>or I forget if the scripts could be before the packages <civodul>i wonder if you could build & run guix-daemon, and then run "make as-derivation" <efraim>i suppose it's worth a try, IIRC the daemon and pre-inst-env are ready to use before loading gnu/* and guix/* <rekado_>civodul: the issue is blank because of the update pause for issues.guix.gnu.org <rekado_>luckily I *just* got rsync access to debbugs (Glenn gave it to me earlier but adjusting the firewall only just happened) <rekado_>so once the performance test on ci.guix.gnu.org has completed I’ll sync all bugs from there and resume operations for issues.guix.gnu.org <PotentialUser-3>Hi, love your work. Just trying 1.1.0 now and the graphical installer fails at partitioning, brings me back to language choice again (tried this three times now). Any ideas? <apteryx>raghavgururajan: have you experienced crashes also when using linphoneqt? It's not currently usable (but close, it seems). <sneek>apteryx, you have 1 message! <apteryx>For example, we can't visit the preferences menu without it crashing. The round, orange button on the top right also trigger a crash, mentioning the lack of QuickDialogs. It seems it needs a couple more Qt QML (unpackaged) dependencies <rekado_>I hope we’ll have enough space for all of debbugs. Would make it easier to develop missing debbugs features in mumi. <civodul>oh right, all of debbugs can take quite some space <rekado_>civodul: links-traversal is *slow* on ci.guix.gnu.org :-/ <civodul>perhaps we should store it on a squashfs? <rekado_>the first run (without dropped caches) in mode 3 took 67 minutes. <rekado_>I wanted to quickly send a few benchmark results but this is taking a lot longer than I thought. <civodul>i was hoping statx would help a bit, haven't benchmarked it <rekado_>mode 3 was supposed to be the fastest of the bunch, wasn’t it? <civodul>can you try with statx instead of stat? <civodul>as in commit 7738a72186583afb3bb2e0a866c8aba130372400 <civodul>on a warm cache it probably makes no difference <civodul>especially since we have plenty of RAM there <Veera>PotentialUser-3: try manual install <Veera>PotentialUser-3: same happened to me with 1.0.1 version <Veera>PotentialUser-3: though has not tried 1.1.0 <civodul>rekado_: also, we should bench on an idle machine (i just noticed a download from berlin that stalled a bit :-)) <rekado_>“I also found the mailing list not particularly helpful and sometimes even downright rude.” — really? :-/ <civodul>perhaps we could do useful profiling on one of the build nodes, for instance <rekado_>okay, I’ll try on one of the build nodes and abort this run. <lprndn>I was trying to build a custom kernel for an ARM board. Getting errors. Just found that the problem was that the git-checkout/include was added to CPATH creating conflicts. My question is why did it happen..? <lprndn>(and not in the usual kernel build) <civodul>lprndn: how did you create your custom kernel? <civodul>efraim may be familiar with those things <lprndn>civodul: with make-linux-libre*, changing source, #:defconfig and #:extra-version. <raghavgururajan>apteryx Yes, it crashed. I saw you message regarding a missing package. I am packaging it as we speak. :-) <apteryx>raghavgururajan: excellent, thank you :-) <apteryx>rekado_: Users complaining on Reddit? Can't be. <janneke>grmbl, python-boot0 needs a similar change to python-2.7, but not to python which is python-3.8, because build system changes between 3.5.9 and 3.8.2 ... /me goes to check git to make a proper comment and fix <efraim>sputny: there's only the one help-guix mailing list but it accepts emails in multiple languages <raghavgururajan>apteryx We just need to add 'qtquickcontrols' as input, along with 'qtquickcontrols2'. <mbakke>ooh, substitute coverage on core-updates for x86_64 is now at >= 83.4% <mbakke>at this rate it will still take weeks before armhf and aarch64 catches up though <allana>Hi Guix. Anyone else having issues running "guix pull"? I have not been able to for the past couple of days. Could it be releated to the new release? I'm getting the error "failed to produce output path '/gnu/store/blahblah-guix-package-cache'" <mbakke>allana: are you using any custom channels? <rekado_>hmm, I get “implicit declaration of function �statx�;” *rekado_ really doesn’t know C <rekado_>I thought I already had the right includes…? <pkill9>does browserpass-native not work for anyone else in either icecat or ungoogled-chromium? ***rekado_ is now known as rekado
<rekado>finished syncing debbugs; it’s just under 10G <rekado>but there are no ready-to-use mbox files; have to extract those from .log files that contain other stuff. <civodul>rekado: see the list of includes in "man statx" <rekado>civodul: I have them all, but still get errors. *rekado sees this comment in the CGI script: # This is craptacular. <civodul>rekado: #define _GNU_SOURCE 1 maybe? <sputny>efraim: allright. Thanks for clarification. <rekado>civodul: hah, that’s it! I tried “-D__GNU__” and “-D__USE_GNU” before, but I have no idea what I’m doing <civodul>yup, don't change __GNU__ and __USE_GNU <civodul>the former is defined on GNU/Hurd and the latter is internal <sammich>hey im trying to write a package for guix (installed on opensuse) and im getting an error /etc/services cant be found, any idea what thats about? <mbakke>sammich: `/etc/services` is not available in the build container <sammich>I see, but whats it being used for? I dont refereence it in the package definition and it doesnt get as far as downloading the package for the package itself to be relevant <pkill9>is it possible to route specific network traffic through a proxy? <pkill9>and if not specific traffic, then all network traffic? <civodul>sammich: what command did you run and what's the exact output, to make sure there's no misunderstanding? <efraim>note: currently hard linking saves -2.93 MiB <civodul>sammich: the build environment for downloads contains /etc/services bind-mounted from the host <civodul>thus you need to make sure that file is available on your system <civodul>(/etc/services is a database that maps "http" to 80, and so on) <civodul>so you need to install the package of the host distro that provides that file <sammich>civodul: ah i see, so it turns out open suse moved it from /etc/services to /usr/etc/services, ill try linking it back *civodul looks at jonsger <sammich>yup, well linking it seemed to fix it, thank you for the help <civodul>rekado: that's by Bernard of SuSE, right? <efraim>malloc.c:2382: sysmalloc: Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed. <efraim>error from guile-bootstrap-2.0 on powerpc <allana>mbakke: Yes, I have a custom channel. <efraim>civodul: thanks, that's what I suspected. I'll probably try dropping glibc to a lower version for the next round <apteryx>raghavgururajan: you mean core-updates, right? :-) <sneek>Welcome back apteryx, you have 1 message! <apteryx>raghavgururajan: sounds good. I'll give it a try a bit later. <rushsteve1>Hello. I'm trying to use Guix from git to test a package I want to contribute, but every time I run `./pre-inst-env guix build package` I get the error: `no code for module (gcrypt hash)` <raghavgururajan>apteryx Currently it is in core-updates. But I think it is ready to be pushed to master. as the crash is fixed now. <lfam>rushsteve1: You need to add guile-gcrypt to your environment. Try `guix environment --ad-hoc guile-gcrypt` <nckx>Hi Guix. What's the deal with A0C5E3522EF8EF5C64CDB7F0FD73CAC719D32566 (bavier, commit 77704cb1). <madage>civodul, mbakke: FYI, the possible bug with substitutes I reported here days back turned out to be related to a misconfigured http-proxy on my system config <rushsteve1>lfam: Oh, yeah. That would make sense wouldn't it... thanks for the help! <madage>afaiui, the recent commit that enabled a runtime http-proxy setting made my config error to break guix <lfam>rushsteve1: I have ended up just installing guile-gcrypt into my profile with `guix install guile-gcrypt` because I do a lot of Guix development and it saves time <madage>so notabug afterall and I won't report it, thanks for your help <rushsteve1>lfam: I was running in a pure environment, but I should probably just install it to my profile too <lfam>Right. You can also compose environments like this: `guix environment --pure guix --ad-hoc guile-gcrypt` <apteryx>raghavgururajan: the reason linphoneqt is on core-updates is/was because we needed to build it with a newer Qt/GCC to prevent a compilation failure, IIRC. Does it now build on master? <guix-vit`>nckx: `xplanet -window -body MARS` seem to work, "somewhat" <rushsteve1>lfam: Update, installing guile-gcrypt didn't fix the issue <rushsteve1>Same error as before `no code for module (gcrypt hash)` <lfam>Hm... any ideas, anyone? <bricewge>rushsteve1 Did you tried the last command lfam suggested you? <lfam>Changing to subject to icon themes, what's the current consensus on whether or not they should be hard dependencies? Previously, we expected users to install them, but I notice that a lot of packages are using them as inputs now <raghavgururajan>apteryx, That's correct. I have made it to build it sucessfully on master by using gcc-5. <rushsteve1>bricewge: yeah that's what I did at first, then I tried guile3.0-gcrypt and a few other things. No luck. <apteryx>raghavgururajan: I think master is now using gcc7. (gnu packages commmencement)'s gcc-final ultimately inherits from gcc, which is defined as (define-public gcc gcc-7) in (gnu packages gcc). <lfam>rushsteve1: After you enter the environment, try re-doing the configure and make steps <lfam>And if you have set a custom GUILE_LOAD_PATH environment variable somewhere, make sure it isn't making it into the pure environment (for example if you set it from bashrc or zshrc <apteryx>raghavgururajan: But that's nothing new (2018). So the original problem building linphoneqt must have been with Qt, correct? <raghavgururajan>apteryx That's correct. But if one declares ("gcc" ,gcc-5) as native-input, build-system uses gcc-5 instead of gcc-7. <bricewge>rushsteve1: Hum that should have worked. Can you share the exact command line you are using that generate the error? <apteryx>I'm not sure that'd be reliable without filtering out the gcc7 stuff that comes with in the implicit inputs. Danny had commented about this, and chose core-updates because there it works without doing anything special. I think we should leave it there, until the next core-updates merge. <rushsteve1>bricewge: `./pre-inst-env guix build midori --keep-failed` <apteryx>mbakke: when was core-updates last merged into master? I fail to find this information in the git log. <lfam>rushsteve1: From within the environment, please run `env` and share the results of <https://paste.debian.net>. You may need to also add coreutils to the environment in order to get the `env` command <lfam>rushsteve1: Also, you could poke around in the profile pointed to by GUILE_LOAD_PATH in that `env` output, and see if it contains the Guile gcrypt module *ecbrown had forgotten what a beast guile-emacs is to compile <allana>Are channels broken with the new release og guix? <lfam>Okay, I actually have the exact same profile for GUILE_LOAD_PATH as you rushsteve1 :) <lfam>The z8irn4kxv6s... store item <lfam>Are you familiar with strace? <lfam>You could also add strace to the environment and then re-run the command like `strace -f ./pre-inst-env guix build ...` <lfam>The environment looks correct so I'm not sure what's up. Probably somebody else could figure it out right away... <lfam>You might want to set up logging like `strace -f ./pre-inst-env ... 2>&1 | tee ~/tmp/log` <pkill9>my system build and my root user's guix are built from the same guix commi,t yet it's rebuilding stuff when i reconfigure, i don't get it <lfam>Yeah, that's normal. But if you search in there for gcrypt you'll find the right info <pkill9>i don't think i change my config file either <rushsteve1>It seems like it's trying to load from the wrong path, despite GUILE_LOAD_PATH <lfam>Did you re-do configure and make since creating the environment with '--ad-hoc guile-gcrypt'? <cbaines>rushsteve1, I'm not following along well, but mixing Guile 2 and 3 things can go wrong <rushsteve1>lfam: I tried that earlier and nothing changed, but I can try again <rushsteve1>cbaines: Yeah probably, do you know how I'd fix that? <lfam>I would try that, and also try `./pre-inst-env env` <cbaines>I've found I need to clear GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH when using Guile 3 for Guix <cbaines>rushsteve1, are you trying to run Guix with Guile 2 or 3? <lfam>Using Guile 3 is still a special case, right? Like, you'd have to go out of your way to do it? <rushsteve1>cbaines: inside the environment it seems to be using Guile 2.2.6 <lfam>rushsteve1: I notice in the strace log that a different profile is being looked up, /gnu/store/fq44bza85r0... profile <lfam>That's why I think you need to regenerate your pre-inst-env file <lfam>I bet if you look in that profile directory, it's missing gcrypt <rushsteve1>lfam: yeah I added strace to the environment, and gcrypt is still in there <rushsteve1>Full env command `guix environment guix --pure --ad-hoc guile-gcrypt strace` <lfam>Okay, I'm going to try to reproduce this from a fresh Git checkout <lfam>Outside of the environment, can you do `guix describe` and share the result? If that doesn't work, then `guix --version` <lfam>Also, what Git commit are you on? <lfam>And in the Git repo, which commit? <rushsteve1>Just pulled to 7adf6f1be9 so I'm going to try a full rebuild <lfam>Alright. Currently waiting for `guix pull --commit=90ec7085793700552359d9d409287528437f0280` to complete so that I can match your Guix state <pkill9>why was pulseaudio designed in a way that they expect it to close after a period of time? it just seems unneccessary, a desktop's sound system is something you expect to always be there <pkill9>and when pulseaudio closes it disconnects my bluetooth headphones <pkill9>i guess maybe i should have it configured to reconnect to them when pulseaudio starts <pkill9>maybe that's the real issue for me, lol <lfam>Building Guix now rushsteve1.... <lfam>Changing the subject... tzdata is not even qualified for the staging branch now. Changing it would cause 1439 rebuilds <lfam>We need to look into this and try to reduce that number <cbaines>Is tzdata something that changes often? <mothacehe> civodul: Found out that installer error reporting is broken in 1.1.0 :( <rushsteve1>It shouldn't be, timezones rarely change do they? <pkill9>I believe I *finally* worked out the weird behaviour with chromium and pulseaudio <pkill9>what's happening is that when pulseaudio isn't running, i think if you start chromium and you view a video with it, if pulseaudio isn't runninghten it uses alsa <pkill9>and then if you run pulseaudio, pulseaudio doesn't connect to alsa <pkill9>hence why in pavucontrol it says 'dummy output' device <lfam>rushsteve1: The time zones actually change a lot. Several times per year and in a huge variety of locales <lfam>Time zones are something people make decisions about on a regular basis <lfam>Often with only a few days notice <lfam>So, that's why I think it's important to be able to keep them up to date <lfam>I've done work in this area previously to keep the number of rebuilds much lower than they are now :/ <lfam>It's a particular problem for Guix relative to other distros because they have no trouble updating the time zones at a moment's notice. We really should not let Guix get out of sync here <rushsteve1>Does it have to do with how I'm running the daemon? <lfam>How are you running the daemon? <rushsteve1>`sudo -E ./pre-inst-env guix-daemon --build-users-group=guixbuild` <lfam>Not sure but it's a wrinkle <rushsteve1>With a main daemon run by systemd that *should* be unrelated <lfam>How are you configuring the build, btw? You are doing `./configure --localstatedir=/var`, right? <roptat>mh... I've downloaded a substitute for texlive, but I'm missing disk space for applying a graft to it :/ <roptat>is there a way to add the substitute to the gc roots so it won't be deleted by guix gc? <lfam>roptat: Yes, symlink the store item into /var/guix/gcroots <lfam>I have a long-term symlink in there for texlive-texmf <roptat>looks like I was able to free quite a bit of space, and texlive was preserved, so thank you! <lfam>rushsteve1: After building the fresh Git checkout using the same Guix as you, I can do `./pre-inst-env guix build hello`, if I am in the `guix environment --pure guix --ad-hoc guile-gcrypt` environment. And that is having guile-gcrypt from my normal profile <lfam>So, I'm not sure what's up here <rndd>hi everyone! i found http-proxy variable for guix configuration. But how i can set up system proxy settings? <cbaines>rndd, I see a "Network Proxy" setting in the GNOME Settings interface, if you're using GNOME/Network Manager <rushsteve1>lfam: yeah it looks like the missing --localstatedir on ./configure might have been it <rushsteve1>Or actually, I just realized I forgot to run the daemon again with ./pre-inst-env when I did the guix build. <lfam>Unless you are testing changes to the daemon there's no reason to run it from the Git repo <guix-vit`>IWAY inkthay eway ouldshay anslatetray ethay Eferenceray Anualmay otay Igpay Atinlay, otay attractway BSDAY-eoplepay <guix-vit`>`pig <<< 'I think we should translate the Reference Manual to Pig Latin, to attract BSD-people'` ***atw` is now known as atw
<rushsteve1>Because it just worked, built all the way and everything <Blackbeard>guix-vit`: how do you know my friend who uses OpenBSD and maintained LibertyBSD loves pig latín? <rekado>ecbrown: don’t bother with guile-emacs yet. It’s currently broken. <rekado>the compilation takes *much* too long and eventually times out. <rekado>I started to rebase the wip-elisp branch of Guile to the latest 2.x stable version to see if it makes any difference. <lfam>You're welcome rushsteve1 <mbakke>apteryx: there have been a couple of merges in which master was merged to core-updates, and then that merged core-updates was pushed to HEAD <mbakke>I've contemplated a couple of times how to track moving HEADs in git, but haven't gotten around to actually scripting it yet. <mbakke>apteryx: so to find the last merge, you'll need to look at git's graphs and see when it "changed lane" <apteryx>mbakke: so core-updates was forced push on master at some point? <mbakke>apteryx: no, git allows that because that new merged branch is a direct descendant <mbakke>i.e. you can merge master into core-updates now, and push that new branch back to master <mbakke>I think we should discourage such merges though since it's difficult to figure out when it happened <guix-vit`>Blackbeard: i didn't know about that, but read that OpenBSD maked some security patches to bsd-games. <mbakke>apteryx: it may be easier to scrape the guix-commits archive <apteryx>I'll explore the graph when I have a bit of time later, thanks <lfam>I'm curious where you found reference to 3.1.0? <lfam>Maybe we should patch libical to respect TZDIR like in nixpkgs <lfam>They don't give any indication of when this might be release, though <lfam>Ohhh I found their release notes with "future" changes <lfam>I wonder about the timeline <lfam>I regret not noticing this earlier in the core-updates cycle <lfam>Maybe for the next staging cycle we can squeeze it in <lfam>The tzdata-for-tests package is woefully underused :( ***vagrantc_ is now known as vagrantc
<cbaines>how is core-updates coming along mbakke? <mbakke>cbaines: for x86_64 it's pretty much on par with 'master', but armhf and aarch64 are still a few weeks off <cbaines>I've noticed that it's been evaluated successfully lately on ci.guix.gnu.org <lfam>Do we have any visibility into substitutes requested per-architecture? I'm curious about how much armhf is actually in use these days <lfam>It's really a poor platform for general purpose computing and 64-bit ARM is so inexpensive now <cbaines>I've been looking in to why the Guix Data Service can't process core-updates <mbakke>I don't think we have such metrics lfam. <cbaines>I believe I've tracked the issue down to a regrssion when building Guile with libgc 8, rather than 7 <mbakke>Anyone up for packaging 'piwik'? <cbaines>mbakke, lfam Guix has a package for goaccess. I've used that when looking at NGinx logs before <cbaines>you could probably just run that against the logs on ci.guix.gnu.org <cbaines>mbakke, back to core-updates though. I've just built Guile 3 with libgc-7, and I can't reproduce the issue. So I'm wondering if it would be feasible to stick with libgc-7 for now? <cbaines>(I'll send an email about this shortly as well) <mbakke>cbaines: I guess we could graft it <mbakke>though it would be better to fix Guile, of course <cbaines>I'm not sure if it's an issue with guile, or libgc <cbaines>mbakke, it's a little hard to tell from the stacktrace, but that looks like the exact same issue <vagrantc>sometimes "guix build FOO ... The following derivations will be built: ..." lists the exact same derivations multiple times ... <vagrantc>is this plausibly because of packages with multiple outputs? <civodul>vagrantc: hmm no, that sounds fishy; exactly the same, really? <vagrantc>i noticed it a couple times yesterday, and then today <vagrantc>what was i ever thinking adding openjdk* test suite for diffoscope. <vagrantc>when there are no substitutes ... that one is brutal <plstohelp>I'm going to be back later for guix help, I want to learn some stuff <plstohelp>going to try building a package at some point <pkill9>the bikeshedder in me thinks pulseaudio-service-type should be renamed to pulseaudio-configuration-service-type <sirgazil>I just run "guix upgrade" and it took more than 30 seconds to display any output. Something similar happens with "sudo guix system reconfigure". I haven't tried with other commands yet. <civodul>sirgazil: is that a regression for you, and if so, do you have the commit that didn't have that problem? *rekado is gonna push 40629 (with documentation) soon. <sirgazil>civodul: Guix has been slower to display output, for some weeks for me, but I don't know when exactly the problem started. <sirgazil>Often I run into little bugs that I don't have time to report. <civodul>rekado: i had completely overlooked that one, looks cool! <sirgazil>One thing I remember is that it was around the time Guix was upgraded to use Guile 3 <sirgazil>guix upgrade: error: build of `/gnu/store/lwyn22pmyfxwy9whpvdsdp69n3zhl7qh-python-jedi-0.17.0.drv' failed <sirgazil>command "python" "-m" "pytest" failed with status 1 <rekado>incidentally, this “fixes” issue 15284 <civodul>sirgazil: "guix pull -l 3w" shows the revisions you pulled over the last 3 weeks <civodul>if you could do a quick comparison of "guix upgrade" or so to find out, that'd be great <civodul>run "time guix upgrade -n" for instance *rekado just closed a (wishlist) bug from 2013