<raghavgururajan>sneek, later tell bandali: In the package definition of icedove, source field is mentioned as icecat-source. Does this mean, icedove is now part of gnuzilla project? <rekado_>the reason is that Thunderbird differs from Firefox only in the presence of the “comm” directory and a configure flag. <rekado_>instead of downloading the *huge* Thunderbird release tarball (2.7G unpacked) and patching it to unbundle dependencies exactly how we do it for Icecat, I decided to just reuse the prepared Icecat sources and add the “comm” directory (from the Thunderbird repository) to it. <rekado_>Thunderbird uses the same “platform” as Firefox, so the huge release tarballs are almost the same <lfam>Agreed, nice move to save disk space and bandwidth! <raghavgururajan>rekado_: I am just wondering if any other directory has to be used, with regards to #41138. <rekado_>raghavgururajan: I think I may just have screwed up a patch somewhere <rekado_>I can’t investigate this now, but my guess is that I produced some invalid syntax by carelessly patching files <raghavgururajan>rekado_: No worries! Happens. Just wanted to get my feet wet with icedove. :-) <rekado_>raghavgururajan: I wonder if we can convince Icedove to *show* us the file it tried to parse <rekado_>that would make it easier to correct the error. <sneek>Welcome back bandali, you have 1 message! <sneek>bandali, raghavgururajan says: In the package definition of icedove, source field is mentioned as icecat-source. Does this mean, icedove is now part of gnuzilla project? <bandali>it is not, but we may consider it, if there are no freedom issues <bandali>especially if someone would be willing to volunteer help maintain it <raghavgururajan>bandali: If we can reuse most of the files for icedove, from icecat; then we wouldn't need maintaining it separately right? <bandali>raghavgururajan, we would still need to maintain a script similar to `makeicecat', i think <rekado_>it seems to me that it could piggyback on icecat, so it would be much less difficult than generating icecat from Firefox. <rekado_>raghavgururajan: great! Could you please add this information to the bug report? (And perhaps include how you found out.) <bandali>raghavgururajan, and maybe cc me too pls? <bandali>i want to have it somewhere in my pile of mails so i could come back looking for it at some point <raghavgururajan>bandali: Sure thing! I will also forward the initial mail to you. :-) <bandali>raghavgururajan, thanks, appreciate it! it's my nick @gnu.org <emsyr>I'm trying a pci-e wifi card (ath9k driver) and when I try in ecconman to write wpa2 password to connect to the router I get segmentation fault. Without password I connect to the router without problem. With usb wifi dongle (ath9k driver as well) I can connect to the router without problem, with password either enabled or disabled. Any idea?. <raghavgururajan>I probably came across this error, but forgot what it means and how to overcome it. <raghavgururajan>./autogen.sh: ./configure: /bin/sh: bad interpreter: No such file or directory ***jonsger1 is now known as jonsger
<tho1efx>Should $GUIX_PROFILE be set to `"$HOME/.guix-profile"` or `”$XDG_CONFIG_HOME/guix/current/”` <tho1efx>Seems every doc I look at says different than the last. Split right down the middle. <mwette>tho1efx: I struggled w/ that a lot. Everything was breaking until I set $GUIX_PROFILE to $HOME/.guix-profile and made sure guix was from $HOME/.config/guix/current/bin/guix. So PATH has $HOME/.config/guix/current/bin before $HOME/.guix-profile/bin. <mwette>I'm on foreign distro Fedora-31. <mwette>GUIX_PROFILE=$HOME/.guix-profile ; source $GUIX_PROFILE/etc/profile ; PATH=$HOME/.config/guix/current/bin:$PATH <tho1efx>The same thing again but I got a little more from it :) <tho1efx>Maybe it is that I don't understand setting path in bash. Is that what I should look up? <mwette>that sequence should go in your .bashrc file <tho1efx>Yep, I understood the first two and the right values are in there. But the last one I don't, and I don't like to put things I don't understand into configs <singpolyma>Hello all! I just booted a Guix VM from the qcow image provided in the downloads, and I want to SSH into it. It seems that the way to do that is to edit my system config.scm and run reconfigure to expose an ssh service. Is there a standard place this scm file is located? One place I saw said /etc/config.scm but I don't seem to have that file in the VM <ecbrown>singpolyma: 1) set root passwd 2) herd start ssh <ecbrown>i.e. the ssh daemon is started with the herd progam <ecbrown>add the appropriate (openssh-service-type ...) and then guix system reconfigure /etc/config.scm <ecbrown>i think you can copy the one you used to create the VM <singpolyma>oh, wait, I've found the guide I should have been reading <ecbrown>singpolyma: i do not know where the config.scm file is that is used to create the vm one the website. perhaps someone else does. *but* the point is to start rolling your own :-) <singpolyma>Right, but if I just create an empty one with the ssh service in it I assume everything already on here will go away? <ecbrown>there are some examples such as bare-bones <ecbrown>also in ~/src/guix/gnu/build/vm.scm is the vm spec <ecbrown>(~/src/guix is where i checkout git repo) <ecbrown>wow i'm messing up tonight. that's not it i don't think... ***jonsger1 is now known as jonsger
<singpolyma>I mean, I guess I don't need the GUI that came with the VM and everything, but it seems weird to reset the system to not have things it came with just to install a service <ecbrown>i think the point of the vm is to get you up and going quickly, e.g. guix package installing <singpolyma>right now I'm just trying to run guix pull, which seems like it's going to take a very long time, heh <ecbrown>yeah, i think a big update branch was just merged in, too <singpolyma>It's consuming all the CPU in the VM very easily, so yeah, I have time <singpolyma>that really should live in the VM somewhere sensible :P <singpolyma>the file itself seems to think it should live there <tho1efx>mwette: The guix pull tool disagrees with this too xD <singpolyma>I know this is such a bored user thing to want, but guix pull gives me basically no indication that anything is happening. And the default top in this VM sorts by PID? wut. Anyway. I'm sure by the CPU usage that *something* is happening <tho1efx>I find it's ok about such things. Are you sure the VM is not oom? <singpolyma>free -m says free 29 available 600 so I think so? <singpolyma>top on the other hand seems to think I'm using 39 GB of 1 GB available RAM, so maybe? <singpolyma>I can give it more than 1GB, yeesh, though I don't have anywhere close to 39 on here <mwette>tho1efx: I get that too. I have been ignoring it. I may certainly be wrong. <singpolyma>I'll reboot it with 4GB ram and see if that helps :) <tho1efx><singpolyma "I'll reboot it with 4GB ram and "> My 4gig system handles it fine as long as I don't have browsers or other memory intensive tasks <tho1efx>I also have only 4 build users set up though. <srandom>neovim Do I need additional configuration for the plugin installed using guix? I packaged and installed the plugin to share/nvim/site but it doesn't seem to take effect <tho1efx><mwette "tho1efx: I get that too. I have"> Those hints would be a really cool feature if the were right. <srandom>sorry translation error, i mean neovim need additional configuration to use the plugin in guix? <tho1efx>Does neovim in guix need post-install configuration done to it to use plugins? <tho1efx>If that's the question my follow up is: How are you installing the plugins? <srandom>I wrote vim.scm which defined my plug-in, and then installed <tho1efx>And nvim is not loading the plugin you packaged. <tho1efx>Ok, now I have to defer to people using nvim on guix. <singpolyma>With 4GB ram my graphs are all nicely showing definitely not OOM. Just burning CPU. Ah, well, I'm sure it'll finish if I leave it run <srandom>From strace, nvim did not scan the files under ${HOME}/.guix-profile/share/nvim/site <tsmish[m]>srandom: not really a neovim user, but nvim -V showed me .guix-profile/share/nvim/site. Do you have anything under .config/nviim, .local/share/nvim that can block it? <tsmish[m]>Also, did you try neovim-syntastic from repository in order to exclude bugs arising from package itself? <tho1efx>mwette: I'm learning about path here and I'm wondering something. There's nothing in my bashrc that sets $PATH but when I echo it I see $HOME/.guix-profile//bin and the same //sbin at the front of path. <srandom>I do n’t know how to copy the output of nvim -V, it seems to be curses, there is no way to redirect <srandom>I have tried the neovim-syntastic plugin in the official Guix repository, and it does not work <singpolyma>Thanks for the help, all. I'm going to leave this guix pull running overnight and see if it finishes :) <tho1efx>It took a while for me but maybe not this long. Good luck and gn. <tsmish[m]>srandom: nvim -V10/tmp/file. I'll also try testing with new user: sudo useradd test; sudo -iu test; guix install neovim neovim-syntastic; nvim. :Syntastic<Tab> should give something. <tsmish[m]>srandom: Well, seems I didn't tell it, but it works for me (well "works", it finds it). From my side either something in user configuration breaks it or our guix channels differ in that respect. <srandom>I used nixos solution to make it work, this may be a problem with my system (Guix on nixos) <srandom>Maybe guix should also set XDG_DATA_DIR for neovim <tsmish[m]>Sorry, forgot that guix worked on other systems. <raghavgururajan>I get "./autogen.sh: ./configure: /bin/sh: bad interpreter: No such file or directory", during build. Any ideas? <pkill9>raghavgururajan: it sounds like the configure script has a /bin/sh shebang <pkill9>which doesn't exist in the build container <pkill9>normally guix patches them to point to the store path for bash, but it sounds like autogen generates the configure script and hardcodes /bin/sh <raghavgururajan>patch-shebang: ./autogen.sh: changing `/bin/sh' to `/gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7/bin/sh' <pkill9>what is the shebang of the configure script? <pkill9>i mean the generated configure script <pkill9>that's like the template for the configure script that gets generated <tho1efx><srandom "Maybe guix should also set XDG_D"> If you have to set the environment variable it's not following the spec. <pkill9>raghavgururajan: add the -K flag to guix build, then look in /tmp/guix-build-... <jeff_>Hi, anyone encounter/resolve this error? guix pull: error: glibc-bootstrap-system-2.2.5.patch: patch not found <apteryx>raghavgururajan: is this package using gnome-common? <apteryx>ah, nevermind, I see this is now taken care of directly in gnu-build-system; (setenv "NOCONFIGURE" "true"). <tho1efx>Should I delete /usr/local/bin/guix now that I've got guix running and path set correctly? <apteryx>no, it's now being made automatically in the bootstrap phase <raghavgururajan>apteryx: Ah, I sa the temp dir after build failure. There was configure file with /bin/sh shebang. How do I correct this? <raghavgururajan>Its already there in master, but broken. I tried building from git-fetch instead of url-fetch, and got this error. <raghavgururajan>"./autogen.sh: ./configure: /bin/sh: bad interpreter: No such file or directory" <apteryx>but this should be done automatically by the gnu-build-system bootstrap phase as I said earlier <raghavgururajan>apteryx: I was using glib-or-gtk-build-system, but also tried gnu-build-system. It did not work automatically. <apteryx>does it when you manually add a phase? <apteryx>another thing you could try is to remove autogen.sh and run 'autoreconf -vif' manually. <tho1efx>I thought I saw fish and bash completions for fish somewhere in the default install. anyone know where they might be? <tho1efx>Actually I managed to find them but I can't tell which I should go for? Can diffoscope diff ~30 files? <apteryx>nope. that'd be wrap-program*, which we don't have <apteryx>so you have to use for-each, there are assuredly couple examples already <srandom>How should I fix it? I built the rust-base64 of the official repository <benny>well it also has zfs encryption at rest, which you may not want <benny>oh damn completely wrong channel sorry everyone. lonzo1, ignore the above <srandom>Is write operation not allowed in copy-build-system? <srandom>I use copy-build-system to build my neovim plugin, because it needs to build a binary file written by rust, I added the build command, but it display Permission denined. <tho1efx><lonzo1 "how does ZFS work with Guix?"> The distro? <lonzo1>then why is ZFS in the package repos? <bricewge>lonzo1: I think you can use it as a loadable module <lonzo1>zfs on root? how would one do that? <ik1>Can somebody tell me what`s the problem with tor browser binary? I installed 64 bit GuixSD and afterwards downloaded 64 bit Tor browser alpha. And it shows me 32 vs 64 bit error. Is it aknow bug? Same with stable tor browser. <sammich>I'm working on an importer for go modules, and just before i continue, one doesnt exist already, right? <cbaines>ik1, generally there will be issues in running arbitrary binaries on Guix. Same as with other operating systems, just more extreme <leoprikler>you should be able to resolve (some of) them using patchelf <cbaines>sammich, I think there was one started. I was trying to track this down recently as well, I found a couple of patch sets on guix-devel <bricewge>lonzo1: We don't support it on root ATM. <cbaines>at least ZFS for root isn't a documented configuration, unlike ext4 or btrfs <bricewge>I'll probably have to add the zfs module to the initrd too <sammich>cbaines: ah i found the threads, thanks! Also, darn i had a decent bit done, shoullda looked it up first <cbaines>sammich, what you've done is probably useful, the situation might have changed since that previous work <cbaines>sammich, I'm glad someone is working on a Go importer though :) <janneke>sneek: later tell civodul, loopback works! fresh rebased wip-hurd-vm on my gitlab, tty maybe tonight <bricewge>Is there a way for the CI to build non substitutable package? <bricewge>Looks like the zfs package is broken but since it “#:substitutable? #f” I can't find it on ci.guix.gnu.org <cbaines>bricewge, I'm not sure it would necessarily make sense to build non-substitutable things on ci.guix.gnu.org <cbaines>I can't see Cuirass builds either, so I guess it's excluded <bricewge>cbaines: Bu then how do we catch broken packages which are non-substitutable? <cbaines>bricewge, I think it would be better to build it, but not provide substitutes. Unfortunately that's not very feasible with the way ci.guix.gnu.org is setup at the moment. <bricewge>Okay, should I open a whishlist item on the bug tracker then? <cbaines>I've been thinking about building things for quality assurance, and that's something I'm hoping the Guix Build Coordinator thing I'm working on will help with <xelxebar>Aaaargh. Trying to package something with a texlive-union input, I dumped *hours* into trying to debug latex errors... <raghavgururajan>sneek, later ask mbakke: Did something changed regarding fonts, during core-updates merge? After guix pull and upgrade, some of my app's started to show TOFUs. I tried fc-cache -rv and didn't work. But when I installed font-dejavu, those apps started to use them. I wonder why this happens, as those apps were working fine with just font-google-noto installed. Any ideas? <mbakke>raghavgururajan: no idea, maybe we should add font-dejavu to %base-packages to ease the transition <sneek>Welcome back mbakke, you have 1 message! <sneek>mbakke, raghavgururajan says: Did something changed regarding fonts, during core-updates merge? After guix pull and upgrade, some of my app's started to show TOFUs. I tried fc-cache -rv and didn't work. But when I installed font-dejavu, those apps started to use them. I wonder why this happens, as those apps were working fine with just font-google-noto installed. Any ideas? <jonsger>cbaines: i can not find 40777 at your patches git repo <raghavgururajan>mbakke: I see. Btw, do you know why most applications in gnu/linux uses font-dejavu as default? I was expecting font-gnu-freefont to be common in gnu/linux systems. <mbakke>raghavgururajan: I have no idea :-) perhaps #gtk or #dejavu knows more <rekado>xelxebar: the only problem with that patch is that it couldn’t be added to core-updates in time <rekado>I asked Jelle to push it to wip-texlive but that didn’t happen. <xelxebar>rekado: Thanks for answering. So the problem is technically fixed but just has yet to be merged? <mbakke>rekado: can the fix be grafted? won't help for packages using texlive-union though <grumbel>Trying to use #include <cmath> on gcc-toolchain > 7 gives me "error: 'log2' is not a member of 'std'; did you mean 'log'?", seems like _GLIBCXX_USE_C99_MATH_TR1 isn't getting defined and a bunch of functions end up missing <xelxebar>mbakke: Wait, texlive-union doesn't pull in grafts?? <mroh>grumbel: this works with gcc-toolchain <= 7 ? <mbakke>xelxebar: grafts are applied "post-build", that is if you try to use texlive-amsfonts in a package definition or gexp (to build some TeX document) you would be using the non-grafted package <mbakke>it would probably still be worth grafting it for those using texlive-amsfonts in a profile, and to have a 'texlive-amsfonts/fixed' variable that can be used in package definitions <grumbel>Using this for testing: echo -e "#include <cmath>\nint main() { std::log2(1.0); }" | g++ -x c++ -std=c++11 - <wxie>command "git verify-commit `git log --format=%H build-aux/git-authenticate.scm" outputs error <wxie>error: Unbekannte Option: `format=%H' <xelxebar>mbakke: Hrm. Not sure I follow. The graft wouldn't be picked up because texlive-union effectively generates a new package definition on the fly, not acting like the moral equivalent of a mini-manifest? <grumbel>wxie: What is the output of just: git log --format=%H build-aux/git-authenticate.scm ? <wxie>error: Unbekannte Option: `format=%H' <wxie>grumbel: option format=%H is not known <wxie>bash: git: command not found <xelxebar>Now I'm confused though. guix environment --pure texlive-amsfonts doesn't actually put texlive-amsfonts in the environment... <grumbel>xelxebar: You need to add `--ad-hoc` <mbakke>xelxebar: put another way, grafts are only applied to outputs. If you want to use texlive-amsfonts to build e.g. a PDF document in a Guix package, the graft would be applied after the PDF has been built and would not actually change the PDF. <grumbel>xelxebar: guix environment doesn't put the packages in the environment, but creates the environment you would need to build texlive-amsfonts <wxie>grumbel: git log --format=%H outputs numbers <wxie>error: cannot run gpg: Datei oder Verzeichnis nicht gefunden <wxie>grumbel: what do I miss here? <grumbel>wxie: What are you even trying to do? Sounds like you are missing packages or executing stuff in the wrong directory <grumbel>wxie: does "guix package -i gnupg" help <grumbel>that doc seems to assume that some common packages are already installed <wxie>grumbel: yes. gnupg worked, but missing public key - gpg: Signatur kann nicht geprüft werden: Kein öffentlicher Schlüssel <lonzo1>hey sorry for maybe being a bit annoying but can someone link me the F2FS patch code? <lonzo1>I might take on the challange of writing a ZFS patch <reepca>wxie: note that later on it says "(you may need to fetch this key from a key server, if you have not done it yet)" <reepca>It does seem a bit counter-intuitive to put the requirement for running a command after the output of the command, though <wxie>reepca: how should I fetch the public key? <reepca>great question. I actually happened to already have it when I ran that step, and the only time I recall fetching any keys was during one of the installation steps, so that was probably it <wxie>reepca: Thanks. Now the output is ok: gpg: Korrekte Signatur von "Ludovic Courtès <ludo@gnu.org>" [unbekannt] <wtx>icecat running on 1686 <wtx>i just download the binaries from gnu mirror <wtx>i dont know why guix compiled all the source and break in rust instead just get the compiled version <wtx>maybe because the kernel that i am using is 1686-pae ? <Talas>Hi all, I'm trying out guix on top of debian. I've run into an issue with compiling a game, it seems like the include files can't be found. Did I miss something in the setup? https://pastebin.com/kyjigcXY <srandom>freetype2/freetype/config/ftheader.h <tsmish[m]>I think it misses necessary include paths, because it doesn't use autotools and pkg-config in particular. <tsmish[m]>And adding freetype2/ doesn't help, because header files itself have includes in them, that assume that freetype is available at freetype/... Had same problems while building one particular game. <xelxebar>mbakke: Hrm. Does that statement about grafts also apply to native-inputs? Ostensibly, it's the outputs of these packages that are supplied to the building machine, so I'd naively expect their post-grafted versions to be available there. <grumbel>Talas: the Makefile hardcodes the freetype2 include path, try something like: <grumbel>-CXXFLAGS += -I/usr/include/freetype2 -isystem./source/glfw/include <grumbel>+CXXFLAGS += $(pkg-config --cflags freetype2) -isystem./source/glfw/include <grumbel>Talas: make that double $$: +CXXFLAGS += $$(pkg-config --cflags freetype2) -isystem./source/glfw/include <grumbel>Talas: With that change and a few more packages it compiles: guix environment --pure --ad-hoc gcc-toolchain git cmake libpng zlib glew glu freetype libxi libvorbis libogg openal bzip2 libxrandr curl make lesspipe coreutils less which pkg-config bash <grumbel>CC=gcc CXX=g++ LDFLAGS=-std=c++11 make -f source/linux/Makefile compile <srandom>When will GuixSD support xinit to start X sessions? <mbakke>xelxebar: build inputs are never grafted, it happens on the guix "front-end", i.e. when using guix build and guix package etc; you can always access the ungrafted variants with --no-grafts <srandom>gdm, sddm, slim are inflexible and too big. <bricewge>srandom: I think it already does, see xinit in (guix services xorg) <Talas>Thanks grumbel and others. It does indeed build now. Thanks a lot! <bricewge>srandom: Some docs should be written tho <srandom>Sorry, I didn't see the configuration about xinit in the latest source code, I saw only a global xinitrc configuration <srandom>I just need an xinit that can be used in vt <bricewge>srandom: My band it's xinitrc *not* xinit <bricewge>So you mean a xinit service that start at startup on a vt like the gdm and the others? <bricewge>You want xorg-start-command then, it returns a startx script <bdju>build failure for the "toxic" package <jojoz[m]>Anyone using Guix environment for Haskell development? Do you manually build via `runhaskell`, or is there some better way? <jojoz[m]>On Arch I'd use `stack`, but that's not packaged here, and feels like it would/should be redundant on Guix. <mbakke>bdju: fixed in 93600aae801dbd58192e5aa65b36f57255191d0d :-) <mbakke>alextee: core-updates has been merged to master now <bdju>argh, keep running out of space trying to update. I fear the GC is touching the stuff I just built and setting me further back. been trying to update for a couple days now <alextee[m]>mbakke: w00t! you mean we have meson 0.53 AND gcc 10? \o/ <mbakke>bricewge: let's add it on staging instead, it does not add much to the rebuild count of 'mesa' anyway <mbakke>bricewge: I can push it on your behalf when I get around to do my staging updates <bricewge>I have commit access now, so as you want. <reepca>it'd be nice if there were a way to delete generations but keep the provenance information around somewhere. It's an extremely low cost to pay (~250 bytes for me) to be able to reproduce a system configuration from any point in time, and would make it much more comfortable to only keep one or two old generations built at a time. <mbakke>bricewge: I changed Cuirass to not build all of staging, so feel free to push it there now :-) *mbakke goes offline for the weekend <kmicu>[Not serious] But that’s steering me into proprietary ecosystem tho! <alextee[m]>kmicu: well, it's GPL, although we have jack transport too ***gary is now known as Guest58781
<reepca>rndd: do you have guile installed (and in the same profile as pkg-config)? <reepca>note that depending on how old your guix is guile-3.0 may be named guile-next. <kmicu>alextee[m]: the (non)‑issue is with FSDG which is much stricter than libre software. Personally I don’t see the issue but I recognize why some FSDG purist could have an issue with Ableton™‑link. <alextee[m]>i thought that was completely proprietary, but guix has an asio package now? <kmicu>It’s a gray area and drawing line on the sand. For me even Wine doesn’t comply with FSDG because in practice is used in overwhelming majority for proprietary apps. <alextee[m]>Being a proprietary protocol, it does not have any universal compatibility with Windows-based DAW and other recording software. For example, the user manual of the Audacity audio editor states: "Licensing restrictions prevent us including ASIO support in released versions of Audacity, but Audacity can be compiled with ASIO support for private, non-distributable use. <alextee[m]>i thought this was the reason i couldn't ship zrythm with ASIO support on windows too. idk, i didnt look into this too much <pkill9>I think asio on guix is a different library than ASIO on windows <alextee[m]>other audio devs also told me you cant distribute anything compiled with asio support <pkill9>asio on guix is a networking library <pkill9>ASIO on windows is a jack equivalent <rndd>reepca: this is my (specifications->manifest '("gcc-toolchain" "pkg-config" "guile" "make" "autoconf" "automake")) <alextee[m]>ableton-link has "asio" as a propagated input o.o this is confusing <kmicu>Naming things, one of the biggest problems of computing, amirite 😺 <alextee[m]>so that's the "other asio" for networking i guess <alextee[m]>kmicu: i guess this is why gnome starts doing things like org.myorg.MyApp *kmicu hides seeing Java like import string. <reepca>rndd: what does 'guix package -A guile-next' show? <rndd>reepca: guile-next 3.0.2 out,debug gnu/packages/guile.scm:292:2 <wxie>Why GUIX_PROFILE="/home/wxie/.guix-profile" outputs "command not found"? <rndd>reepca: thank you with guile-next it works <wxie>The command GUIX_PROFILE="/home/wxie/.guix-profile" has different behavior in terminal bash and emacs eshell. <reepca>alternatively you could run "guix pull" and get the latest version, where guile-next has been renamed to "guile", and thus the specification will resolve to guile-3.0. <bdju>will `sudo guix gc` do something different than `guix gc`? <bdju>(such as have access to other things that the user's gc can't clean up) <g_bor[m]>cbaines: I believe there was a patch to not try to execute bootstrap if it's a directory. Where is that as of now? <reepca>bdju: with no arguments, no. `sudo guix gc -d 5d`, however, will delete generations owned by *all* users, not just the current user. <rndd>is it possible to build android apk on guixsd? does anybody tried? <pinoaffe>iirc some work is being done on getting the java build system support there <wxie>what does 'make check' XFAIL mean? I do not see the failed test. <buffet>alright, so core-something has been merged back, and i updated wlroots, which broke sway, so i updated that as well. should i submit those as one commit ("every commit builds") or two (splitting up the changes)? <ngz>buffet: I think two patches are fine <reepca>wxie: I *think* XFAIL means "expected failure" <jonsger>hm. MATE doesnt have sound on current master. Says: "Waiting for sound system to respond". <thomassgn>so the last few upgrades to icecat has disbled some of my plugins and enabled some from the browser. Is there anything I can do so I don't have to fix the plugins each upgrade? <jonsger>thomassgn: I wondered about this issue as well <thomassgn>I see now that I can't just select the plugins and enable them either, I don't know how to enable them. This is _very_ frustrating. Will I have to reinstall all my plugins each upgrade? <sneek>civodul, you have 2 messages! <sneek>civodul, jackhill says: Did you see my reply about emacs-next? https://issues.guix.gnu.org/issue/41016#4 (I replied to a closed issue, so I don't want it get lost). tl;dr with your change to the patch the addition of the (ice-9 match) import is not longer needed. <sneek>civodul, janneke says: loopback works! fresh rebased wip-hurd-vm on my gitlab, tty maybe tonight <cbaines>g_bor[m], I'm not sure I've looked at fixing that <cbaines>(not trying to run bootstrap when it's a directory that is) <cbaines>Sounds like a good thing to do though <thomassgn>civodul: Will do. I see there's a FF issue that may be related, will link it in my bug report. <thomassgn>oh ho, I think I just understood what it is. <thomassgn>I have recently been needing to manually run ntpdate to set time and date for my system after boot (I found I was missing the ntp service - re added :). It seems icecat once in a while checks time. The FF issue I mentioned above is related to certificates, Guessing that the error in time between plugin certificates and system is what makes them disabled. <jonsger>rekado: can we built texlive-bin with `--enable-shared` or `-fPIC`. This is required when updating atril to 1.24 as it links against libsynctex from texlive-bin? <thomassgn>jonsger: does this fit your problem as well? or did you reinstall your plugins? <jonsger>thomassgn: I guess I reinstalled them. But I did stuff with profiles and migration. So maybe something went wrong there. It would be a good idea to open a bug <thomassgn>jonsger: maybe, but my plugins got reenabled on its own and I'm now back to what I expected. So it seems time was the problem in my case. <jonsger>so maybe just see if it occurs again :) <jonsger>the duration field on ci.guix.gnu.org seems to have some integer overflow. 50 years build time is not really beliveable :P <lfam>Are you sure? Is it for LibreOffice? ;) <lfam>I wonder if that field is actually representing when the build completed, in seconds since the Unix epoch? <reepca>I could believe 50 years for texlive-texmf to download... especially when the download freezes every 10 minutes. I really need to properly fix that cat5 cable one of these days... <lfam>`date --date='@1586142575'` gives "Sun 05 Apr 2020 11:09:35 PM EDT" <lfam>I recommend adding a "gcroot" for it so it doesn't get garbage collected <lfam>Something like `ln -s /gnu/store/5rnvmy02yazy8iwaa91kijbbqp8qmflz-texlive-20170524-texmf.tar.xz /var/guix/gcroots/20170524-texmf.tar.xz` <lfam>Can you check if there's already a bug report about this? <jonsger>lfam: issues search is broken, so you get hundreds of hits <reepca>AFAIK it's not even really a gc issue, just upgrades. <jonsger>lfam: I'm building texlive-bin with `--enable-shared` <lfam>The search works well there <lfam>reepca: I haven't downloaded a new texmf tarball in years, because I have protected it against garbage collection <lfam>Although I see there is a new one now <lfam>Or maybe I don't need to download it anymore? Not sure <bdju>failure after failure from lack of space... I keep doing a gc, but apparently it's never enough. this is driving me nuts <reepca>tests/foreign.scm of guile-fibers seems to be hanging <lfam>bdju: What are you trying to build? And how much space do you have? <reepca>I'm strace'ing all the threads of it, 4/6 are stuck in a futex, 1/6 is stuck in a read, 1/6 is stuck in a epoll_wait. <bdju>lfam: just general updates for the first time in a while, / partition is ~99GB but is very near full and I keep GCing a bit but the free space is never quite enough. The latest thing it's failing on is texlive. <bdju>I was telling it to free 5, 10, or 20GB mainly, but this time I'm gonna gc a lot more because the time between tries seems to be very long for whatever reason <bdju>I'm still paranoid I'm GCing some of what I've just built <lfam>bdju: We just did a big update, of the entire system from the core packages on up. So you will need some space. How much depends on how many packages you need <lfam>You will end up doing that bdju <lfam>Do you mean to be building stuff? Can you use substitutes? <bdju>substitutes are used where they can, I'm not building everything on purpose <bdju>it's a mix of downloading and building, I'm not doing anything fancy <lfam>I feel like 10 GB should be quite enough but I suppose it depends <lfam>Do you notice that you are downloading a huge source tarball for texlive-texmf? <lfam>And, do you know about "gcroots"? <bdju>I'm not 100% sure. I do see texlive-texmf but not necessarily a tar <bdju>I don't know about gcroots <lfam>Gcroots are things in /gnu/store (store items) that are registered as not allowed to be garbage collected. So, packages in your profile, things like that <lfam>You can create them by hand by symlinking them into /var/guix/gcroots <lfam>So if you know you built or downloaded something big and don't want to do it again, you can make a symlink to it in that folder, and then run `guix gc`, and not worry that it will be deleted <lfam>`ln -s /gnu/store/...-foo-1.0 /var/guix/gcroots/foo-1.0` <jojoz[m]>Hmm, I just broke my `guix` binary by Ctrl-C:ing out of a `guix pull` that had frozen. Just segfaults now <lfam>jojoz[m]: What OS are you on? <lfam>You should be able to use the Guix found at '/run/current-system/profile/bin/guix' as a rescue tool <lfam>Before you do, can you report the bug? <lfam>Including anything left from the run of `guix pull` that was stopped? <jojoz[m]>I tried rebooting, so I don't suppose there's any output left to copy <lfam>Okay, can you still report the bug, with whatever details you can remember? <lfam>If possible, you could use that other system Guix to make strace available, strace the Guix that segfaults, and include that info <jojoz[m]>Alright. Don't quite remember what it said though. Something like "Preparing 1 package for profile" maybe? <lfam>It's just that I wouldn't expect it to be possible to break Guix by interrupting this, so it's a bug we'd like to investigate <jojoz[m]>lfam: I had another issue just before, but it may be unrelated. Various Haskell packages failed to build, including ghc-llvm-hs and my own package. After compiling a few of the modules, it just suddenly failed with something very close to "command runhaskell build failed with status code 11". <tho1efx><wxie "The command GUIX_PROFILE="/home/"> Eshell is not bash not even POSIX compliant I think. <jojoz[m]>lfam: Should I just file a bug about what I can remember + the output of `strace guix`? <lfam>jojoz[m]: Please use `strace -f guix ... 2>&1 | tee ~/tmp/log`, and then include the log <lfam>The Haskell packages failing to build is likely a separate issue that should get a separate report <jojoz[m]>Do you mean I should substitute the ... for something? Just running `guix` without any subcommand already gives segfault <lfam>Then you can leave out any extra stuff where I wrote ... <jojoz[m]>Re. Haskell packages, ok, will try to reproduce <jojoz[m]>I'm afraid I will have to start dual booting Arch for a while yet. I don't know if I have an uncommon usage pattern or something, but Guix just doesn't seem to want to play nice with me :( <ATuin>hello! what's the current status of rust packages in guix? I can see that rust version is 1.39, is it possible to build a newer version right now? thanks <anadon>Where is the libressl-dev/libssl-dev package? A search isn't turning up anything I'd recognize as the development package for ssl. <ATuin>anadon: you can try yourself: "guix environment --ad-hoc libressl;ls -la $GUIX_ENVIRONMENT/lib" <ATuin>not sure if that's what you are asking for. <anadon>What I am running into is that just more things need to be packaged. <bdju>what the... I did `sudo guix gc -d 5d` this time and still failed on texlive for space reasons... <bdju>I'll maybe have to gc everything, do everything over, and then hopefully there'll be enough space, and I'll find out if it worked in several hours <anadon>Put on the mailing list too, but if anyone knows of a organized packaging backlog I'd be appreciative. I need to add a number of things, and it would also be nice to have something kanban like to pull work from. <bdju>anadon: Guix Wishlist on libreplanet wiki <bdju>I've added to it whenever I run into something new that's not packaged <anadon>bdju: wish me luck in not getting flagged for spam! <ATuin>uhh my emacs font are completely messed up after upgrading <ATuin>any idea how to fix that, I always get problems with the fonts <cbaines>ATuin, it could be some fonts that were available before have disapeared <cbaines>what fonts do you have installed in your profile? <ATuin>hack, inconsolata and gnu-freefont <ATuin>the buffers have proper fonts, it's the menus that are messed up <cbaines>Hmm, I wonder what font Emacs is trying to use for the menus... <efraim>cbaines: you asked earlier what I know about zfs. I have no idea how to use it, I just packaged it because it was there <cbaines>ATuin, I have font-dejavu installed, maybe that would help. Also, are you using Gnome? <cbaines>efraim, ah, cool. I thought you might be using it :) <jonsger>which service/package is required for signing git commits with pgp? <ATuin>cbaines: changing it it Xresources does not fix it :D <jonsger>error: gpg failed to sign the data. I have git and gnupg in config.scm, but it doesnt even ask for my passprashe <ATuin>jonsger: gpg-agent should take care of that part <ATuin>is it running? normally it's started by demand by gpg when needed <ATuin>is it asking you for the passphrase when signing or encrypting from the cli? <jonsger>ATuin: I found the solution. I have to install pinentry package <ATuin>that's the gui providing the gui thing to get the passphrase, i forgot aboutit <ATuin>cbaines: seems that all the GTK stuff has the fonts wrong, now when trying pinentry it has the same problem <cbaines>ATuin, I've used the Gnome Tweaks tool to fix font issues in the past, any chance you have that? <ATuin>i can install it i guess, I don't have it installed right now <ATuin>This problem with the fonts happens very often, I guess it's because I'm missing some GTK stuff <cbaines>ATuin, well, ideally it would be harder to get in to a bad state with the fonts... <ATuin>mmm I can not run the gnome-tweaks <ATuin>when this happen before I could fix it with fc-cache -f but now some programs looks fine (icecat for example) <arpunk>ATuin: can confirm using stumpwm aswell <ATuin>looks like a GTK3 problem, maybe some font missing in the system profile <anadon>I want to add a field in packages for program aliases. It looks like adding the field is easy enough, but I don't see a way to enforce that it is a list of pairs of strings giving the alias name, and what distro uses that alias. I want this because I keep seeing package references to names in other distros which aren't the same in guix and I <anadon>think this lookup ought to be easier.. <cbaines>anadon, is this the same subject as "Should guix track package aliases?" on guix-devel? <ATuin>arpunk: did you find any solution? <ATuin>for me it looks like it's missing some GTK stuff (theme, font) <anadon>I've been unsure there I should best spitball thoughts. <arpunk>ATuin: just tried on a fresh installation using awesome and have the same issue. I didn't notice before because I barely leave Emacs <cbaines>anadon, so aliases isn't something I've explicitly been thinking about in the context of the Guix Data Service, but I would like to make it possible to link up against other datasets. Things like directory.fsf.org and repology.org <cbaines>anadon, have you used repology.org before? <ATuin>arpunk: same here, I normally don't see the menus so I don't really know when this started :D <anadon>I recall seeing somewhere at some point that some group of devs didn't like the maintainer. I'm not sure if that was here or not. <cbaines>anadon, so it's not particularly related to aliases, but it does try to work out what packages map to what across different package managers <anadon> That would be useful. Especially if it could be hooked into searches and installs. <ATuin>arpunk: trying now "environment --ad-hoc gnome" to see what magic does it have <anadon>cbaines: looks like it doesn't even handle a simple search for "zlib1g" <lfam>There can be a lot of difference between what packages "are" between distros <lfam>They may not be directly comparable <anadon>Actually, a ton of the problems listed in repology.org for guix have already been fixed. What's with that? <cbaines>anadon, I'm not entirely sure why, but the data is out of date <rekado>jonsger: issues search is broken? <jonsger>rekado: not broken, but the results are very general <rekado>still need to figure out how to actually use xapian <rekado>I just whipped this up real quick <rekado>search for the logs works pretty well, though <anadon>cbaines: So it looks like the HTTP server needs to provide a current datetime in the HTTP header "last-modified". <anadon>That might be able to be fixed (poorly) by just including the datetime of the request. <cbaines>anadon, yeah, I think the Etag and Last-Modified headers for guix.gnu.org/packages.json currently reflect the file being last modified back in 1970 <cbaines>anadon, including the datetime of the request where? <anadon>cbaines: With what server dev work I've done, usually there is some way for the server process to modify headers. If the underlying files all have datetimes scrubbed, than have the server process replace the header with the system datetime rather than the file last modifies date. <cbaines>anadon, at the moment, it's just nginx serving the files from /gnu/store/... <anadon>cbaines: `add_header Last-Modified "";` -- add that to the config <cbaines>anadon, I think the requirement is to have Last-Modified be at least roughly correct. <anadon>My understanding is that the last-modified header is used to aid in caching, and so incorrect behavior is anytime when a request for updates indicate to not update a cache when in fact there have been changes and the cache is invalid. In the event there is no change but the server has indicated that there have been changes then there is a <anadon>performance penalty, but not incorrect behavior. <anadon>So always saying there is a new version works correctly, just a little heavier server load. <anadon>Which, if repology.org uses daily pulls anyways, means that it will have the same load and then everything just works correctly.