<civodul>you could replace config.guess and config.sub with new ones from automake
<roelj>I'm trying to build the bootstrap binaries with "guix build bootstrap-tarballs", but it fails to do so: guix build: error: build failed: derivation '/hpc/gnu-store/...-guile-bootstrap-2.0.drv' has incorrect output '/hpc/gnu-store/...-guile-bootstrap-2.0', should be '/hpc/gnu-store/...-guile-bootstrap-2.0'. All having different hashes. The store only contains ...-guile-bootstrap-2.0.drv and a .drv.lock file.
<mark_weaver>civodul: my usual method to delete bad nginx cache items is to run "ls -lS /var/cache/nginx/nar/*/*" and find the entries that have a size only slightly larger than the result of "wget <URL>". the cached item includes the HTTP headers, which is why its bigger. you can then 'less' the binary file and see the nar URL in there, to confirmation. then just delete it.
<kristofer>I reconfigured my system for a third time, spent all day waiting on it to compile only to find out that my kernel version is older yet again. I started 3 days ago with kernel 4.4.1, did a reconfigure and wound up with kernel 4.3.3, did a system reconfigure again last night after updating guix to the latest guix from git, now I'm at kernel version 4.2.6
<kristofer>why does the kernel get older everytime I system reconfigure?
<mark_weaver>kristofer: if you don't run "guix pull" (or equivalent) as root, yes.
<kristofer>I have guix src from git in /home/kristofer/src/guix and it's symlinked to both /root/.config/guix/latest and /home/kristofer/.config/lateset
<mark_weaver>(and btw, running "guix pull" as root only affects the version of guix for root; it also needs to be run as your normal user as well, to update the version of guix for that user)
<mark_weaver>oh, well, in that case, this shouldn't be happening. maybe something is wrong with those symlinks.
<mark_weaver>kristofer: what is the output of: readlink /root/.config/guix/latest
<roelj>Ah, I see.. it's generated in bootstrap.scm
<davexunit>Kristofer: looks like you reconfigure with an older Guix each time
<davexunit>so make sure you don't do that going forward.
<civodul>mark_weaver: yeah i have a script for that, that i posted to guix-sysadmin ;-)
<civodul>mark_weaver: i suspect that if the backend replies with 200, then closes the connection prematurely, then nginx might cache it as a zero-length reply
<mark_weaver>civodul: I recently changed the nginx config to use HTTP/1.1 to talk to hydra-server, hoping that might help.
<mark_weaver>with HTTP/1.0 in the absence of a content-length field, it might be hard for nginx to tell the difference between successful completion and an error, but if hydra-server uses the chunked method (forget the exact name), then the difference should be apparent to nginx.
<mark_weaver>e.g. if you made a change somewhere earlier in the file that contains bash, that would change the line numbers of the source location information for bash, which would change its guile build script, which would change its derivation and everything that depends on bash, etc..
<mark_weaver>so unfortunately the discarding of that information is important
<civodul>mark_weaver: maybe eventually we could change the derivation format to include "source maps" that would not have any effect on the hash computation
<Jookia>davexunit: Yes it's inefficient but a lot of the backtrace is noise/not understandable to me. I can kind of get what's going on but usually it's more efficient for me to just try different things
<mark_weaver>Jookia: my guess is that the reason is that is significantly reduces the likelihood of finding something that looks like a nix-base32 hash but isn't. e and t are the two most common letters in english text, and o is quite high up there too.
<mark_weaver>I don't know what guix-daemon does, but the algorithm I came up with to scan for hashes on the wip-faster-grafting branch benefits greatly from the fact that long runs of valid nix-base32 characters are quite rare outside of genuine references.
<Jookia>Ah, I see. I was reading through that code
<mark_weaver>I scan for the '-' after the hash, and every time I find a character that's not a valid nix-base32 char, I can skip ahead 33 bytes.
<mark_weaver>civodul: FYI, I've recently rebased wip-loongson2f onto recent master and updated GuixSD on my Lemote Yeeloong. thanks to grafts, it is now practical for me to keep GuixSD up-to-date on this machine which I choose to avoid substitutes on.
<civodul>mark_weaver: i was indeed seeing partial downloads being cached on the mirror
<civodul>so i ended up using http 1.1, which should help
<mark_weaver>civodul: if hydra-server uses chunked transfer encoding (or whatever it's called) to send the nars, then it should help.
<mark_weaver>one thing I'm not sure about is: does hydra-server detect if the nar packing subprocess returns a non-zero status code.
<mark_weaver>if there's an error in the subprocess, will it send the chunked-transfer-encoding termination making it look like everything is good?
<civodul>mark_weaver: good question; it's in NixNAR.pm
<mark_weaver>civodul: while investigating what would be needed to write the custom-nar-proxy for hydra, I was wondering: maybe I shouldn't bother talking to hydra-server at all for this? maybe it's easier to just use the code in guix that's used for guix publish?
<civodul>i don't know what Perl does when the pipeline fails
<rain1>I wonder if anyone has some aliases that are often used for development?
<rain1>I will probably collect up mine as i make them, I saw a nice ruby on rails on gist
<rekado>I usually just create a guix.scm file containing a preliminary package definition, then load it with "guix environment --pure -l guix.scm"
<mark_weaver>rain1: btw, on another subject: webkitgtk-2.4.x, which midori uses, just received an unexpected upstream update with security fixes, and I pushed the update to guix master a few hours ago.
<bavier>civodul: I haven't been able to recreate the ICE with guile's vm.c and -Os you reported the other day
<civodul>bavier: i just added -Os to the CFLAGS in guile-static, in make-bootstrap.scm
<ng_>would you prefer the way ratpoison.scm gets the .desktop or the way fluxbox (wm.scm) gets the .desktop file? there are 3 files on archlinux.org which would just do what I want for urxvt (urxvt,urxvtc,urxvt-abbed)
<mark_weaver>actually, I think it was a mistake to use the term "character" to describe code points, as opposed to graphemes.
<Jookia>I think the standard was revised to change the terminology
<Jookia>Generally I treat text as an opaque object to be manipulated using i18n/l10n tools
<mark_weaver>sure, but what I mean is that the elements that comprise strings, which historically have been called "characters" and which are still called characters in many places, even if the recent standards make clear that they correspond to code points.
<mark_weaver>when internationalizing things, for high-level purposes, I think it would have made more sense to make those elements graphemes, as perl 6 did.
<mark_weaver>and for low-level purposes, bytes of UTF-8 are a good choice.
<Jookia>That's true, I assume right now all the bootstrap binaries could be built with a version of GCC
<mark_weaver>the thing is, even with tcc, you'll still need an assembler and linker. and what architectures does tcc support?
<efraim>I did some reading last night on tcc, sounded a bit depressing
<mark_weaver>I had a different idea, to implement simple language implementations in Scheme, and to write a simple Scheme implementation that can run on bare metal, maybe initially as a coreboot payload.
<ng_>if 1984 hosting wouldn't be that expensive, I would pick a faster machine w more bandwidth so I can provide that as well, but for now it's 1984 for the patches thing testing soon, then maybe later more and a dedicated server running guixsd at in-berlin some day.
<mark_weaver>I've been thinking about jumping head first into this project for a while now...
<Jookia>You'd also have to get upstream compiler developers to agree on keeping a certain version for bootstrapping with
<lfam>mark_weaver: You're tempted to write machine code that can bootstrap the entire dependency graph?
<mark_weaver>bavier: well, my plan is to first bootstrap a Scheme interpreter and go from there, so a large part of the work would be to build our bootstrap binaries from Scheme alone, e.g. to have things like sh, make, and a C evaluator written in pure Scheme.
<lfam>I am referring to the current version of python-pyopenssl, not the old one on master
<dannym>(There was actually a funny competitions that start with paper and entering opcodes directly to write an assembler, then write a tiny forth using the assembler, then write a tiny scheme in forth, etcetc to see how long it takes to get network connectivity. I wish I remembered what it was called...)
<rain1>it's very fun stuff so you could probably organize people to work on lots of subproject aspects of it and make good progress
<civodul>Jookia: fwiw when i bootstrapped Guix (initially it was bootstrapped from Nixpkgs) i tried to reduce the set of binaries as much as possible, which was in part possible thanks to the Guile bits we use (web client, etc.)
<paroneayea>civodul: maybe a bit late, but I'm writing up a blogpost encouraging people to apply on MediaGoblin and Guix GSoC, especially the 8sync one for shepherd and the "port our federation to our new standard" one
<rain1>I think an assembler and tool to compute its output size would be a crucial part of a toolchain like this -- but anyway I agree with making a ML!
<paroneayea>ACTION wonders if anyone in #guix is new post libreplanet talk
<mark_weaver>rain1: it's a good observation, although I'm not sure how I'd make use of it, given that a similar trick could not be used for other components which I'd like to bootstrap from scratch anyway.
<rekado>so, the scheme implementation would run on bare metal and talk via serial port, allowing us to avoid dealing with hard disks and drivers.
<mark_weaver>or allowing those drivers to be written after some other parts of the system have been bootstrapped
<rain1>mark_weaver, yes it only works for assemblers - I have some half baked ideas for more complex compilers but I need to get them solid first :)
<mark_weaver>which would need to include some kind of editor and repl environment, bootstrapped concurrently.
<civodul>rain1: Rotten is an interesting exercise!
<rain1>civodul, it's great isn't it! I had always known about this attack but never saw a PoC before
<paroneayea>rain1: I'm trolling... I actually don't buy the "nothing is safe without static types" argument
<paroneayea>the main really dangerous bugs seem to be in memory safety and bootstrapping problems
<Jookia>So I guess we now know what mark_weaver's going to be doing over the next decade :P
<paroneayea>most type errors result in crashes but I think very rarely (comparatively) seem to be security issues from what I've seen
<mark_weaver>paroneayea: seriously though, I pondered trying to write proofs of everything along the way, but I think that might push this from a merely crazy idea to insane, and unlikely to get done by me.
<mark_weaver>for now I'd be satisfied to make the code as comprehensible as reasonable, avoiding clever tricks and hacks.
<rain1>They key would be to find ways that proofs can accelerate the development instead of slow things down
<paroneayea>mark_weaver: I met the current emacs maintainer (John Wiegley), he's currently working for work on a "provable far into the future system" using strong proofs
<mark_weaver>rain1: for now, the goal would be to bootstrap a GNU/Linux system, because that's the free OS that large numbers of people are actually using, but my hope is that other systems could be bootstrapped from this same tool.
<mark_weaver>and specifically, I would probably focus on bootstrapping GNU Guix in particular
<paroneayea>one thing that was interesting in Snowden's talk
<paroneayea>he called out long-running stable systems as something we probably can't promise
<Jookia>mark_weaver: At what point do you declare a system tristed?
<mark_weaver>paroneayea: I came very close to diving into the world of proving as much as possible, static type systems, etc, but Sussman has recently convinced me that there are serious downsides to that approach to programming.
<Jookia>mark_weaver: Well, even if you build it from sand you have to trust each piece of software too. Are we going to declare Linux trustable? At what point can we be satisfied with bootstrap binaries?
<paroneayea>Jookia: there were a few, but one especially (which davexunit sent me) was very strongly emphasizing the need to have programs which are live and dynamic
<paroneayea>and only very very particularly special pieces need strong proofs (like garbage collectors)
<paroneayea>mark_weaver: though maybe a bootstrapped system could be considered a case where a strong proof system would help, I don't know. I agree you should aim for implementability not perfection though.
<rain1>unlike scheme, rust has a complex type system which program safety rests on
<rain1>therefore the safety of programs that type needs to be proved - this is someones PhD project
<mark_weaver>CompanionCube: that RFC includes this text: "Rust, at least, does not have to worry about memory safety violations, but it is still possible for overflow to lead to bugs. Moreover, Rust's safety guarantees do not apply to unsafe code, which carries the same risks as C code when it comes to overflow. Unfortunately, banning overflow outright is not feasible at this time. Detecting overflow statically is not practical, and detecting it
<mark_weaver>dynamically can be costly. Therefore, we have to steer a middle ground."
<CompanionCube>I'm not a rust programmer, I'm just aware that it's a thing and that they have a thing for safety and related things
<mark_weaver>and that's in line with my vague recollection of Rust: they are trying their best to improve safety, but ultimately they consider high performance to be a top priority, and that's a reasonable position for them to take, given their goals: to allow them to use it to write a competitive web browser that people actually want to use.
<CompanionCube>there are some other interesting projects in it - an OS and coreutils
<mark_weaver>sapienTech: the porting guix to hurd project is probably already locked in, since the person who has already done most of the work on that has expressed interest in doing it again this year.
<mark_weaver>sapienTech: yeah, I'd agree that the GUI package manager is probably (IMO) a lower priority than some of the others, including the two others you mentioned, precisely because right now our audience is limited to techies for other reasons.
<mark_weaver>an installer wizard is one the key blockers to allowing non-techies to use guix.
<mark_weaver>but I still think it's important that whatever project you choose is well suited to your interests and skill set.
<mark_weaver>all of these things will be important at some point, it's just a question of when :)
<mark_weaver>so, e.g. if you would be motivated to write a GUI package manager, that would not be wasted effort.
<sapienTech>mark_weaver: agreed. I think personally I am more interested in getting involved with the guix community, and working on something that can make a definite impact right away, than I am about working on a particular piece of software
<sapienTech>and like you said, a definite consideration is what would suite/push my skill-set
<mark_weaver>sapienTech: do you have previous experience with Scheme or Lisp?
<sapienTech>I am familiar with the guile-specific features, like extending/interfacing with c programs
<sapienTech>I understand many of the more advanced topics in the guile manual, and the general concepts behind scheme as a language, like latent typing, closures, macros, continuations, mutual recursion, tail recursion, etc
<dannym>[I've been thinking on and off about some emacs thing which does ... forms as the GUI installer. Not a lot of dependencies (especially not X) and still can be made very user-friendly because the form could auto-update on the fly as you enter values and the documentation of what things are could be in-line. (Thinking doesn't mean I started doing it). I think many parts for it already exist, even. I think wanderlust uses these kinds of