<ng0>if I could, I would file a bug on this, but I can't send emails because of this temporarily, so I'll just say here that I hope that updating torsocks to the latest stable will fix this: WARNING torsocks[16538]: [syscall] Unsupported syscall number 202. Denying the call (in tsocks_syscall() at syscall.c:165) <ng0>this happens when you execute: <ng0>. torsocks on; mutt ... try to send an email ...; . torsocks off (the off is optional, but this is basically my script <ng0>error happens before that. did not happen in gentoo build, so i'm looking first at torsocks and then at mutt <cvog>What is the best way to put general questions about GuixSD so that no answers will be lost? Is there a forum? May I use StackExchange (with a realistic probability for an answer)? <cvog>I never used IRC before, is there a possibility to scan the logged text by keywords etc? <bavier>but the search capability is minimal there <bavier>cvog: feel free to post general questions to help-guix@gnu.org mailing list <ng0>our mutt is broken: SENDMAIL="/usr/sbin/sendmail" is returned when mutt -v <ng0>I'll pick the fixes to this and more either now or tomorrow <ng0>when I can send mail to the list again you'll know it worked <ng0>also we should probably do symlinks for msmtp .. that's where my issue might be right now. <ng0>yep. the problem was msmtp does not get symlinked to sendmail and other binaries, while this was default on gentoo.. fixed muttrc to this ***erdic_ is now known as erdic
<efraim>sneek: later tell civodul in the end I disabled the libarchive part of the test and pushed that to core-updates ***the_ktosiek is now known as ktosiek
***pksadiq` is now known as pksadiq
<efraim>alezost: lightning needs a license prefix on gpl3+ <alezost>efraim: oh! silly me, I fixed it, but pushed the wrong patch, thanks! <sneek>Welcome back civodul, you have 1 message. <sneek>civodul, efraim says: in the end I disabled the libarchive part of the test and pushed that to core-updates ***ielectric is now known as domenkozar
<pksadiq>ng0: Oh, sorry. I was testing my internet ☺ <ng0>oh okay. I just block all cctp requests. <ng0>so it's not broken at your side, just blocked here :) <efraim>ng0: looks like i didn't send the email to you too, I pushed the perl package update <ng0>no, it's alright. the email arrived. <ng0>is it okay when I add a Guix: bla bla reason bla commit commit url to the original commit message of a patch series? that's what I asked about in the last email <efraim>I think lfam meant as an actual line in the top of the patch file <ng0>I can add lines over the Subject: of patches? <ng0>then I'll move it there <ng0>I heard that SSDs can speed up compilations compared to HDDs, but I'm not sure about this if it's really a significant decrease in compilation times. Does someone know more? <efraim>i think it mostly has to do with the reading and writing to /tmp <davexunit>it's impossible to build guix@0.10.0 because it will just build 0.10.0-0.e901 instead <civodul>you can always work around it with -e <civodul>the snapshot should be called "0.10.1-something" anyway <davexunit>civodul: the snapshot has that, but the official release does not. <davexunit>I want to use the 0.10.0 guix to build a new guix for purposes of bootstrapping new servers. <davexunit>the servers start with a 0.10.0 binary install, and I want them to upgrade to a newer version without having to compile. <davexunit>but part of me feels that there should be way to say "I want precisely version 0.10.0" <davexunit>could be as simple as checking if any package version matches exactly the version specified, in which case it is not ambiguous. <davexunit>not sure if that breaks anything else, though. <civodul>feel free to email your thoughts to bug-guix :-) <lfam>bavier: I didn't notice that --check doesn't work with grafts. Thanks for the warning <lfam>Have you noticed if it works as expected with --no-grafts? <bavier`>lfam: I haven't noticed, but I'd assume it works as expected in the case <civodul>bavier`: --check is not "useless" with grafts, but it checks the derivation that does the grafting <civodul>so in general you want "--no-grafts --check" <civodul>overall grafts in their current form do not provide a good user experience <civodul>i think it's the right approach though, but that we should find ways to eliminate/mitigate those annoyances <lfam>They are a superior user experience to rebuilding the whole system every time there is a bug discovered in some foundational C library ;) ***Kooda_ is now known as Kooda
<bavier`>what I meant by "useless" is "is doesn't do what I'd expect" <ng0>hm. torbrowser 6.0.2 out already <ng0>with the switch to the new firefox they got faster in fixing/releasing <ng0>using iceweasel as a temp. replacement is annoying. maybe I should try and get torbrowser going and post a wip to the list.. no idea who was working on it or if at all already <ng0>a "liberated" firefox could use torbrowser as a base or the other way around, depending on what comes first as a sideproduct <ng0>if there's anything non-free in firefox, it must be the default of google services etc <ng0>maybe some codecs too.. we'll see <bavier`>ng0: kyamashita and I were looking at tor-browser a little while back <bavier`>ng0: the open question was whether a torbrowser package from guix would leak identifying characteristics over the web <ng0>I have a little bit experience with the inofficial build on gentoo, but if I was not distracting myself I am working towards a guix with gnunet-fs, so this is more of a side thing, the torbrowser <bavier`>or if it would be sufficiently similar to the official version that it would not be a concern <bavier`>ng0: I didn't know there are other unofficial builds of torbrowser <ng0>well.. one can do what the inofficial build does, and be inofficial but replicate what the official gitian build does <ng0>see torbrowser-overlay <bavier`>ng0: ok, that gives me more confidence <ng0>we sync it into our gentoo overlay <ng0>with the big post-setup warning that this is not official, but replicates what official does <bavier`>I think guix's reproducibiility efforts and substitute challenges would be useful for torbrowser <ng0>torproject has been discussing on their trac about nix and guix, but so far have not considered it <ng0>but if we get somewhere, it would be a good point <ng0>risks are included, but risks exist to be pointed out and to encourage people to investigate them <ng0>i think by now using iceweasel is giving you a more unique fingerprint <ng0>without having compared 45.2.x and iceweasel, but i think it's likely <bavier`>we'd probably want to base a torbrowser package on top of icecat, if possible <ng0>iceweasel on debian 'unstable' switched to 45/esr a while ago <ng0>i don't think that's a good idea. <ng0>the firefox source needs to be exactly what torbrowser uses in gitian <ng0>so we can create a firefox labeled iceweasel if it is already 45.2.x, and torbrowser can inherit it. <ng0>this is the one which replicates gitian <ng0>on top of that I'd just create patches for the non-free components of firefox .. and we'll see if it makes the browser more unique in fingerprint or if there is no difference <bavier`>I'm assuming torproject has tests for such things already? <ng0>there's this fingerprinting service website.. can pass it to you in a moment, need to communicate something else <ng0>this website is continously tested and updated with new tests, as mentioned on one of the torproject lists. not associated with torprojected, but a good testing tool: https://panopticlick.eff.org/ <ng0>but iirc iceweasel is now firefox-esr in debian, as the last problems were solved already or something? <ng0>bavier`: judging by the licenses, this should be alright for guix.. or not? <ng0>i have some dislikes in new firefox, like helo, defaulting to google services(? do they still do that) etc, but that could be done locally through inherit. <sankey>how do i calculate the sha256 hash for a package which uses a download method of git-fetch? <ng0>git clone the thing, checkout the revision you want, rm -rf the .git dir, <ng0>guix hash -r therepodir <sankey>ah, guix hash can hash whole directories, not just files <wingo>would be nice to be able to hash a git dir without doing that <wingo>i.e. a hash of only the files in the git index <sankey>now i'm wondering how to calculate the hash of a tarball...do you guix hash before or after unarchiving? <ng0>guix download can do that <ng0>guix hash could just ignor .git, .svn and similar dirs once smeone doesthat <sankey>is there a reason guix download can't fetch git URIs supplemented with a commit/version? <ng0>possibly because it just uses a download so far and not added git/svn/etc <ng0>but in general firefox-esr still looks like it could be a long package, looking at the gentoo package and the guix package (of icecat) <efraim>I haven't looked too closely at writing a package for firefox, but I think the main thing is adding a phase changing the directory either before configure or before building <ng0>right, src_install() cd's into a directory. <ng0>prepare, configure, and everything above that is just very long. <ng0>there's maybe just the thing to solve where we could look at parabola.. the ethical decisions.. for example patching out google services etc should not alter the fingerprint <ng0>I think i want to start with this on the side.. and maybe it makes more sense to move all webbrowsers into webbrowser.scm or www-client.scm? <ng0>gnuzilla.scm for firefox is not fitting imo <ng0>wip will be in firefox.scm, i can move it around afterwards. <efraim>i've done some combining of packages <efraim>i bet we could also move w3m, links, lynx and dillo to webbrowser.scm <ng0>probably time could be saved by tracking gentoo or some other distros patches.. or starting off as a base for own patches. firefox bundles many things <ng0>or maybe not. but patches need to be included for sure. <ng0>yeah... i don't know if anyone of us wants to sign up at chromium.org for api key , and I see google as something we can leave out of firefox. the api key is needed for the location services in firefox. <efraim>also if we ever get around to packaging chromium we might also need our own API keys <ng0>yes.. but for now, and for just a wip, I won't touch google. <ng0>if it's indeed necessary, I'll find out that way. <ng0>I'm just writing down the how to, thread to follow. I think we can use browser/branding/official now.. if I am not wrong this is what debian does too <ng0>at least for gentoo it is: if use bindist; then (here come things related to branding/aurora) else (Here are things related to branding/official) . <rekado>flashing with libreboot didn’t work today. The experimental flasher didn’t quite work right. <civodul>rekado: oh you have a libreboot machine? <ng0>ACTION strikes the last questions. safety is a workaround of a branding which is not official. the trademark still applies to official branding and distribution of binaries containing such <ng0>wip is 300 lines now. I could've inherited icecat, but this needs to be extra, for keeping a version around where we can pin torbrowser to, and more up to date firefox' <wingo>i was about to carp about missing debug packages, but it turns out you can just install them :) <ng0>on debug... firefox with debug+debug-symbols: 8G. without: 4G. my decision is to build without, and I think it would be friendly to current hydra disk space. building with will be possible once there's enough space or another method to distribute (8G shouldn't be that much then, it's just the time needed to compile) <wingo>anyone able to get backtraces from core dumps? <wingo>i installed guile:debug, glibc:debug, and libgc:debug <civodul>"debug" outputs are broken by grafting, could be the reason <wingo>like, no symbols or unwind info in the backtrace <wingo>just no debugging information <wingo>numeric backtraces, no line numbers or file names <jlicht>civodul: really? How long has this been? <wingo>probably grafting then is the issue <civodul>and you have the right incantiations in ~/.gdbinit? <wingo>do i need incantations for a normal debugging session? <civodul>dunno i do get backtraces for what i do, but i know mark_weaver reported problems with grafts <wingo>this is with guile 2.0.11 from guix <wingo>yes i do have the .gdbinit incantation <wingo>seems it came from the skeleton when i made the user <jlicht>that might explain some issues I was having, but I just thought it was me not knowing what I was doing <wingo>maybe i just need to install more debugging packages <myglc2>I have Guix/Debian 8.3 installed. Can anyone comment re... 7.2.14 Running GuixSD in a Virtual Machine ... pros and cons of QEMU vs KVM? <civodul>in 'guix environment' it's inconvenient because you have to copy/paste the file name of the generated profile <civodul>it's easier if everything is in ~/.guix-profile <civodul>davexunit: another case for have GUIX_ENVIRONMENT=/path/to/profile ↑ :-) <wingo>civodul: weird, i have all of those :debug packages installed and though i can "gdb guile" and break on things, i can't debug a core dump <wingo>but, i can debug a core dump from running "guile" then doing a (raise SIGSEGV) at the REPL <wingo>i guess it's not a guix thing then fwiw :) <wingo>thank you for your patience :) <civodul>myglc2: KVM is a kernel module that QEMU uses, so no pros and cons :-) <anthk_>qemu doesn't have virgl in the current Guixsd build :p <ng0>if qemu just requires the lib, "it's probably easy" (famous last words). <myglc2>anthk_: Thanks. I'm not needing virgl right now ;)