<mekeor>there is no guix-package for the Android Debug Bridge (ADB) yet, right? <mekeor>did anybody begin to package it, maybe? <CharlieBrown>Hey, anybody know how to get Jitsi Meet working in IceCat? <mekeor>CharlieBrown: maybe disable the ’GNU LibreJS‘ addon in IceCat? <mekeor>CharlieBrown: what exactly doesn't work? <CharlieBrown>mekeor: I made an exception for Jitsi's site in the LibreJS settings. When that didn't work, I disabled the LbireJS and SpyBlock addons. It still results in a Jitsi session that has unresonsive buttons and blank video boxes. <CharlieBrown>mekeor: I also tried it in IceWeasel. It didn't work there, either. <mekeor>CharlieBrown: i've got no idea then. maybe a look into the javascript-console (within the web-developer tools of icecat) could help? maybe there is a #jitsi irc-channel which can help? ... good luck! <buenouanq>call whoever sent you a rar and yell at them and have them send you something else <gazon>has anyone experienced a very long wait for make test in /tmp/guix-build-guile-ssh-0.9.0.drv-0/source/tests? it's been on tunnel.scm for several hours. doing a guix pull in a vm which was using guix 0.11.0. <marusich>luser1, not sure...what exactly is a RAR file, anyway</ <marusich>The Wikipedia page says, "decompression source code is available, but it's not free software due to the restriction that it must not be used to reverse engineer the RAR compression algorithm" <marusich>If that's true, then I don't think the tool will be included in a free software distribution like GuixSD. <luser1>I don't expect a tool be included with Guix. <marusich>I do not know of any tools which can decompress RAR files, myself <luser1>There are free software that decompress rar files. <luser1>But it's not working for me as it fails (literally says that) when I try it. <luser1>I'm compiling peazip since it can decompress rar files apparently. <marusich>luser1, it looks like unrar is already packaged <marusich>FWIW, I was able to build unrar locally just now in GuixSD. <luser1>marusich: Try using it against a file. <marusich>Anyway, glad your problem was solved. And I even learned something about RAR :) <marusich>Oh. Well, I don't have any RARs at the moment <marusich>If it is reproducibly not working, you might want to file a bug report. <marusich>I gotta log out while I move locations, though. See you around! Glad you were able to solve your issue. ***Piece_Maker is now known as Acou_Bass
<htgoebel1>how can I access "inherit" a phase within a package definition? <htgoebel1>Like ant-build-system does: ((assq-ref gnu:%standard-phases 'unpack) #:source source))) <ZombieChicken>Anyone here have any experience replacing the linux-libre kernel with something else? <ZombieChicken>Actually, how does a system reconfigure handle using something like GUIX_PACKAGE_PATH? <roelj>ZombieChicken: I searched Github for "guix iwlwifi" and found the package recipes I needed.. Of course, this is quite ugly as those packages contained binary blobs.. <roelj>When you set GUIX_PACKAGE_PATH to a custom directory and then run "guix system reconfigure" it will be able to reconfigure with those custom packages. <ZombieChicken>I know I'm going to have to use a different kernel, but I'm also worried about things like Mesa. As it turns out, the open-source nvidia driver doesn't work for me <ZombieChicken>It can't reclock my GPU, and I actually have a need for that power <roelj>I don't know much about nvidia drivers, but isn't it "just" a kernel module that should be loaded? <ZombieChicken>I'd have to look it list of files installed up, but no. There is also a few libs (libGL.so, for instance) that are special <roelj>Ah right. I imagine it takes quite some fiddling before getting that right. <ZombieChicken>but there is certainly a chance for some serious problems, like getting Mesa to play nicely with it <roelj>It would be pretty awesome if it was just free software, then we could figure it out fairly easily I guess.. :) <ZombieChicken>Yeah. At this point I'm expecting an FPGA-implemented GPU before anything useable and open <civodul>htgoebel: i'm not sure i understand yuor question <civodul>htgoebel: the snippet you show is one way to "copy" a phase <civodul>tomorrow's the deadline for GSoC, and it seems we'll have zero students this time <reepca>... maybe one of them will submit something at the last minute and try to blow it off by making a joke about lazy evaluation? <janneke>ACTION has generated first mes binary from mini-mes.c using mescc: we're self hosting! <janneke>still quite some cleaning-up todo before 0.5 release <catonano>civodul: did anyone advance their candidacy for the GSoC ? <htgoebel1>civodul: This snippet errored when I tried. Tried again and it works :-) Obviously the error was caused by something else. <efraim>before I forget! I was reading The Unix and Linux Administration Handbook, they had a throwaway comment that manpages can be a colon separated list of directories <roelj>janneke: That's really cool! <roelj>janneke: I look forward to having the time to read the source code of mes. <janneke>roelj: if you wait a bit things will get easier to read ;-) <roelj>janneke: Hehe, looking forward to it :) <civodul>catonano: there was only one candidate (mthl on Cuirass) who canceled afterwards <civodul>in previous years there's always quite a few people that email us <civodul>not necessarily a bad thing though ;-) <civodul>but often that's quite a bit of time investment as a mentor <OriansJ>congrats on the self hosting janneke could I get a broken out version of mini-mes to play with? <janneke>OriansJ: not sure what you need wrt broken out? <janneke>i'm working to cleanup for 0.5; that should only have a single self-hosting mes <janneke>currently, i have besides `mes.c' a sanitized copy in scaffold/mini-mes.c <janneke>they practically coincide now, apart fro some pesky details ;-) <janneke>OriansJ: i also have some bad news... mini-mes.c takes about 1h30' to build with mescc <janneke>i'm afraid that rewriting mini-mes.c in your lisp will add about a factor of 100 of speed loss? <janneke>working on the wip-mescc branch right now <OriansJ>janneke: actually, I was wondering if your mini-mes.c was small enough to manually convert to assembly <janneke>OriansJ: it's about 2000 LOC, producing a ~50kB binary, rather verbose assembly <janneke>so i guess it's a bit too early for that <janneke>OriansJ: how about separating-out the assembler-bit of mescc, and dumping annotated assembly first? <janneke>trying to add either a i686 cross compiler or multilib -m32 compiler to package defininion <janneke>ACTION should have a clue here, but terribly confused <yoosty>wow, a lot more people in #guix these days :) <phant0mas>janneke: maybe add (cross-gcc "i686-linux") as a native input? <janneke>phant0mas: hi! yes... i also have cross-gcc, cross-libc; but keep getting <assert.h> not found, or crt0.o not found, or libgcc_s.so: error adding symbols: File format not recognized <janneke>whereas something like: guix environment --system=i686-linux --ad-hoc gcc-toolchain -- bash -c 'make mes-32 S=-32 CC=i686-unknown-linux-gnu-gcc' <phant0mas>janneke: maybe the recipes in gnu/packages/avr.scm can help you <janneke>phant0mas: that could be...I'll have a look thanks! <janneke>phant0mas: how are you doing with hurd? <phant0mas>janneke: I am waiting for the next core-updates cycle to start pushing more Hurd related changes <janneke>phant0mas: after i got my recipe written down and hurd VM up, i wondered: what now? <civodul>janneke: since we can cross-build to GNU/Hurd now, we should be able to build a VM image that boots GNU/Hurd (without GuixSD for now) <civodul>similar to what i did long ago in Nixpkgs <civodul>i think that's a fairly low-hanging fruit <lfam>civodul: Speaking of building a qemu-image, that's something I wanted to add to the "next release" to-do list. <lfam>To get hydra building it again <civodul>lfam: so what os config would it build? <lfam>civodul: Something close to bare-bones that's ready for virtualized environments <phant0mas>janneke: currently I am working to finish the Hurd side of the daemon and solve the guile test problem <lfam>civodul: Yeah, although I don't like the idea of hard-coded passwords. I guess we'll invent a suitable workaround sooner or later <civodul>we just need to do the same for sshd <lfam>Okay, I can put that on my todo list, but I invite everyone else to steal things from my list ;) <civodul>as a first step i can take the lsh thing into Guix proper <janneke>ACTION trying to build an avr-like i686-linux-gnu thingy <civodul>currently it's in guix-maintenance.git <lfam>I guess it will come after the GRUB terminal configuration thing <civodul>besides, what do we do with "greenisland"? <civodul>i was about to press the "merge" button and then i saw Marius' message :-) <lfam>Right, I didn't realize that sddm was an important package <lfam>We have another vim package that works fine, right? <lfam>Plus nvi. What more could one possibly want in a text editor? :) <lfam>Reading myglc2's comments on the GRUB thing, I'm beginning to think that exposing the GRUB configuration properly is sort of tricky! <lfam>Suddenly there will be lots of ways to break GRUB :) <lfam>I think the 'graphical?' toggle is pretty safe. At least, it's no worse than the current situation, where GuixSD's default GRUB menu doesn't show up on most of my installations :) <lfam>On the other hand, myglc2's message makes me think that 'graphical?' is not going to be useful for servers <lfam>The values that GRUB accepts for 'terminal_output', 'terminal_input', and 'serial' all seem to be defined in the GRUB manual. So we could abstract them. Validating them fully sounds tricky or maybe even impossible, although GRUB does provide a syntax-checking script we could use when building the new grub.cfg <rekado>civodul, lfam: we also have neovim <lfam>I think the modal editors are winning the race in Guix ;) <janneke>ACTION managed to avoid emacs for almost 10years (until '97) <clacke[m]>I haven't tried geiser yet. Seems pretty awesome, from what I saw in paroneayea's 8sync presentation. Any live guile REPL in neovim yet? :-) <lfam>catonano: Does the error repeat if you run the command again? <rekado>hmm, I don’t think this grant application is going to fly <rekado>there are more than 250 applicants <OriansJ>lfam: emacs does also count as a modal editor, should the user so choose... <lfam>Heh, emacs counts are everything, right? ;) <lfam>I mean, it counts as everything <OriansJ>well it certainly is everything you need it to be. <civodul>rekado: but yours is certainly among the best :-) <janneke>how do i get the output of a package? as in something like: <janneke>search-path: (files (list (string-append i686-linux-gnu-libc "/lib"))) <civodul>the 'files' field in search-path-spec should be relative <janneke>getting gcc -m32 or i686-linux-gnu-gcc to work in a spec is driving me mad <civodul>oh but gcc -m32 requires libc to provide both 32- and 64-bit headers, which we don't do <janneke>guix environment --system=i686-linux --ad-hoc gcc-toolchain -- bash -c 'make mes-32 S=-32 CC=i686-unknown-linux-gnu-gcc LIBRARY_PATH=$${PATH%%/bin:*}/lib' <janneke>in my makefile, which is amazingly easy <janneke>but cannot do it like that -- i cannot get `guix' to work in a guix build recipe <janneke>i've spent all night to get i686-linux-gnu-gcc to work and finally have something working: with a hardcoded CROSS_LIBRARY_PATH <reepca>Question(s) (and I'm sorta in a hurry, because I'm not sure when today the applications close - timezones and all that)... how integrated is the GSoC build tool supposed to be with guix? It says "by default runs inside the GNU Guix build system" (no mention of that at https://www.gnu.org/software/guix/manual/html_node/Build-Systems.html), and it also says "in time, we can target out of GNU Guix builds" and "we primarily target GNU Guix <reepca>because Guix already solves the complexity of handling dependencies and software deployment". Is it talking about the package manager or the system there? I would assume the package manager, but how would such a build tool handle the stuff Guix solves without Guix? <janneke>civodul: so i was now hoping to calculate the hardcoded library path <janneke>we really need to just provide a i686-linux-gnu-toolchain package :-) <reepca>I'm just not sure how much a person would be allowed to assume in developing said build tool if the goal is to eventually work without Guix (is that the goal?) <rekado>the build tool was Pjotr’s idea, wasn’t it? <rekado>I’m not really clear on what the goal there is. <rekado>reepca: sorry, I can’t answer these questions. <civodul>janneke: you should use a native compiler for i686, not a cross-compiler <civodul>so the initial "guix environment -s i686-linux" lgtm <civodul>in the package definition, you can use #:system "i686-linux" (see Wine for an example)