<shcv>how hard would it be to position guix as the wasm package manager? :P <ArneBab>shcv: I’d guess it would need guix pack --target wasm --publish <module-name> — I don’t actually know how much work it would be. <mikadoZero>I got mu4e sending email again for me by changing from smtpmail-send-it to message-send-mail-with-sendmail with msmtp. <UnderSampled_>I was able to install using rtl18192ce wifi, but after install it seems to want firmware. How did the install medium support it? <UnderSampled_>I presume the install us isn't made with anything I can't get forba normal install, so how do I get an rtl8192ce to work? <reepca>UnderSampled_: The default firmware is in gnu/system.scm, in the %base-firmware variable. That's what your config is most likely using. Give me a moment to check what the installer uses. <nckx>UnderSampled_, reepca: The installer doesn't add any extra firmware. <nckx>Not where I can find it, anyway. <reepca>nckx: out of curiosity, where is it defined? <nckx>In fact, you can just ‘guix system disk-image’ that file to re-create it. <nckx>UnderSampled_: I'm 90% sure that the Thinkpad I borrowed last month had that chip and it worked under Guix… <nckx>…unfortunately, not very well. <nckx>I'm positive you didn't have any firmware loaded in the installer either. The firmware is proprietary so we'd never ship it. The card works without it, just unreliably. <nckx>(I don't have that machine anymore but this all sounds very familiar ☺) <nckx>Sometimes the card would seem dead (no wireless networks in range despite re-scanning in the middle of about 20 of the things), then it would start working again. I didn't investigate because it wasn't worth it to me then. <nckx>UnderSampled, OverSampled, what are you doing to those poor signals anyway… Which gnu/system.scm? <OverSampled>Sorry; phone webirc stopped showing your responses. I successfully am on ethernet on the thinkpad <nckx>Ah, from reepca's reply, got it. That would be in the guix repository. <nckx>Try ‘find /gnu/store/*guix*/ -name system.scm’. <nckx>OverSampled: No need to be sorry, you're right. I'm just so used to working from a git checkout that I don't know how to get there nicely, hence the brute-force find. *nckx should have used ‘find /gnu/store/*guix*/ -path */gnu/system.scm’, there are some unrelated systems.scm in there. <OverSampled>I just installed IceCat, and the default font has no ascii characters <nckx>OverSampled: I'm guessing you mean Unicode? <OverSampled>well, it probably doesn't have any unicode characters either <nckx>I've had my share of font trouble but always safely above 0xff... hm. <OverSampled>Oh, and if I tell xfce4-terminal to use the system font, it immediately crashes when I check that box <nckx>OverSampled: Are you running a fully up-to-date Guix (i.e. have you guix pulled, guix system reconfigured, guix package -u'd?). <nckx>Otherwise, I'd install font-google-noto as a first (again, pretty brute-force) attempt to get full coverage and then run fc-cache -fr. *nckx is firing of random suggestions because → 😴 <nckx>OverSampled: Can't promise it will fix anything but at least you won't be chasing old bugs. <nckx>Chase shiny new ones instead! G'night #guix o/ <OverSampled>I was expecting the install guide to tell me to pull before installing if it doesn't automatically do that when you build <nckx>OverSampled: On purpose, so you install a (relatively) tested system and don't spend a day building from source while running from a live DVD. But it is a trade-off, indeed. <OverSampled>The "relatively tested" bit is the thing that can be improved to be "fully tested" in the future, I suppose. LTS! <OverSampled>Actually, has there ever been an enterprise-level LTS source based distro before? This could be it! <OverSampled>What's the difference between xfce-desktop-service and xfce-desktop-service-type? <brendyyn>"The Linux world has always worked with a develop and deploy model where software gets written by projects such as KDE and then distro projects pick that up, polish it and give it to the user. No other computer environment works like this and it goes against the fashion of DevOps concepts where the people who code are empowered to deploy to the end user going through QA as appropriate. We changed that..." <brendyyn>I'm interested in the discussion between distros providing packages and developers <demotri>`./pre-inst-env guix build -S ruby-sass-spec` fails with a sha-mismatch while downloading substitute sources from ci.guix.info. Any idea? Local download works. <ArneBab>brendyyn: I’d love to have a way to define something cross-language which creates packages distros can simply include without changes. <ArneBab>something like guix export -l guix.scm package.deb <brendyyn>ArneBab: it would likely come under the guix pack command <ArneBab>could that also support Gentoo ebuilds or a Arch package descriptions? <brendyyn>I need to post some patches before 1.0 to get my name in ***ChanServ sets mode: +o civodul
***civodul changes topic to 'GNU Guix | https://gnu.org/s/guix/ | videos: https://gnu.org/s/guix/blog/tags/talks/ | bugs and patches: https://issues.guix.info/ | paste: https://paste.debian.net | Guix in high-performance computing: https://hpc.guixsd.org | This channel is logged: https://bayfront.guixsd.org/.well-known/logs/ | 1.0 is in the works!'
<brendyyn>civodul: Will the contributors list for 1.0 include all names or just the names since the last release? <civodul>i haven't really thought about it :-) <civodul>the whole list would be a bit long i guess! <brendyyn>I was thinking about removing all redundant uses of mkdir-p. That'd ramp my contributions up <ArneBab>brendyyn: oh, ok — Gentoo ebuilds are just descriptions, very similar to guix packages. <brendyyn>which would be compared to Arch's PKGBUILD <ArneBab>ah, then I did remember correctly that they have something similar :-) <brendyyn>Do you mean exporting a definiton for installing a guix pack binary? <civodul>roptat: i assume you'll take care of committing all the new .po files, is that fine with you? <numerobis>Hi #guix! I see that the guix has a boost 1.69 package, which contains boost numpy headers but not the corresponding .so libraries. Is there a way to install libboost_numpy on guix? Many thanks for this great project! <civodul>numerobis: looks like our boost package doesn't depend on numpy, so perhaps you'd need to define a separate boost-numpy package or to add numpy as a dependency to boost? <civodul>it may be worth discussing this on guix-devel@gnu.org <roptat>civodul: I'll do that this afternoon <numerobis>civodul: Thank you very much for your response. I'll investigate your suggestion when I have time. :) <civodul>Miguel must actually be a code name for a 12-person team, that's why <brendyyn>If you wanted to write a program that used some guix modules, how would you package it? if you didnt include guix as a dependency, guix pack would not export guix with it right? but if you did then it would be the old version defined in gnu/packages <brendyyn>ImportError: No module named backports.functools_lru_cache <brendyyn>I'm getting this even withhhhhhhh the functools package in the environment <ArneBab>brendyyn: I had the same problem and had to adjust the pythonpath … <ArneBab>brendyyn: have a look whether your python2 might be trying to pull in python3 modules <brendyyn>ArneBab: I'd like to fix the package for good <brendyyn>but i dont really understand this stuff too much, <brendyyn>functools isnt used at the moment, so i guess such errors would go under the radar <ArneBab>backports.functools_lru_cache is only available in python2.7, because python3 has it without the backports prefix <ArneBab>if `echo $PYTHONPATH` contains *python3.7/site-packages*, that could be a problem, because PYTHONPATH is not version specific <brendyyn>guix environment --ad-hoc python2-backports-functools-lru-cache --pure <ArneBab>brendyyn: it’s cleaner than what I have … <ArneBab>python3 -c "import sys;print(sys.path)" <brendyyn>"PYTHONPATH is somewhat of a hack as far as package management is concerned. A "pretty" solution would be to package your library and install it." *brendyyn is packaging and installing it <ArneBab>brendyyn: you can get the actual search paths via the command above <brendyyn>Perhaps this is only an error that occurs during building <brendyyn>Looks like there are many tens of packages that set PYTHONPATH during build. so i guess this is not an unusual bug <ArneBab>I worked around it by fiddling even more with PYTHONPATH, just to get my usecase working, but that is pretty horrible in general. <brendyyn>I don't really know what the correct solution is then <ArneBab>the core problem is that python looks into absolute paths to find the packages — i.e. /usr/local/lib/pythonX.Y/site-packages/bar <brendyyn>Actually I think it will work because the program im packaging is wrapped <ArneBab>Guix already somehow adds the paths, so someone figured out how to do the right thing <brendyyn>if you open a python program you will realise its just a small wrapper script <brendyyn>The think is I have 10-20 other python packages as inputs but none of them needed any hacking like this <rendaw>Hello! I have a program that takes a script as an argument. I'd like to run a g-expression. Is there an easy way to turn a g-exp into a string path of an executable script? Looking at how initrd it seems like a fairly elaborate process: program-file with gexp, compile-to-cache, locate current guile, symlink guile to script's directory, etc <rendaw>And the only way I see in code to get the path of the gexp script is to use `(symlink derivation "something")` which creates a symlink in the current directory (which would be the directory I'm running `guix system` in? That doesn't seem super helpful) <rendaw>The context is `pam_exec.so` needs a script as a string argument <pkill9>how can you do a search-and-replace of a string in guile? <amz3>pkill9: I think it is called substitutes* procedure in guix repo <amz3>pkill9: build/utils.scm: substitute <davidl>pkill9: example: (substitute* (find-files "bin" ".*") (("^#!.*") (string-append "#!" bash "/bin/bash\n"))) <davidl>where bash is the path to /gnu/store/asdfasdfbash <efraim>Or (which "bash") in place of string-append <davidl>efraim: yeah unless it's part of a package-definition where the which command is not available by default (needs specified in %build-inputs). <civodul>brendyyn: the question you asked about how to depend on Guix is a good one <civodul>there's no great answer, it depends on what you're doing with Guix <civodul>you could depend on the 'guix' package and use an inferior to get the latest packages, for example <civodul>but sometimes that's not a great approach <brendyyn>I guess one use case is creating a gui package manager front end. another is just using miscellaneous abstraction from guix's modules <civodul>for a GUI front-end i think inferiors are OK <davidl>I have a package-definition using the trivial-build-system and the #:builder runs a ./install.sh script that uses the which command. This script fails saying line 62: which: command not found. Im unable to fix it with guile's setenv and "/path/bash -c PATH=<path-to-which-etc> /path/install.sh" still install.sh doesn't know the path to which command. <brendyyn>ok im really quite confused at why this functools module cant be found despite being in PYTHONPATH <brendyyn>when i test python2 -c "import backports.functools_lru_cache" manually it works fine <rekado>civodul: the gnome-shell problems on staging should now be fixed <rekado>civodul: I still haven’t been able to work on the guile-json upgrade and I’m afraid there might not be enough time to get it done before 1.0. <rekado>(I’m not confident in my ability to weed out all problems that might arise from the conversion) <samplet>rekado: I’m testing gnome-shell now. <rekado>davidl: the trivial-build-system hardly does anything at all. It does not set up PATH. You will also need to ensure that “which” is among the inputs, of course. <rekado>davidl: generally, it may be better to use gnu-build-system, delete the “configure” phase and replace the “build” phase with a procedure that executes install.sh. <rekado>brendyyn: “found” where? In a package definition? <samplet>I think we could move gdk-pixbuf out of LD_LIBRARY_PATH at run-time and into PKG_CONFIG_PATH (or something) at compile-time, but we’ll see. <rekado>there are a bunch of other things in gnome-shell that ended up gonig on LD_LIBRARY_PATH. <brendyyn>rekado: there is a test that runs import backports.functools_lru_cache, but reports that the module cant be found <rekado>brendyyn: how are the tests run? <samplet>rekado: Yeah, but I presume it’s because they are not configured in the build system, which is not a problem for gdk-pixbuf. <pkill9>amz3, davidl: substitute* operates on a file, I wanted (don't need it anymore) to operate on a string in guile <rekado>brendyyn: this just means that setup.py test is run; but does setup.py do anything funny with the load path? <brendyyn>there is this trivial test that runs "import soupsieve, bf4" to test for its existence <rekado>some Python packages are picky about how the test environment is set up. <brendyyn>but i looked at the PYTHONPATH and clearly see functools path <rekado>brendyyn: have you tried adding it? You can also check if replacing the check phase with an invocation of pytest works. <rekado>pkill9: there’s regexp-substitute. <brendyyn>pytest fails. I would expect Calibre to work with anything really the developer doesnt really care about software packaging <brendyyn>E AttributeError: 'module' object has no attribute 'resources_location' <brendyyn>It's just a directory in the package source with various bundled stuff <civodul>rekado: re gnome-shell, awesome! thanks! <civodul>i believe 'staging' should be mergeable now? <civodul>the guile-json upgrade can happen after 1.0, that's okay <samplet>Sure thing. It seems my main talent is teasing out good ideas from rekado! :) <bavier>could we maybe fix the exit-code issue for 1.0? <bavier>i.e. the comment in scripts/guix.in <civodul>bavier: it's not an issue in practice, is it? <bavier>imo it's nice to be able to rely on the exit code. e.g. guix pull && guix package -u <pkill9>is there a way to change the sudoers file using a service? <civodul>bavier: you _can_ rely on the exit code; the comment is just about structuring things differently <civodul>pkill9: no, but it would be a welcome addition! <demotri>What's wrong here: guix archive --export /gnu/store/mn6522xx9lmirzzvmrkjga1vil0sqg1p-ruby-sass-spec-3.5.4-checkout | guix archive -x out <demotri>guix archive: error: corrupt input while restoring archive from #<input: file 0> <demotri>guix archive: error: fport_write: Broken pipe <civodul>demotri: did you generate a key pair with 'guix archive --generate-key'? <demotri>civodul: I think I did this a long time ago. When looking at /etc/guix, I see a signing-key.pub/sec, two years old. <demotri>civodul: A "uix archive --export /gnu/store/mn6522xx9lmirzzvmrkjga1vil0sqg1p-ruby-sass-spec-3.5.4-checkout > outfile" produces someting, when I look into that file I see binary garbage with "nix-archive-1" somewhere. Export looks good to me. Problem seams to be the import. <demotri>I.e: This command is causing the error: guix archive -x out < output <davidl>rekado: thx for the tip. Though I managed to finish the package definition using the trivial build system. <demotri>civodul: What I actually want to do is compare my local store entry with the download from ci.guix.info. That seams to have a problem: <demotri>`/pre-inst-env guix build -S ruby-sass-spec` fails with a sha-mismatch <civodul>demotri: hmm it fails for me as well, dunno what's going on <civodul>"guix archive --export" produces something that's not quite a nar <civodul>whereas "guix archive -x" expects exactly a nar <civodul>also the pipeline you shown above would have been equivalent "cp -a /gnu/store/... out" <demotri>civodul: Hm? When I download a something from ci.guix.info, it IS a NAR? But when I do the same with guix archive --export, it is not exactly?! But then how does ci.guix.info produce the "fully-certified NAR"? <civodul>'guix archive --export' produces a stream of nars, which includes extra markers <demotri>civodul: OK, at least then I can "cp" my local part, and I extracted the downloaded version already. <davidl>Can you install and use shepherd if you have installed guix just as an extra package manager on RedHat without breaking the system? What happens after a reboot when shepherd has been installed? <kmicu>How do you want to use it davidl? <davidl>kmicu: If somehow possible I would like to use shepherd services instead of systemd services, but Im on RedHat instead of GuixSD. <kmicu>If you want to replace a native init system with Shepherd then that will not work. <davidl>Basically I just want the generation and rollback functionality for the definition of services. Thinking I could start shepherd from systemd, then shepherd has for example an mcron service etc that I could get into guix version control. <kmicu>It sounds like you want a Guix System but installing it is not an option. <samplet>rekado: It works with neither PKG_CONFIG_PATH nor LD_LIBRARY_PATH. At least for me, just adding “gdk-pixbuf+svg” was sufficient. <davidl>but maybe there are no feasible workarounds. <katco>in a package def, within a `snippet` block, how can i access the path to the output directory in the store? <kmicu>davidl: It will be time consuming to occupy the space between Guix and Guix System on a foreign distro but I wish you luck. That’s a new territory for exploration. <apteryx>do we have a VNC server service in Guix? <kmicu>[Paraphrasing Little Britain’s gag] Source Code says no. <reepca>I'm curious what the motivation is for 'recursive?' arguments to stuff that may deal with a directory or a file. Any idea? <nckx>reepca: Not meant to be snarky at all, but… besides the obvious? What kind of stuff are you referring to? <reepca>nckx: for example, add-to-store has a recursive? argument which gets sent as-is to the daemon, but looking in nix-daemon.cc it looks like all it affects is whether it should fail on a non-regular-file input or not. Why add a flag that just causes it to fail sometimes? <reepca>I would expect that any procedure dealing with files can determine on its own whether a given file is a directory or not - I mean, to even be able to do anything recursively, it *has* to be able to do that much. <nckx>reepca: I'd interpret such an argument not as ‘the procedure can't figure it out on its own’ but as ‘sometimes we want to explicitly forbid recursion’, but you're far more familiar with the daemon than I am. I don't know if it makes sense there. Maybe not. Maybe it's historical cruft? The daemon is certainly more complex than it should be. ***dalz[m] is now known as dalz
<reepca>nckx: fair enough, though I can't really think of an example where it'd be necessary. I'm trying to implement add-to-store right now, and there isn't a corresponding 'recursive?' argument to restore-file, and I'm rather wishing I could just ignore it. <nckx>You'll find no objections from me there. Simplification would be welcome. <dalz>Can anyone read this? I'm having some tecnical difficulties :) <nckx>reepca: I think ignoring it until you find a use case is the right thing to do. <dalz>Now, to my actual questions <dalz>Should I depend on nss-certs? Grepping for ,nss-certs yields only two results, and I think there are more packages that deal with https than that. If I do put it in my inputs, should I give as a compile argument /etc/ssl/certs/ca-certificates.crt or /gnu/store/...nss-certs.../.../ca-certificates.crt? <nckx>dalz: A Matrix user without [m] spam? The horror! ☺ <dalz>Square brackets are for clojurists! <nckx>dalz: You definitely shouldn't. If you need it for tests, make sure you don't retain references to it in the final output. <nckx>If you need it at run time, I think you can safely use the SSL_CERT_* variables. <nckx>(We shouldn't trust things on the user's behalf being the rule here.) <nckx>That could've used some punctuation but you get my drift. <dalz>I didn't notice them, thanks <dalz>nckx: so I need to set CURL_CA_BUNDLE to $SSL_CERT_FILE. Should I write a wrapper script that does this and then calls the actual program? <nckx>dalz: As it happens, CURL_CA_BUNDLE should also already be set in users' environment, but I don't know if it depends on cURL being present in the profile. <nckx>dalz: See the ‘newsboat’ package for what might be a useful example. <dalz>nckx: checking it out now, thanks <dalz>mhh... doesn't tell me much. I don't actually have CURL_CA_BUNDLE set, yet I have curl installed <nckx>dalz: Hrm. Is this on Guix System? <dalz>> [20:30:55] <ecbrown> (answer to my previous question about R and SSL error: guix package -i curl and place CURL_CA_BUNDLE=<whatever> in ~/.Renviron hopefully this message will be found by search) <dalz>This is from august 2018 <nckx>I fully admit to not understand exactly how that works. <dalz>It suggests it's not actually set automatically <dalz>(as a side note, such a shame irc logs are deleted... i came across a couple indexed logs while searching stuff, but the actual file was gone) <katco>in a package def, within a snippet block, how can i access the path to the output directory in the store? <nckx>dalz: It's set here. I can't find where. *nckx wishes Unix were designed, there'd be metadata attached to env vars or something. <nckx>dalz: Unfortunate and unplanned. The current log situation isn't more robust than the previous one, I'm afraid. Archive them if you care. <dalz>I guess it's a downside to irc... you get awesome personalised help, but it's ephemeral information ***Glider_IRC_ is now known as Glider_IRC
<katco>dalz: matrix has a bridge to irc (from which i am speaking to you through, hi!), therefore, the history of this room is searchable through there. i'm not sure if that helps. *nckx keeps grepabble ZNC logs now, huzzah for self-reliance. <dalz>katco: I am talking through matrix too :) <dalz>However, I can't access messages sent before i joined the room <katco>i'm trying to use `(gexp #$output)`, but strangely that gives me the source archive which was downloaded <katco>dalz: oh, hm. maybe that's a limitation i'm not aware of. i thought the room had the same urn for all users, and thus the history was a function of the bridge lifetime, not when a specific irc user joined. <kmicu>(#guix has public logs (location is in the topic)). <nckx>kmicu: Yes, but they don't go back very far and you don't want to see how *that* sausage is made. <nckx>I think dalz was referring to the old GNUnet Drupal bot ones? <nckx>How I miss that default theme :'( <kmicu>katco: iiuc ‘snippet’ is for source modification only. <kmicu>nckx: that’s a feature. Old logs have outdated info 😺 <katco>kmicu: yes, i am trying to run a `substitute*` on a source file, and i want to place the output directory into a source file <nckx>katco: At the time the snippet is evaluated, there's simply no concept of the *build* output yet. <nckx>You'll need to do that in a build phase. <katco>ah, i see. so this has to be an after build phase of some kind <nckx>Source derivations are separate from build ones. <katco>i don't yet fully grok how packages interact with the store. i've been doing a lot of packaging, so things are getting clearer. thanks for the info! <dalz>nckx: nope, I just joined the party and know nothing about old logs (besides the fact that i can't find them) <nckx>(foo.tar.gz.drv and foo.drv, completely separate.) <nckx>katco: Doesn't have to be after-build, just has to happen during it. The output directory is calculated before the build starts so you can (add-after 'unpack …) if you need to. <kmicu>[Joke] So five days left until Guix System 1.0 Ablaze Altair. Cool. Cool cool cool. <nckx>Oh oh can we choose release nicknames? <nckx>Guix 1.0 Death Comes For Us All. <nckx>Guix 1.0 At Least It's Not Docker. <dalz>nckx: yeah, that link looks familiar enough <dalz>the worst feeling is seeing part of the message in the search results, clicking on the link and... 404 <nckx>kmicu: I admit to not getting the reference, although I agree that running Guix on an Altair might present some thermal challenges. <dalz>that's how i noticed my messages were not ignored, just undelivered :) <kmicu>nckx: it’s a star! There is a world besides IT Doh! My take is that Guix shines so bright like Ablaze Altair but we can move to Ablaze Aldebaran to avoid any trademark issues. [Still jokin’]. *kmicu [impersonating Carl Sagan] We are star stuff. Guix is star stuff. <nckx>kmicu: My world is very much not IT. I know Altair, but what's Ablaze? A state? A star state? <nckx>Guix is definitely stuff. We can slap that on without getting sued. *bavier just finished reading Sagan's "Cosmos" <kmicu>On fire; in a blaze, gleaming. --Milman. In a state of glowing excitement or ardent desire. <kmicu>When I use Guix I’m in a state of glowing excitement. *nckx prefers ardent. Ablaze just sounds too much, y'know. Like, Altair, turn it down a notch. <nckx>kmicu: Same same. The quality of the excitement differs. Sometimes it's pretty shouty. <kmicu>ardent ‘Warm, applied to the passions and affections; passionate’. That sounds like Guix. <bavier>should definitely increment the names lexicographically so we don't run out too quick; i.e. AA, AB, AC ... ZY, ZZ <nckx>Sometimes I'm waiting for a kernel to compile so I waste others' mental bandwidth on IRC. <nckx>Guix 1.0 Ardent Aardvark. <kmicu>bavier: Do we plan to have more Guix releases than the stars are in the sky? Cool. 😹 <kmicu>nckx: You talk Ubuntu to me. <nckx>kmicu: Oh, there was apparently an ‘Artful Aardvark’ Ubuntu release, I didn't know. <nckx>Guix 1.0 Glorious Gnu - Guix 1.1 Glorious Gnu - Guix 2.0 Glorious Gnu … <nckx>(For those wondering the obvious: ‘The Gibbon won the G-race to be [Ubuntu's] engineering mascot for this next release, but it was a close run. We very much wanted to honour the <nckx>tremendous contributions of the GNU project to Free Software by awarding the role to the Glossy Gnu. This prompted an intense internal debate about trademarks’.) <quiliro>hello...how can a user browse the web with tor on guixsd? *kmicu always keeps ‘Glorious’ next to ‘… Haskell Compiler’. <nckx>quiliro: Doesn't tor start a SOCKS proxy on $port? You'd configure your browser to use that. [Blah blah, security risk, DNS leakage, maybe, I don't know] <nckx>quiliro: Search the manual for tor-service-type for documentation on starting Tor as a service. <roptat>with icecat, you can go to about:preferences, network proxy, select manual proxy, and socks v5, proxy is localhost on port 9050 and also select "proxy DNS when using Socks v5" <roptat>of course you need to add (service tor-service-type) to your operating-system configuration *nckx always reads GHC as ‘GNU Haskell Compiler’ despite never actually having thought this was its real name. It's automatic. <kmicu>quiliro: Tor Browser is not packaged so using socks is the only option now. (But keep in mind that’s a less private option for browsing). <quiliro>the idea is to connect to an onion site <roptat>the socks proxy is enough for that <quiliro>bavier: w3m does not support js...i think <nckx>Wasn't there a Web MITM one could use browse onion sites if they don't care at all about privacy? <kmicu>(That’s a feature, not a bug ;) <nckx>quiliro: Remember that just running JS makes you a lot more identifiable with or without Tor. <quiliro>is there is something equivalent w/o js? <quiliro>but isn't the whole web filled with js? <nckx>OK, so Freedombone isn't specifically a Tor thing, that makes more sense. <nckx>quiliro: Yes, which sucks, but I manage without. <roptat>I'd suggest Guix System (if I understand what freedomebone is) <quiliro>i do not know how to integrate the services onto guixsd yet <nckx>quiliro: Web things are often not the easiest to package (they're often insanely complex and anything using npm is a nightmare) but please do! <quiliro>for now, i am using some sites with epiphany, others with eww <quiliro>i aspire to have a network appliance to do basic communications as does freedombone.net <roptat>"basic communications"? like what? <nckx>So this is a device running Tor so you can ignore our advice above about tor-service type, but you probably figured that out yourself. <quiliro>roptat: voice over ip, videoconference, file sharing, file storage, chat, voice conference, messaging (email style) <quiliro>nckx: so you mean i do not need tor-service? <kmicu>Freedombox/Freedombone works out-of-the-box on ARM boxes. It’s a nice addition when we don’t want to spend weeks configuring everything. <nckx>You're talking about connecting to a Freedombone appliance already running Tor, right? <nckx>Then you'd just add the device (IP+port) as a proxy. I guess, I've never actually done that. <nckx>This will work with any browser, but be warned that (according to the Tor Project at least) anything that's not Tor Browser might leak some information over the regular 'net. <nckx>Tor Browser works under Guix with manual patchelfing but it's extra work. <quiliro>i don't get it... you mean that i connect to an onion address on my freedombone by putting my freedombone as a proxy on icecat? <nckx>You said you wanted to try Tor to test your Freedombone, or did I misunderstand? <nckx>You can run Tor + a browser on your own machine but that doesn't really ‘test’ the Freedombone in any way other than as a plain router. <quiliro>i want to connect to my freedombone by accessing it through its onion page <kmicu>Connect to a Freedombone from a Guix System? <nckx>OK, sorry, I misunderstood the misunderstanding then ☺ <nckx>tor-service-type is the light and the way. <quiliro>ok...so i set up tor-service-type for all users? <quiliro>is there a way that only one user could do it? <nckx>Services aren't per user so yes. And… maybe, but I can't help you with that. <bavier>quiliro: iirc the tor configuration allows one to restrict access to a specific group <kmicu>Thank you bavier “If it is 'unix, then Tor will listen on the UNIX domain socket /var/run/tor/socks-sock, which will be made writable by members of the tor group” <raingloom>does gcc not have cc symlinked to gcc on purpose? <bavier>raingloom: can you set an environment variable instead? <raingloom>bavier: no, it's not configurable in the makefile. I could just ask upstream to add an option for it. <nckx>raingloom: They hard-code cc? :-/ Please do. You'll have to use substitute* for now. <bavier>if I'm looking at the right Makefile, it's only used in a single recipe, should be $(CC) instead *nckx reads ML mail and is glad they don't use GDM… <OriansJ>is there any particular reason why guix pack doesn't support file inputs like build and package?