<CharlieBrown>killing process 3262guix package: error: build failed: some substitutes for the outputs of derivation `/gnu/store/x9bi3ap4nrll69qzcqflm94v56d0fb3l-nss-certs-3.33.drv' failed (usually happens due to networking issues); try `--fallback' to build derivation from source <CharlieBrown>`youtube-dl`gives a bunch of Python errors and complaints about locale. <lfam>CharlieBrown: Usually there will be some other useful information printed when substitution fails like that. Can you put it on a paste site? <CharlieBrown>This happened while I was trying to `guix pull` and `guix package -u`. <lfam>CharlieBrown: I was talking about the NSS issue <lfam>youtube-dl is working for me, so I'm not sure what's up there <CharlieBrown>All environment variables were lost, because I did `export FOO=bar` in the terminal like everything else, because I followed the installation guide very literally. <CharlieBrown>Oh, I forgot! I just installed `ncsd` and need to check it out. I hadn't configured that yet, because I wasn't sure if I should install it with APT or Guix. <CharlieBrown>I still don't know where to set yenvvironmyenvariablyenv Triyenv <CharlieBrown>Sorry. My keyboard was acting up. When Gedit or Firefox are running slow, some keys on my keyboard print random letters when I'm trying to type. Even Backspace and Enter. <CharlieBrown>`guix package -u` still gives a substitution error for `nss-certs` and says `killing process 3581`. <lfam>CharlieBrown: That's weird, I'm not sure what happened. I would re-run the command with --fallback <lfam>I was able to download that substitute <CharlieBrown>lfam: `--fallback` seemed to work, but I still get errors about locale &c. <CharlieBrown>I put `source $HOME/.guix-profile/etc/profile` in `~/.bashrc` so I can run Emacs from the terminal, although I still can't do it from GNOME, and the GTK widgets look broken. <CharlieBrown>The other Python apps, like `youtube-dl`, do run, though. <lfam>By the way, I recommend exporting these things from ~/.bash_profile or ~/.profile, but not ~/.bashrc. The former is used when you log in, but the latter is used every time you open a new Bash shell, which is usually undesirable <CharlieBrown>lfam: I thought sourcing `$HOME/.guix-profile/etc/profile` would set all the env. vars, because Guix put them all there. <CharlieBrown>export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale` to .profile. <xelxebar>Testing out IRC client. Would someone mind mentioning me? <buenouanq>CharlieBrown: you say `buen' twice while doing a somersault ***drp_ is now known as drp
<taohansen>just started SICP and am really enjoying it paired with geiser. hope i can someday attain the illustrious heights of Guile knowledge as the rest of you. :-) <taohansen>fingers crossed my questions become less the idiot-speak of a drunken fool and you can all breathe a sigh of relief <taohansen>rekado_: yeah i’m having a tremendously good time with it! <taohansen>just started the first exercises reviewing conditionals, if, and, else, etc. <CharlieBrown>Fcitx does not include Mozc for Japanese, and it has errors which disable my UK Dvorak. Enabling Russian does not give Russian letters. Guix on Trisquel. <efraim>mb[m]1: I'm building to python[23] on core-updates now on aarch64 <Necrosporus>CharlieBrown, I don't know what is fcitx, but you can try using /etc/X11/xorg.conf.d/10-layout.conf <Necrosporus>File can be copied from /usr/share/X11/xorg.conf.d and edited according to your needs <mb[m]1>efraim: great! Though we should try get gawk, binutils and the python-updates branch in before starting it on Hydra. <brendyn>CharlieBrown: I'm planning to package some fcitx input methods soon. <efraim>mb[m]1: agreed, although sometimes we only test x86_64 on hydra for starting out <rekado_>I read some months ago that future versions of GNOME will only work with ibus. <efraim>when I commited the changes for more tests to skip on python was the last time i built out core-updates, everything was working fine at that point, so i'm not expecting too much to change with what we have so far <Necrosporus>Why do you want all those things? Isn't whatever is already in X.org and configurable in xorg.conf enough? <Necrosporus>it supports compose keys for arbitrary characters plus variety of layouts <rekado_>Necrosporus: input methods are much more convenient than character composition. <mb[m]1>I tried reporting the gettext test failure with gawk 4.2 to bug-gnu-gettext@, but got a bounce-like email in french back from "dont-nod.com". <rekado_>for Chinese there are various input methods, such as pinyin that maps the official latinisation to Chinese characters; there are also stroke-based input methods that map keys to strokes and strokes to characters, etc. <rekado_>that’s impossible to achieve with just key composition. <brendyn>I actually forgot the reasons exact why I discarded ibus for fcitx but It's because I use Chinese and Japanese methods <clacke[m]>ibus for pinyin (Mando) and jyutping (Canto) has been working well enough for me <brendyn>My main problem is that I use the colemak layout, but fcitx maps everything from a qwerty basis, so i have to switch back to qwerty when I want to use zhuyin input <Necrosporus>Are input methods other than xinput useful for lating and say greek? <brendyn>Well if you want spelling correction and auto completion? <rekado_>mb[m]1, efraim: is there still time for a change to sqlite on core-updates? Or should this wait until the next eval? <mb[m]1>rekado_: 3.21 was released a few hours ago, could you try the update as well? :) <efraim>Idea I'm going to play with for the distribution Dev room at fosdem: living an aarch64 life in an x86 world <drp>you have to use fallback mode <drp>it seems to stop midstream when downloading a wallpaper <htgoebel>Hi, I picked up the "use overlayfs instead of unionfs" thread any am trying to use overlayfs. <htgoebel>Now boot fails, dropping me into the guile debugger. How can I poke around in the system from here? Maybe access a shell? Or get the output of "(system …)" calls? <brendyn>drp: that package fails for me too quite a lot i'm not sure what is wrong with it <drp>brendyn: unexpected end of file of a wallpaper file wasn't it? <drp>I have only ever lurked mailing lists so this is the best place for me to bring it up <drp>next time I install I will give out the full error code <drp>it did work when compiling from source though <efraim>does MooX-File-ConfigDir have the right source? <Digit>how does one extract the .xz usb or virtual drive so they can be used in virtualbox? xz -d gives me a larger file, but virtualbox complains it doesnt reccognise the format. do i just need to add .vdu or something to the filename? <rekado_>Digit: you would probably need to convert it before being able to use it in virtual box. <efraim>rekado_: not sure, sometimes my aarch64 board doesn't want to download sources <rekado_>I’m trying to build it on a different machine now <Digit>a quick "how to ..." ddg search, and i'm doing a "VBoxManage convertdd guixsd-vm-image-0.13.0.x86_64-linux guixsd-vm-image-0.13.0.x86_64-linux.vdi --format VDI" ~ which ran ok, and virtualbox doesnt complain when selecting the new .vdi, and it launches, but then greeted with no bootable medium. <Digit>maybe i should just go qemu again *sigh*, if only qemu had a nice virtual machine manager gui, like virtualbox has. ~ i could just install guix on my native gentoo again, but rly wanted to have it guixsd, n, not on my other computer (it's already there) but here on my main machine, without getting rid of gentoo, n ... just twoulda been more convenient if managed in virtual box along with the many others. <efraim>intel-gpu-tools compiled correctly on aarch64, no clue if its relevant <Digit>ACTION shuts up n installs qemu n all its guis, lets the guix crew get on with it in peace. ***piyo` is now known as piyo
<rekado_>efraim: you’re right about moox-file-configdir <rekado_>when I run “guix import cpan MooX::File::ConfigDir” it downloads the thing just fine <rekado_>could it be that some of the mirrors we have for CPAN are stale? <efraim>i didn't notice a typo, i assumed it was a different author <bavier>rekado_: is the cpan importer working alright for you? <rekado_>bavier: I’m not using it much, actually. <rekado_>these patches were all taken from an old submission to guix-patches. <rekado_>the importer has at least two mistakes: it should use “propagated-inputs” instead of “inputs” for Perl things, and it should add a trailing slash to the home page. <rekado_>“guix lint” complains a URL redirection otherwise. <bavier>rekado_: I noticed that patch recently <pksadiq>is there a plan for setting up priority queue for the build farm? Such that if any package from base gets updated, it will be prioritized than the other, then the package from bare-bones, then xfce, then gnome, etc? <bavier>woo! 'hello' package finally built on my aarch64 system \\o/ <rekado_>pksadiq: there’s no such plan, but I think it’s a good idea to segment the packages somehow. <rekado_>pksadiq: are you interested in working on this? For the new build farm we use Cuirass, which is very hackable. <bavier>we should be able to get a rough idea of "popularity" from the server logs, right? <ebrasca>Why it is build on guile and not in common lisp? <pksadiq>rekado_: I stoped using guixSD (temporarly) because it rquired too much resources than I have (processor and internet). I shall come back after some if this issues gets fixed. <rekado_>ebrasca: because we’re Guilers and not Common Lispers :) <ebrasca>rekado_: But guile is not "common" lisp. <rekado_>ebrasca: these two languages have a very different feel. <ebrasca>rekado_: How is guile compared to common lisp? <rekado_>ebrasca: there are many differences; Guile is Scheme, after all. <buenouanq>I never liked CL - Compared to other lisps it's always felt like a bloated mess to me. <daviid>ebrasca: you should ask these question on #scheme rather <nee`>How much hard drive space does `make check-system` need? I have 15G and it ends with 'ERROR: In procedure copy-file: No space left on device'. <ng0>hey, quick OT question: what's the texinfo magic I need to speak when I want to refer to another documentation? I want to make an "ref" to https://www.gnu.org/prep/standards/ and avoid a weblink… Iirc we did it in the guix documentation but it was some kind of hack with a custom file right? <ng0>(and due to the fact that it's both on gnu.org?) <ng0>"refering to a manual as a whole" wasn't the right section in "info texinfo" <ng0>@inforef{} and @cite{} also seems wrong <bavier>ng0: if standards has an info manual, you can use @pxref <ng0>yes, it's an info manual, but I'm writing with the output target to html, pdf, info and intended location locally (peoples devices), on gnunet.org, and on other systems, primarily .info though. <ng0>huh… do you have an example? Or is this what we use in guix doc? <ng0>the documentation on pxref only speaks of nodes <ng0>and I've been using it for internal reference so far <bavier>ng0: yeah, there are examples in guix.texi currently <bavier>ng0: I'm not familiar with how info renders the results in the different formats <ng0>(@pxref{Guile Preparations, how to install the GnuTLS bindings for <ng0>Guile,, gnutls-guile, GnuTLS-Guile}); <ng0>ah that's still internal i think <ng0>damnit grep, you had one job <ng0>I think it's like this: <ng0>@xref{Guile Preparations, <ng0>how to install the GnuTLS bindings for Guile,, gnutls-guile, <ng0>from memory this produces a link to the gnutls docuemntation <ng0>I'll eperiment and search <ng0>texinfo is currently keeping me sane in one really "incredible" course where all I have is justified rants for it :) <efraim>mb[m]1: Lib/test/test_socket.py from python-minimal on core-updates on aarch64 failed for me <ng0>bavier: well whatever I'm doing with my custom texi2pdf compilation is incomplete and produces strange stuff. I should switch to the tools I copied from GNU as I intended to. I was able to reference and switch to 'standards' texinfo documentation by using @pxref{} when I build GNUnet the "normal" way (without my insered special break). <ng0>long store short nonense: <ng0>@item @pxref{Top, The GNU Coding Standards,, standards, The GNU Coding Standards}. ***urbain1 is now known as numerobis
<numerobis>Hi! I (a guix noob) am trying to import the nix package libreoffice to guix as explained in the documentation of the "guix import" utility in the manual, but I encounter the following error: "In execvp of nix-instantiate: No such file or directory" (I did `export NIX_REMOTE=daemon` before and I set the '/path/to/nixpkgs' to the root of a cloned nixpkgs repository). Would any of you know what I did wrong? <bavier>numerobis: doesn't answer your question, but: did you try guix's libreoffice package? <numerobis>pavier: No, but my goal is not really to install libreoffice. I'd like to try to make a guix package for emby, and starting by importing the nix package seemed to be a good place to start. Thanks though! <mb[m]1>efraim: That's odd, can't think of anything that might be related. Can you try with 3.6.3? <ng0>today my java prof showcased a GNU software in Windows (implicitly) for being better than what we should use (Matlab). Though he didn't mention GNU. Still very nice <ng0>yes right. I thought I put the name in the sentence <bavier>ng0: cool. I appreciated octave during my studies because I could understand the mathematics better after reading some of the octave source <nckx>Random noob git question: if I just push a ‘regular’ expat 2.2.2 → 2.2.4 bump to core-updates, will that cause merge conflicts with master (which currently uses a replacement to do the same)? <lfam>nckx: Yes, but it will be easy to resolve <lfam>I recommend grafting on master, then merging master into core-updates, then undoing the graft and updating on core-updates <lfam>But, if the master -> core-updates merge causes problems, it's okay to skip that step and let someone else handle the merge later <nckx>Oh, OK. I didn't know it was acceptable for $anyone to merge master into core-updates. :-) <nckx>Seems like the easiest way to go then. <lfam>Heh, we always can use some help there :) But if it's tricky, feel free to ask for help. <numerobis>jonsger: Yes, or I'll try to write it from scratch. But I'm pretty sure that I must have done something wrong, because I can't manage to import any of the nix packages. <lfam>Sometimes people who are the de facto maintainers of certain parts of the codebase make similar changes on both master and core-updates, and I have to ask them how to resolve the merge conflicts <lfam>numerobis: Do you have the nix-instantiate command available to you? <efraim>mb[m]1: when I built on python-updates I had to disable Lib/ctypes/test/test_structures.py <efraim>i'll pull in python@3.6 locally and build it and see what fails <efraim>we should also bump the kernel headers on core-updates <nckx>lfam: The only conflict is my own expat update, so that's not a problem. I guess it's normal that ‘git log -p’ doesn't show the merge commit? The resulting xml.scm is fine and contains no replacements. <lfam>nckx: Yeah, your commit should be in the log separately from the merge commit <nckx>lfam: Right! I found it. ‘git show’ shows it, ‘git log -p’ didn't. I'm sure there's a good reason for that if you actually understand git. <nckx>ACTION fakes it most of the time. <numerobis>lfam: Actually, no. I guess installing nix would help! ;) Thank you very much! <efraim>mb[m]1: I wouldn't worry too much about the failing python test, all the 3.x test failures are on aarch64 and seems to increase over time <nckx>‘24404eaf93329b17219c5f2c094c136efa3674d8 failed signature check’ :-/ <lfam>numerobis: Just a warning, even if you get it working, it might still be unsatisfying. It can only import the most basic parts of the package definition. My opinion is that it's only useful for a mass import of many packages, and then only to get them started <lfam>nckx: It passes for me. Maybe you don't have that key, or it is expired for you? <nckx>ACTION updates his keyring <lfam>Glad to see the hook in practice :) <lfam>efraim, mb[m]1: Is there any way I can help with python-updates? Testing anything? <efraim>I was only really testing that the updated packages worked on aarch64, I figured if there was breakage it would be caught in a hydra build <efraim>hey, it looks like my long forgotten lumina desktop package actually works <numerobis>lfam: Thanks! I am not really expecting it to work straight out of the box, but it's just to have an idea of what the basic parts of the package definition should look like, a starting point. :) Unrelated question, but does anyone here use vim for scheme/guile, and if yes, what plugins do you use? <mb[m]1>lfam: it works as-is, the main thing "missing" is a hypothesis upgrade which requires a bootstrap path for python-attrs IIRC. <mb[m]1>I have a WIP branch and will finish it before we start building core-updates. <lfam>numerobis: It works okay but I can tell that these tools are very poor compared to what's possible in emacs <efraim>I use vim, I only use vim-fugitive and vim-airline <lfam>efraim: No paren matching at all? Wow :) <efraim>I finally learned that '%' will go to the matching parenthesis <lfam>mb[m]1: Can I run it in vim? ;) <efraim>mb[m]1: pulling in 3.6 to core-updates causes that test to pass, leaving the two currntly failing as the only ones <efraim>do you want to merge python-updates into core-updates? <lfam>ACTION cancels build of python-updates worktree <mb[m]1>I don't think it makes much sense to build them separately with current resources. <lfam>In the future it will be nice to use topic branches more often, but it's not practical right now <rekado_>matlab has the better marketing, unfortunately. <rekado_>even though few people actually like matlab <rekado_>the marketing is rather directed *against* octave; not so much marketing in favour of matlab. <ng0>"Matlab is sporadic and random in actually working" was the contra point for him :) Octave just works <bavier>we should have a nice text-based backend for 'guix graph'... <efraim>fraction of a second for the graph, minutes for dot <efraim>I looked into piping it into something to pipe to cacaview and came up blank <mb[m]1>I have a one-liner somewhere to pipe straight to "feh", can dig it out later. <lfam>bavier: I sent a patch to make calcurse use an older copy of tzdata for its test suite, in order to reduce the number of packages depending on tzdata. Are you sure it's just used for tests, and not "baked in" to calcurse somehow? <efraim>jimtcl FTBFS on aarch64, time to see what it is <bavier>lfam: yes, it's just for the test suite <efraim>forget it, jimtcl built on my faster aarch64 board, probably an IO bound test failure <bavier>wow, how many gettext's and glibc's do I need to build to get a simple package installed. <efraim>7.89% failures as of evaluation 109807 <bavier>(my numbers might be slightly inflated, haven't gc'd) <lfam>Possibly related to glibc having been grafted <bavier>I'm just surprised at having to build so many things before 'guix package -i' can do its thing <lfam>I would really like to undo that graft ASAP, it's not great for user experience <efraim>unpacking the source requires xz, tar, gzip, bzip2, patch, and some others so the source can be patched <bavier>i.e. 'guix build htop' finished, then 'guix package -i htop' has to build ghostscript, mkfontdir et al, man-db, gettext-minimal, glibc, ... <efraim>it also wouldn't be bad if we could download the grafting version <lfam>bavier: They are "just" grafting builds right? Not actual compilation? <lfam>I'm going to send an ungrafting patch and we can discuss whether or not to rebuild the world for it <mb[m]1>efraim: grafted derivations are substitutable IIRC, but probably requires that an actual profile is upgraded on hydra/berlin/bayfront. <mb[m]1>bavier: are you not using substitutes? <bavier>yeah, the manual-database and ca-certificate-bundle hooks require different glibc derivations than the package I was installing <efraim>wait, second time I got it from hydra <efraim>i think it means the line endings were changed and then re-released with the same version number <nothingmuch>i'm trying to use guix import cpan, i've installed nss-certs but seeing: guix/build/download.scm:295:6: In procedure tls-wrap: X.509 certificate of 'fastapi.metacpan.org' could not be verified: signer-not-found invalid <nothingmuch>I think it worked for some packages earlier, but now works for none (it used to output a guix package to stdout) <bavier>libidn suffers the gnulib test-lock hang too <bavier>I'm curious if the glibc@2.26 update might fix it. <sneek>civodul, you have 2 messages. <sneek>civodul, dustyweb says: congrats on narrowing down the memory leak! \\o/ <sneek>civodul, dustyweb says: and having a supposed fix :)