<catern>so is there anyone working on removing the need for setuid stuff from guix? <catern>(guixsd that is - I mean things like sudo and su) <cehteh>i mean in some cases (containers, chroot) it is desireable to have no suid binaries <cehteh>but generally its not a so good idea, I think its good that user have to authenticate for/per administrative task they want to do <catern>eh? what do "authenticate per task" have to do with it? you could still require that in a no-suid world <catern>and you replace setuid stuff by IPC to privileged daemons <cehteh>what would be the benefits there? you move authetication away from the kernel to userland <catern>authentication is already in userland, what are you talking about... <catern>those are also already in userland <cehteh>when you want to access a file (or whatever) you dont have access to, then the kernel will block that <catern>when i execute a setuid binary, that setuid binary runs with root privileges, and then checks that I have permissions to do the action I requested <cehteh>so you want to replace sudo with some other sudo :D <catern>what does file access have to do with it? we're talking about setuid binaries, which run with full root: the kernel won't block anything they do, so if they have a bug, you're screwed (and setuid is prone to bugs) <catern>yes, a sudo that is based on IPC rather than setuid.. that's what I said <ng0>wow... your nicks are so similar that I just noticed that catern isn't engaged in one long monologue <ng0>I see emails from CoreOS and Archlinux to get inclusion on some linux-distro list at oss-sec / openwall.. do we already have that here? <cehteh>the guix daemon does that somewhat, respond to user requests <cehteh>but generally, i dont the too much benefit in just another way to do it (new code has new bugs) <catern>setuid is a bug in the design of Unix - deleting it is a great benefit <catern>and of course it makes it so much easier to use various namespacing tricks like containers and chroot as you mentioned <catern>when you don't have setuid stuff lying around and ruining your day <cehteh>i somewhat agree, imo it would be more clever to have a group for each administrative task and let users authenticate against that, switching group and done <cehteh>but i dont like the idea about some extra daemon/ipc doing that on the users behalf (and how does that daemon give the user a privileged shell?) <cehteh>first get full access by suid root and then drop unneccesary privs is a bad idea, totally agreeable <catern>using some group-based thingy like you described, that's just policy, people can have whatever policy they want, that's not super relevant <catern>the same way sshd gives you a privileged shell <cehteh>i mean you can always ssh to localhost <ijp>tlns like me suffer from this bigotry constantly <cehteh>actually it might be a nice idea to have the sshd listen on a local socket too *thinking* .. <catern>sudo/su look at fixed paths in the filesystem to determine who is privileged, which is rather problematic when those fixed paths can be changed to point at anything you want by unprivileged users <catern>but the only reason it is dangerous that sudo/su look at fixed paths, is that sudo and su and other setuid binaries can actually give people greater than normal privileges <cehteh>when a unprivileged user can change anything he should not change then its always problematic <cehteh>you only shift the problems, not fix them <cehteh>in esscence you want the kernel to be your firewall to enforce permissions and access at the end .. and you have to trust the kernel <catern>there's no fundamental reason why namespaces, chroots and so on shouldn't be accessible to unprivileged users <catern>one of the big obstacles (the main one, afaik?) in present reality, however, is the existence of setuid binaries <cehteh>there are some other historic reasons <catern>since setuid binaries are a vector for privesc once you give an unprivileged user access to chroot <ng0>apteryx: this is super confusing <ng0>it would be like me talking to gn0 or what their name was <ng0>in UTC timezone, it's still capslockday ;D <catern>anyway, the existence of setuid binaries is IMO *the* main thing holding us back from the ~glorious unprivileged namespaces future~ <catern>what did you mean, other historic reasons why chroot is not unpriv'd? <CEHTEH>catern: i'd like the idea to have user defineable chroots and namespaces etc ... but one should think *very* carefully about its implications, i bet there are some people already found and thats the reason why it isnt *that* easy to do <CEHTEH>me thinks some of this privileges should be non recursive, as soon a user chroots, he cant chroot again inside this chroot for example <catern>I mean the main gotcha is the setuid issue, there's not much else <CEHTEH>setuid is a old hack, but its understood and proven to work somewhat <catern>(besides kernel vulnerabilities...) <catern>lol, proven to work? it's a major source of security bugs <CEHTEH>anything new may have new ways to exploit it <catern>sshd is already exposed to a hostile network <CEHTEH>the principle is well understood, security bugs are bugs on the implementation side <CEHTEH>but starting something new where the principle isnt even well understood/defined might be far more worse <catern>and at a fundamental level, "send an arbitrary message over IPC" is a far smaller attack surface than "run a process in an arbitrary environment you control" (which are the attack surfaces of sshd and sudo respectively) <CEHTEH>what happens when a user can recursively chroot like a fork-bomb? how would you prevent that? should that be done in kernel (imo yes), userland policies should be only soft <catern>sure, resource controls can all be handled in some way - a new ulimit or something <catern>this is separate from the issue of killing off setuid though <CEHTEH>but good call .. in guix it should be possible for a user to install malicious suid binaries if he has access to any of the substitute servers (which may be local as well) <CEHTEH>(maybe guix should disallow any suid binary in user installable software, these have to be installed on the system stanza) <cehteh>anyways, what you propose would be nice, but imo it needs some kernel facilities which are not there yet <catern>please be more specific: are you talking about removing setuid binaries, or allowing unprivileged chroot? <catern>(I have some ideas about the latter, but first we need to do the former, which shouldn't need kernel support) <cehteh>i dont see much difference in a daemon handling the privileged tasks and a suid binary, attack vectors only shift <cehteh>ideally a user should autenticate per facility (with groups or whatever) to get the requested privilege, and only that without a stopgap over a suid binary or anyting else <cehteh>when you do some IPC daemon then you have all the problems about IPC handling, buffer overflows, illegal messages, wrong/tampered config files .. and whatever the daemon does is not under the users session/ssid, not conntected to the users terminal (you need some more turnarounds) etc <catern>however, we already solve all of that with openssh... <catern>and I already described the major difference between a setuid binary and a daemon: a setuid runs in an environment that the user controls, a daemon runs in a fixed environment and can only be communicated with by messaging <taylan>apteryx: it's not really usable for day to day usage yet <sneek>taylan, you have 2 messages. <sneek>taylan, janneke says: thanks i'll play a bit more and try to come with a concrete example of what i encounter. it's in this bit: "all it does is that the unsyntax'd form is evaluated normally rather than as literal syntax. this means that e.g. further (syntax ...) forms within it will just become syntax." <sneek>taylan, janneke says: any later forms "further (syntax ..) just become syntax"...that's where it gets me recursing/confused <apteryx>taylan: Ok. I saw I had to do some guix environment command to be able to launch it without a "load-thunk-from-memory "~A" error. Is it possible to configure the guile-emacs package so that it always launches in this environment? <apteryx>Is this an error in the manual or am I reading wrong, in section 4.2.5.1 Guile and Build Options: `guix-use-substitutes' Has the same meaning as `--no-substitutes' option. <apteryx>Or maybe it's true the meaning is shared, even one is the complement of the other... <iyzsong>apteryx: yeah, I think the manual is wrong. "If non-nil, use substitutes for the Guix packages." is what the code (emacs/guix-base.el) says. <apteryx>OK. Maybe it should say: "Has the opposite effect to `--no-substitute' option. <apteryx>not sure my choice of preposition is OK, I'm not a native English speaker ;) <iyzsong>I'm not too. How about 'If nil, has the same ...'? <orly_owl>oh im in here already. so what makes guix better than trisquel or parabola? <apteryx>orly_owl: I haven't tried any of the others, but let me try an answer: the package manager? <apteryx>guix itself is the transactional package manager (which you could install or any GNU/Linux distro). <apteryx>But by using GuixSD it is well integrated for you. <reepca>orly_owl: I can switch to a completely new system and as long as I still have my config.scm and a list of packages my user has installed, I can use the system exactly as I did the old one. All it takes is a guix system init. One of the guixsd installs I had on a flash drives died in the line of duty. So I plugged it into my desktop, reformatted and re-ran guix system init, and got up and running again. <reepca>s/drives/drive, shouldn't be plural there <hawkwind>When doing encrypted root on this do I need a separate /boot? <apteryx>hawkwind: From experience; full disk encryption including the /boot partition is possible with modern GRUB, as long as your grub is configured to use the crypto module. <apteryx>This experience was gained on Ubuntu rather than GuixSD, but I don't see why it wouldn't hold true. <apteryx>Also, you might be annoyed by having to enter your passphrase twice rather than once. The first time it's requested by GRUB, and the second time by the main system. <apteryx>hawkwind: Oh, also there is some setup to do with crypttabs or something like that. <apteryx>It was new to me. You have to provide the UUID of the disk in there else GRUB won't find it. It's like an equivalent of fstab for encrypted drives. Not sure of the details though. <apteryx>Google /etc/crypttab or something like that. <jmd>Where do I find the code which parses the /etc/config.scm file? <reepca>jmd: when you say "parses", do you mean the code that *uses* it (as in guix system reconfigure, etc) or the code that actually looks through the text and assigns meaning to it? I'm not sure where the code that does the former is, but guile does the latter I'm pretty sure <jmd>reepca: Is there any way to do any pre-processing/sanity checking on it? <reepca>could you explain what you mean by that? Is guile not parsing it correctly, or not handling errors well? <reepca>How not-well is it handling it? Silently ignoring, crash and traceback, kernel panic...? <reepca>Which sort of error is it silently ignoring? <jmd>So far as I can tell every sort. I mean one can put rediculous values in and it won't complain. <reepca>Like... (bootloader '(potato "fries" -100000))? <jmd>Or like (mount-point ".") <jmd>Or (host-name "-99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999") <jmd>(which the kernel wouldn't accept) <reepca>When is it not complaining about it? Have you tried doing a guix system reconfigure with the bad values? <reepca>What does it do to the host-name in that case? Just leave it the same, truncate all of the 9s, or what? <jmd>It leaves it the same. <reepca>Hm, the reconfigure should probably fail if something in config.scm can't be applied. <reepca>well, I've got a git checkout, let me just quickly do a grep for reconfigure <jmd>Done that. Its in guix/scripts <jmd>Doesn't help though. <marusich>What is the issue? I joined partway through. <jmd>marusich: I'm trying to catch errors in /etc/config.scm earlier. <jmd>(and possibly do some pre-processing on the fields). <reepca>the code that should be giving errors if the kernel doesn't accept the settings should be in switch-to-system, I would think <marusich>Ah, I see. Yes, that would be nice. Perhaps you already know, but just in case you don't: the <operating-system> record type is defined using the define-record-type* syntax, which itself is defined in (guix records). Perhaps you can play with that and figure out a way to add validation? <marusich>jmd, many record types in Guix are defined using that syntax, so if you could figure out a way to add validation into it, you could probably take advantage of it anywhere we define records. <jmd>Right. I'm wondering if this "thunked" attribute could be used for that purpose. <marusich>I don't know a lot about the syntax, but I imagine that maybe you could make it so that you could add a validation procedure or something for the record being defined, and then for each record, if you wanted, you could add that to do validation <marusich>Additionally, if there is something you can catch at macro-expansion time, you could use syntax-error as described in (guile) Syntax Rules <marusich>It would be nice to have better error messages, for sure. I find Guile's error messages and stack traces to be rather cryptic. <reepca>Some additional grepping leads me to believe that the actual setting of the system's hostname is done by the guix daemon, which I think currently uses nix's implementation. In which case it's not properly communicating to the client that something failed. I could be wrong about that, though. <reepca>I'll think about it more tomorrow maybe <reepca>you'd probably have better luck with someone more familiar with guix <jmd>I don't think the daemon has anything to do with it. <GNUtoo-irssi>hi, I've some guix errors (/gnu/store/<hash>-build-utils.scm: No sufh file or directory), in what order should I run theses commands: <alezost>GNUtoo-irssi: you shouldn't run "guix refresh" at all <alezost>yes, and then you can update all the packages in your profile with "guix package -u" <GNUtoo-irssi>Hopefully this time I will get it working again, I'm struggling to make it work since months, but given how exiting guix is, I don't give up that easily <amz3>where should I put link-grammar (LG) software in the package repository. «LG is a syntactic parser of English. Given a sentence, the system assigns to it a syntactic structure, which consists of a set of labelled links connecting pairs of words» <amz3>it's a natural language processing (NLP) software written in C <efraim>ng0: I'm working on applying the psyclpc, but the hash from git-download changes each time I tell it to build <ng0>you use the current patch of it? <ng0>wasn't it the case that the tarball includes a .git? <ng0>i'll try to build some rounds see if I can reproduce it <ng0>it would be troubling if this really happens <ng0>i have a branch from september 21th.. i think the october one must be gnunet.org already <ng0>the patch from oct 4th, or the email? <ng0>the problem of keeping too many branches <ng0>i'll go with what I have on gnunet.org guix <ng0>i assume you meant email from oct 4th <ng0>"guix build: error: build failed: some outputs of `/gnu/store/86pnwpgvbzlk89khs9csp40amj18s88a-psyclpc-20160821-1.8bd51f2.drv' are not valid, so checking is not possible" <ng0>ok, will take some more moments <ng0>cursed garbage clean <ng0>do you know where I could start with looking into why it is not deterministic? <ng0>this is a new field for me.. so far I was lucky not to notice because gentoo has a different build environment <ng0>gentoo being the quasi-official distribution for all things psyced.org <marusich>Hey, has anyone here ever been able to run "make -j check-system" successfully? It seems like no matter what commit I try, it never works for me... <efraim>we "recently" got a new hash thingy for git/svn/etc repos, maybe that has something to do with it <efraim>I think the best way would be to download it manually and check the old way <efraim>marusich: which test(s) are failing? <marusich>efraim, so, most of the time a few of them fail and I suppose I could investigate. I'm just curious to know if anyone has ever seen all the tests pass.\\ <efraim>i've only ever run make test on my aarch64 board which has other issues with the guix repo, so i've never actually seen them all pass <efraim>although I assume they must pass, we run the tests when building guix <marusich>efraim, most recently, however, I get an error about a hash mismatch during substitution: "@ substituter-failed /gnu/store/281c08mmhjx3ijf84yga8sll3iqzsc38-module-import-compiled 0 hash mismatch in downloaded path `/gnu/store/281c08mmhjx3ijf84yga8sll3iqzsc38-module-import-compiled': expected 6bdd1e15d6c70607b65a897ddc4cc0184922ab0065abc68f745d8dfcc35168e4, got 89d7db7656788f125d79c81aeb4466a12581f713607e6d1e2e77e8c130aa95b5" <marusich>When this hash mismatch occurs, all the tests fail, presumably because we couldn't even start <marusich>efraim, well, this mismatch happens consistently for me right now <ng0>efraim: i'll check and send a new patchseries in a new thread with changes. <marusich>I don't recall this happening before. I have gone from previously being able to pass some tests (but not all), to not even being able to run check-system at all. <marusich>But never have I seen all the tests pass. <marusich>So, I was just curious to know if anyone has ever seen them all pass. <ng0>thanks for merging the vim-full :) and regarding vim for guix, i think a guix vimscript might be the better idea, maintained outside of guix source so that other distributions can install it system-wide. <efraim>ng0: I cloned the repo twice, got a different hash for psyclpc and psyclpc2 <ng0>the others were okay? <ng0>i perlpsyc and libpsyc <efraim>yeah, i have them merged locally <efraim>seems to me either theres something fishy going on during the download, or the files are being downloaded in a different order each time or something <ng0>i wanted to move this laptop today to what the others have where guix runs in a qemu, but i guess this has priority now for some hours :) <ng0>but how.. this is git right? <efraim>I get the same hash when I recheck a repo, but different hashes when I check it against other fresh clones <ng0>i'll rebase my way up to psyclpc now <efraim>maybe something changes an "accessed on" datestamp <ng0>i hope you did not discover someone managed to break the server <efraim>it seems less likely than something configured wonky <ng0>there's a hidden-service in case you want to test checkouts from there <ng0>i think there is one.. i'm not 100% sure if they are also served there <efraim>I can always try torify git clone <efraim>ls -la on the repo shows the time I cloned it <ng0>i also discovered some license mistakes I made, so it's good they were not merged yet <ng0>or maybe just one on psyced itself <ng0>efraim: i think i'll ask lynX to make a new release. A removal of the historic pcre is enough for a new release imo <efraim>tarballs are always easier for packaging :) <ng0>I just made 9 checkouts, all the same hash with guix hash -x -r <ng0>anyway, I asked to make a new release tarball. <ng0>i still want to figure out why you get different hashes and for me they are all the same <efraim>I ran guix hash -r gitcheckout , forgot about the -x <ng0>well, I changed the header, and for psyclpc I'll wait for a new tarball now <ng0>then I'll send in a new patchseries <efraim>ok, now I'm getting the same hash for each checkout, when I add the -x <ng0>i have no shell access to psyced.org, so I can't just create a new release. <ng0>efraim: but I still got 'might not be deterministic' when I build psyclpc here with --no-grafts --check <ng0>and it's in our (not guix) interest to fix this <ng0>non-determinism is introduced by timestamps and stuff like that, correct? <ng0>it would be useful when the message --check gives could point to some files / lines to blame <efraim>not sure how to make the download have the right hash though <ng0>maybe it's not deterministic because of some application in the dependency graph or gcc itself? <ng0>i think we should also remove "-02" from the arguments to builkd <ng0>or is this a guix default? <ng0>i haven't looked at psyclpc in a while <ng0>like someone recently requested for secushare: we should have a public bugtracker.. psyced used to have one years ago i think. <ng0>i see no timestamp issues in the builds. so it must be somewhere else <thomassgn>Hey, using the bare-bones.scm for getting my machine started, but keep getting "/mnt/etc/config.scm:8:0: In procedure module-lookup: Unbound variable: Filesystem" <thomassgn>can't see "Filesystem" anywhere in the file, but there is both "file-systems" and "file-system"... Any tips? <ng0>it should be file-system <ng0>can you paste your config somewhere online? <thomassgn>I could, how would I start ssh without config? <ng0>oh, you just have it in the install. <ng0>do you have curl availabe there? <ng0>which parts did you change, and how do they look now? <ng0>guix install image should have wgetpaste <ng0>i mean it should, right now it doesn't <ng0>or some way to paste in case of emergency <thomassgn>haha, yes, agreed. I couldn't find wgetpaste in the list of available packages either... <efraim>ng0: I don't see a commit starting with 8bd in 'git clone git://git.psyced.org/git/psyclpc' <ng0>that's because we have npo wgetpaste here.. i packaged a C application which is an interface to pb based pastebins, but it is experiencing curl problems <ng0>this should be correct <ng0>commit 8bd51f2a4847860ba8b82dc79348ab37d516011e <ng0>Author: psyc://loupsycedyglgamf.onion/~lynX <BM-NB7xa9gEpmJgYp9PVnEdACiZcGmmEJcY> <ng0>Date: Wed Aug 10 15:44:53 2016 +0000 <ng0> removed historic pcre bundling <ng0>sorry lynX, if you pasively read this <efraim>the last one I see is 27f21a3bf0d140f0d2680c695e8df229b46a814b <efraim>git://git.psyced.org/git/psyclpc <ng0>i did 10 new checkouts and they all end at this <ng0>those are the public accessible commits <efraim>woah, I ran torify git clone ... and now I see the last commit <ng0>wgetpaste depends (obviously) on wget, pbpst on curl. I think one of them could be useful to have in the base image <thomassgn>ng0: Haha, sorry. I had grep'd the UUID from tune2fs into the config so I didn't have to type it. But I forgot to remove the line from bottom of the file... Thanks though :) <ng0>standard firefox (not icecat) now greets you with "create a firefox account" on first start... yikes <ng0>this is build with skia, something which might replace cairo dependency in the future <efraim>ng0: i'm going to have to come back to the hash thing later <ng0>ok, thanks so far :) <ng0>i think i forgot tun/tap in the kernel or something in qemu why it's not working <efraim>wgetpaste looks like its public-domain, so it should be fine <efraim>i can't image it would have a very large closure <ng0>we do already have wget in the image, right? <ng0>curl would have to be added <ng0>equery g wgetpaste just gave me "wget" <ng0>i tried to package this i think but it needs to be patched. <efraim>i don't think we have wget or curl in the install image <ng0>marusich: thanks. i'll try first adding tun/tap to my kernel, i forgot that <marusich>FWIW, I use "-net user -net nic,model=virtio" and it works fine for me - I can connect to the Internet from my guests. <ng0>qemu 2.7.0-r4 says : -net default: invalid parameter "default" <marusich>I don't use that one; I'm not sure what that would do. <marusich>I launch my VMs with a command like the following, and it works well enough as far as I can tell: "sudo qemu-system-x86_64 -smp cpus=2 -net user -net nic,model=virtio -enable-kvm -m 4096 /path/to/disk/image" <marusich>I'm sure there are a million other ways to do it. <marusich>It's a bit confusing with all the options; you kind of have to read the manual closely to figure out what to do. <ng0>i'm giving this now a first run to see wether i'll move my mobile guixsd installations into a qemu untill i have everything i want <ng0>mostly: uclibc-ng and a hardened system <ng0>my personal dream, a system which goes towards a reproducible, down to bootstrap, hardened, uclibc-ng.. then I can leave gentoo and only use gentoo for package maintenance <firt-try-unable->Hello :-) I've follwowed the manual to download the *.xz archive, unzip it and use dd to put it on a USB drive but unfortunately it's not recognised at boot time -- any idea why? <marusich>When you say it's not recognized, do you mean you are not able to boot from the USB? <marusich>Or, do you mean that you were able to boot from the USB drive, but a problem occurred after that? <marusich>Do you know how to set the boot order for your computer? <marusich>You might need to change your boot order so that you can boot from the USB drive. Not all computers will boot from a USB drive by default. <firt-try-unable->Yeah I know how to do this but usually I prefer to override it manually (I press ESC on boot time and the Bios asks me what I want to boot) <ng0>depending on the bios, there's a key/key-combo to press to select the usb drive <marusich>If your computer uses BIOS, there is usually a way to access the BIOS menu by pressing some magic key like F8 while it's booting. <marusich>Are you able to select the USB drive from the BIOS menu for booting? <firt-try-unable->Basically I did a test and put Ubuntu Live on a stick: I'm currently writing for a live Ubuntu stick <ng0>is your hardware x86_64/amd64 or x86? <ng0>and you chose the correct (x86_64-linux) guixsd medium? <firt-try-unable->Nope, I'm not able to select the guix USB drive from my boot menu but I can choose the Ubuntu USB drive <marusich>Strange. Here's a random thought: perhaps your BIOS cares about whether or not the boot flag is set for the partition on the USB drive. Maybe if you set it with a tool like GNU parted, your BIOS will let you boot from it? <marusich>I'm not sure if the image has that flag set or not by default. <roptat>could it be related to secure boot? <firt-try-unable->I downloaded it, then used dd to put it on the stick. I just used two paremeters for dd: if and of. Perhaps I should also say it something about bs? <firt-try-unable->I've just had a look on the Guix usb stick with Gparted, it appears to only contain 13 MB of unknown data. Do you think it's correct? <marusich>And as far as I know, the defalut block size for dd should work fine; the instructions in the manual do not specify bs. <ng0>could be my system, but "herd start cow-store /mnt" just failed to start in the kvm machine <ng0>herd: exception caught while executing 'start' on service 'cow-service': <ng0>ERROR: In procedure mount "/.rw-store" on "/gnu/store": Invalid argument <ng0>second try it worked <ng0>fuse: bad mount point '/.rw-store": No such file or directory <firt-try-unable->I've downloaded the file again, checked its signature. I'm putting it on my USB drive, then I'll check the boot flag and try a reboot. I let you know whether my problem is solved. Thanks for your help :-) <firt-try-unable->gosh I've just had an I/O error from dd so it aborted. Maybe it happened the first time and I didn't notice >< <apteryx>firt-try-unable-: How did you create the USB installer? The best way would be to use dd, with somethinglike: sudo dd if=your_guix_image.iso bs=4M of=/dev/sdX; sync <apteryx>Where sdX is the USB device you'd like to write the GuixSD image to. <amz3>ACTION sent a patch for link-grammar <apteryx>firt-try-unable-: Hmm. Are you sure your flash drive is healthy? <apteryx>Might want to try another one just to see if the I/O errors go away. <apteryx>bs=4M would just speed things a bit. <ng0>qemu kvm guixsd experiment builds now.. downloads at the speed of funeral-doom sloths, but it works. <ng0>speed is because of kernel limitations etc <Petter>Ok, tried to express joy of "funeral-doom sloths", managed to exit the channel instead :/ <Petter>Anyway, funeral-doom sloths made me laugh :) <apteryx>Petter: Preferable than copy pasting the universe in the channel ;) <ng0>apteryx: if you use weechat, there is a setting which asks you before pasting more than 1 line <ng0>"do you really want to paste 4000 lines? Y / N" <apteryx>ng0: I guess I'll have to look into it! Thanks for the suggestion! <apteryx>Or there might just be an option in irssi I'm not aware of. <Petter>By the way, Random Agent Spoofer has a setting "Disable canvas support". Checking this made a huge difference with panopticlick. Hash of canvas fingerprint (undetermined) is now 1 in 32.9 browsers. <apteryx>Petter: Wow, that's great! Canvas fingerprint was the biggest in the list. <apteryx>What is the use of the canvas? Is it impacting your web-surfing experience so far? <Petter>No impact so far. My brief web search suggests it's for drawing in the browser. <ng0>Petter: what's the internal firefox config setting for it? is it named clearly (includes canvas)? <Petter>extensions.agentSpoof.canvas user set boolean true <ng0>default firefox has canvas: one in 164606.0 <ng0>well, 49.0 gentoo build with no system-* ones <apteryx>Petter: Where do we download this add-on again? I can't find it on the default IceCat extensions page. <Petter>I think you need to go to the firefox addons page. <ng0>i'm not sure if the windows agent is ok... <ng0>i just compared almost default firefox + torbrowser <ng0>ff 49.0 gives a linux string, for panopticlick this results in "one in 120.77", for torbrowser with lowest tor settings it results in: one in 15.96... <ng0>but tb results in more.. so that's better <apteryx>You mean 1 in 15.96 is better than 1 in 120.77, so it justifies keeping the Windows UA? <ng0>when you take panopticlick as a base, yes <apteryx>I'm still unique, probably because of the System Fonts. <apteryx>But 1 in 5677.48 (system fonts) is better than single in the whole database (canvas size) <ng0>does the hash matter? torbrowser sets one of the hashes just to all 0 <Petter>Random Agent Spoofer has a setting for that as well. "Limit detectable fonts". <apteryx>ng0: Random Agent Spoofer does the same (all zeros for the WebGL hash) <Petter>Takes System Fonts down to 1 in 14. <ng0>i think the hash value is something we could apply for icecat in guix? <ng0>it seems like something which will not get upstreamed from tb to ff <apteryx>Went down to 1 in 13.97 for the system fonts. Still unique with the same amount of information though (17.33 bits). <apteryx>Against even when bringing down one category to less than 1/20, together they add up... <Petter>Yeah, it's more to it than decreasing each characteristic as much as possible. The combination of these is important. <apteryx>Seems like privacy is broken beyond repair in browsers. <ng0>USERAGENT="COMPUTA" fixed. <ng0>apteryx: if you use https-everywhere, I can recommend "certificate patrol" in combination with that <ng0>should still be in mozilla store, but the devs no longer use that for distribution, there's a website for that <apteryx>ng0: How does that work? Adds another root of trust? <ng0>i hjaven't found any similar add-on so far <apteryx>Gosh, this Ctrl-click == kill window behavior of ratpoison is surprising me everytime. I guess I really should banish the rat. <Petter>"Your connection is not secure. The owner of patrol.psyced.org has configured their website improperly." <ng0>there's git:// for it, and there's also an onion <ng0>the infrastructure is stupid <Petter>A little funny that a page for certificate patrol doesn't have https. <ng0>reasoning for new certificates didn't work. <ng0>i think the onion does not cover patrol.p.o <ng0>apteryx: i've asked for extending the wildcard onion to include patrol.p.o <ng0>hm.. is weechat 1.6 already out or is this a developer preview? <ng0>I'll update it for guix then <ng0> python: add detection of Python 3.5 <ng0>what was our python patch about? <ng0>and why does our weechat build with python-2? <ng0>dynamically link against python2.7 <ng0>i just version update it now <first-try-unable>hi back! I've been trying to create a bootable guixsd USB drive but despite of some tries it jsut doesn't show up in the boot menu <apteryx>It could be just an unamed entry in your boot menu: like 3: <first-try-unable>I'm currently using USB drive with Ubuntu 16.10. I've tried several USB drives for guixsd, including some I booted Ubuntu with, so in my humble opinion it's not hardware but I'm missing something obvious in the software part. <first-try-unable>apteryx: thanks for your reply :-) no, actually I just have items from hard drives (or Ubuntu drive when I plug one), never an item for guixsd <ng0>first-try-unable: if all breaks, install debian and do a system init in there <ng0>that's not the nicest solution but should work <ng0>if your intention is only guixsd and no multibooting <ng0>*goal, not intention <first-try-unable>well, yes you're right it could work, but I would prefer to know what I'm missing out >< how did you do to get a working USB drive? <ng0>but i also know someone who was never able to produce a bootable usb drive <ng0>and it was part of some hardware issues <ng0>only drives other people made for them worked <apteryx>first-try-unable: strange. Which iso image did you use? Does in work inside a virtual machine such as QEMU? <ng0>apteryx: there's no iso image.. don't confuse people :) <ng0>it's just a raw qemu image <apteryx>ng0: If he uses dd I don't see how it wouldn't create a bootable iso, since the machinery is bundled inside the iso. <apteryx>I thought it was a hybrid iso or whatever they call it. <ng0>i have no idea what exactly it is because i have not looked at the code yet. but it can happen that the usb drive does not boot, unrelated to the guixsd image <apteryx>ng0: Just checked what's available for download and you are right, it's an xz compressed raw image. <first-try-unable>I've tried to create bootable drive with two computers: Apple macbook pro and Asus. The target computer is Asus. <apteryx>first-try-unable: I'll reboot to see how the bootable key is listed. <apteryx>first-try-unable: So when I pressed F12 I could pop up the boot menu, in which I had to choose USB Storage or something similar. <apteryx>There was like 4 items in this Boot From popup: 1) Hard drive 2) USB Storage 3) Network 4) I forgot <apteryx>I guess you could also try another approach: extract the raw image content to a physical partition from your working install; then chroot into it; and re-install grub from there <first-try-unable>I'll try again, but as I've changed nothing, I'm unsure what could change. <apteryx>(where working install can also be a live Ubuntu session booted from your usb stick!) <ng0>totes not recommended: sloth-speed qemu install <ng0>it arrived at grafting now for the system <first-try-unable>It appears it's not currently possible for me to get a bootable Guixsd drive :/ <first-try-unable>I've tried different host computer to write (dd) the raw image on the drive: Asus laptop with live Ubuntu, MacOS, Windows/Debian (in a VM) <apteryx>Does the USB drive with GuixSD installer boots inside your VM? <apteryx>Have you tried verifying the integrity of the downloaded file? <apteryx>Might want to redownload it & re-extract it again, to be sure. <first-try-unable>Yes I verified the integrity of the file. It appears to be OK but there is a warning on the signature itself (not that crucial for me I think) <apteryx>ok. If the md5 hash matches, that should be good enough. <apteryx>And which dd command line are you using exactly? <first-try-unable>First I do xz -d [what I DLed] then dd if=[what's extracted] of=/dev/sd[my USB drive] <thomassgn>is there some way of defining build jobs? or parallell cores or similar? <ng0>is there something I should change when installing guixsd in qemu? it failed for grub <apteryx>thomassgn: it's doing 1 build at a time, using as many cores as you have by default, see info guix Invoking guix-daemon <ng0>i forgot to change sdX to sda <ng0>i hope the data is saved and the 2 hours installing do not need to be repeated :D <suitsmeveryfine>Hi! Earlier today I discovered that I had just 4 MB free space on my root partition. I then ran the garbage collection command which freed ca 10 GiB. Now, for some reason, guile is not to be found and I'm unable to run guix package anything. <ng0>hm.. this could be related to the grafting bug..? <ng0>I can't find the bug which I wanted to reference <ng0>but yes, open a bug with as much information as possible.. this should not happen <ng0>mark reported something <ng0>sorry, christopher i meant <ng0>if no one else can help, i can't at the moment, there's always rollback <ng0>but you can wait for someone to actually help :) <apteryx>suitsmeveryfine: From what I've read, this could happen if you ran "guix package -r guix" at some point <apteryx>But I guess guix is smart enough that it would warn you that many things depend on guile? <ng0>is only guix package broken for you or ALL of guix <ng0>to stress out "guix package" not guix as a package <ng0>try guix build hello <apteryx>suitsmeveryfine: OK. This should be fine. <apteryx>Can we --rollback after running the garbage collector? I guess so. <apteryx>suitsmeveryfine: guix package --roll-back <apteryx>It's not specific to a package but to the global state of your system before your last change. <apteryx>you can also inspect the record of changes (generations) using "guix package --list-generations" <apteryx>You should verify if the garbage collection created a new generation which you can undo. <ng0>is the new python build system merged yet? <ng0>or is it doing a test build of all of python.scm right now? <suitsmeveryfine>I can't run guix package --list-generations because guile does not exist <ng0>like i said, is it only the subcommand package? <ng0>have you tried building hello? <ng0>guix build --no-grafts -K hello <apteryx>ng0 I would expect that to fail as well if guile got removed from his system -- guix depend on it. <ng0>expect is not running <apteryx>How did you select a previous generation if guix package was not able to run? <suitsmeveryfine>ng0: running `guix build --no-grafts -K hello` outputs the same error message <suitsmeveryfine>apteryx: I just selected a different kernel from GRUB (after a reboot) <apteryx>The process must have been in memory still. <suitsmeveryfine>no, I realize that I must have run guix --help not from the git checkout <suitsmeveryfine>I didn't say it before but I've reconfigured and used my Guix SD system from a git checkout and run every command prefixed by ./pre-inst-env <apteryx>Not sure how to understand "reconfigured and used my Guix SD system from a git checkout". <suitsmeveryfine>Another interesting thing: just running guile from the terminal gives me this: <suitsmeveryfine>apteryx: after the Guix SD install I cloned the git repo and then "ran guix system reconfigure" from there <apteryx>suitsmeveryfine: OK! I've never attempted this yet. Thanks for explaining. <ng0>suitsmeveryfine: please explain exactly what you did. <ng0>I run my system fro mgit checkout without issues <ng0>and i have already run garbage collect with it <ng0>and it's still working <ng0>this is not exactly. I meant, which commands etc <ng0>have you symlinked the git checkout? <ng0>it's described in the documentation <ng0>obviously if yoiu haven't, you can only run guix command in the guix.git checkout <ng0>then there's something i can't help with <suitsmeveryfine>ng0: I understand. It doesn't matter because I have not problem with reinstalling this machine <suitsmeveryfine>I came here mostly to report my findings, but it it's better to send a bug report by email <thomassgn>huh, I see the computer installing is mostly, or only, building from source... <jmd>thomassgn: Maybe you have no substitutes <Common_Era>Do people still want me to send my Mac EFI instructions to guix-devel? <thomassgn>I see my DNS setup isn't working properly (I can ping 8.8.8.8 but not gnu.org (unknown host)). Though it does get sources and so on... <apteryx>thomassgn: I also had this problem when using the lightweight-desktop.scm file <apteryx>I had to instruct wicd to use static DNS and set those to the ones given by my ISP. <apteryx>Before that /etc/resolv.conf was empty, now wicd populates it. I'm not sure why it doesn't work automatically. <apteryx>(I wonder what Ubuntu/network manager does, for example, so that it can resolve DNS without having the user give any information whatsoever) <wingo>this locales thing is such a mess <wingo>every time i upgrade glibc things break <wingo>old builds that used the previous glibc no longer find their locales <thomassgn>apteryx: ah I see. My resolv actually has a nameserver, but I get 'unknown host' both with the one from dhclient and when I add 8.8.8.8 ***contrapumpkin is now known as copumpkin
<apteryx>oops. Was trying to find ng0. Sorry nekomune! ***jje- is now known as jje