IRC channel logs
2014-12-29.log
back to list of logs
<mark_weaver>btrfs utilities will be included as soon as someone packages them. <zacts>perhaps I should be the one to begin this task of Btrfs <zacts>I'm currently on openSUSE, just so I can test Btrfs <zacts>I think I'll install guix on this openSUSE right now <zacts>I know I keep promising to contribute more, I've been busy as all hell with work and school <zacts>huh, I also wonder about the eventual possibility of giving the user a choice to use LibreSSL <zacts>how does guix handle choicey things like this? <zacts>Let's say if you are building everything from source yourself? <davexunit>you'd just have to write packages that use libressl <zacts>huh, where are the proper instructions for building guix on top of another Linux distro? <zacts>I don't see the doc for this in guix /src, or on the homepage <davexunit>the INSTALL file and the info manual have instructions <davexunit>HACKING has the additional details for building from git <zacts>oh, that's the problem I don't see an INSTALL file <zacts>this is with a freshly cloned guix git repo <davexunit>that file is just auto-generated by autotools <davexunit>that file won't teach you anything about installing guix <zacts>which doc will teach me how to install guix on openSUSE <zacts>I previously only saw Installing Guix on Guix, and Installing a full Gnu OS <zacts>^ a pastebin of my guix build error on openSUSE 13.2 amd64 <zacts>I fixed that one, now if I can just figure out how to make pkg-config find guile <zacts>^ this explains how to make guix find guile <mark_weaver>zacts: a better solution is to set PKG_CONFIG_PATH to PREFIX/lib/pkgconfig, the directory where guile-2.0.pc is located. <mark_weaver>zacts: looks like you have an old copy of our git repo. sync-with-upstream is no longer needed. <zacts>mark_weaver: oh, indeed. I did: git checkout v0.8 -b tag-branch <zacts>I did this under the assumption that v0.8 might be a simpler install to bootstrap from <mark_weaver>for one thing, there have been a lot of security fixes since 0.8 <zacts>things are really moving along and changing quickly with guix <zacts>which is cool. it's not the same guix since the last time I was able to install it <mark_weaver>I'm now working on porting Guix to armhf using my Novena board. <zacts>./configure: line 7016: syntax error near unexpected token `have_guile_json,' <zacts>./configure: line 7016: `GUILE_MODULE_AVAILABLE(have_guile_json, (json))' <mark_weaver>zacts: that indicates that guile.m4 wasn't found when 'autoreconf -vfi' was run. <zacts>ok, I don't see guile.m4 in /usr/share/aclocal <mark_weaver>add that directory to ACLOCAL_PATH and rerun "autoreconf -vfi" then rerun configure <zacts>via the opensuse package manager <zacts>and sudo zypper install guile-devel <mark_weaver>maybe opensuse puts guile.m4 somewhere else. that's the file you need. <zacts>now configure works as expected <zacts>mark_weaver: how long does a full guix OS build take on your gnuglug box? <zacts>I'm still considering getting a gnuglug <mark_weaver>you mean building everything from source, and never downloading any pre-built binaries? I haven't tried it on my gluglug. <zacts>heh, I actually assumed that's what you guys were doing.. <zacts>that's cool, but it's also cool that you have the option to build if you want to <mark_weaver>I build everything from source on my yeeloong, and that takes over a week. <zacts>I think once I do guix OS on my main box, I'll do it slackware style <zacts>I'll use binaries for a core base <zacts>and then I'll build my own userland apps <zacts>hah, cool re yeeloong builds <zacts>so you are the primary build farm for yeeloong packages I take it <zacts>mark_weaver: you could probably cross build from a kvm virtual machine though <mark_weaver>we have a build slave to build binaries for MIPS, but it's currently down waiting for a replacement fan. <zacts>the first thing I'm going to go for is i3wm <mark_weaver>the reason I don't use pre-built binaries on my Yeeloong is because I consider it to be my (relatively) high-security machine. e.g. it's the only machine that has my private GPG key, and the only machine with the key to get root access to some other machines. <zacts>mark_weaver: ah that makes sense actually <zacts>you don't want backdoors from various parties (NSA) to tamper with your stuff <zacts>that's good you are concious of that kind of thing <zacts>mark_weaver: I've discovered I really hate java.. oh I forgot it's actually Java(TM). I've had to learn it for school and stuff. <zacts>anyway, guix build is doing well. I'll return in a bit <zacts>oh btw, didn't you mention a gnu music radio service to me once? <zacts>I would like to listen to independent artists freely <zacts>eek, segfault with a message "invalid reference to markweaver.go" <mark_weaver>zacts: since you're considering a gluglug, you might be interested to know that the Thinkpad X200 will soon be supported by Libreboot. <zacts>nah, I'm glad it's working thus far <zacts>mark_weaver: oh nice let me make a note of that <zacts>if I get a glugglug or X200, I'll probably try to get libre backup drives for it <zacts>heh, it's my own invented phrase! I mean a backup drive that hopefully doesn't require non-free firmware, and doesn't use usb. <zacts>man I sound like such a newbie tonight <mark_weaver>if not usb, what kind of interface are you considering? <zacts>mark_weaver: an internal laptop drive connection <zacts>I want to get backup internal drives <zacts>I don't remember the proper name for that kind of connection <zacts>no, I want a laptop that comes with an internal drive. then I want to purchase a backup internal drive for when the original drive fails <zacts>only one drive is in the laptop at any given time <zacts>My point being, I want to make the laptop last for as long as I can <mark_weaver>sure, it's just not what I thought you meant by "backup" :) <mark_weaver>anyway, I don't think I've ever come across a hard drive that requires non-free software to run, although I don't doubt they exist somewhere. <zacts>mark_weaver: the new wifi only drives do <zacts>they have no way to physically connect to them <zacts>as it stands now, I dislike this concept <zacts>(due to the fact that they will require non-free software to even use) <zacts>cool now it's actually downloading guile <zacts>I guess this means that it's actually building my core guix now <mark_weaver>I should clarify that in fact all modern hardware have proprietary software running on them, but the user generally doesn't have to touch that or update it. <zacts>mark_weaver: it would be nice to somehow provide progress bars for 'downloading file' <mark_weaver>well, not "bars" but at least a count of how many bytes have been received so far. <zacts>ok, I'll let you know if any of the 'make check' tests fail <mark_weaver>I highly recommend running guix-daemon as root. it actually runs the build processes an unprivileged users in isolated containers, but it can only do that if it starts out as root. <zacts>yeah I plan to run guix-daemon as root <zacts>and I have my Environment users already setup <zacts>do the checks usually take longer than the build of guix? <mark_weaver>and do _not_ add any other users to the 'guix-builder' group. <mark_weaver>yes, the checks take a long time the first time they are run. <zacts>mark_weaver: are they mandatory? <zacts>hm.. mind if I just kill the make check and try it at a later time? <zacts>I would like to provide feedback to you guys, but I also would like to get started <zacts>snix.scm <- about how far thru is this? <zacts>mark_weaver: oh, I was just going to keep the make check going if I was close to being done <zacts>oh, newbie question, but should I append & to # guix-daemon --build-users-group=guix-builder ? <zacts>or how should I properly start it in the background? <mark_weaver>it's up to you, but it does output messages even if it's in the background. <zacts>mark_weaver: any doc on how to make a systemd init, yes I dislike systemd but it's what opensuse is using? <zacts>an init specifically for guix that is <zacts>that way I can just reboot into it and it will be running <mark_weaver>there's not much to it though. anyone who knows how to create those files should find this one quite easy. <mark_weaver>we don't create a pid file or anything like that. just launch the daemon and forget about it. <toxemicsquire4>Hi; I have a question: Does anyone know the progress of Guix/HURD port? <sneek>Welcome back toxemicsquire4, you have 1 message. <sneek>toxemicsquire4, nkar says: I haven't heard much about it recently. search for relevant commits in the git repo <mark_weaver>toxemicsquire4: phant0mas / ph4nt0mas here on channel is the main person working on it. it's been slow going. <mark_weaver>part of the problem is that the official releases of hurd and glibc don't even work together. the hurd folks have been focused on debian for so long, things have become dependent on debian-specific patches. <mark_weaver>we have a 'wip-hurd' branch in the git repo, last updated 4 weeks ago. <toxemicsquire4>mark_weaver: I heard that they use the debian glibc instead of upstream glibc. Cant the glibc devs just apply patches made in debian glibc to upstream? <mark_weaver>anyway, obviously the guix/hurd effort could use more help. <toxemicsquire4>I wish I could help with the HURD port, but I'm not a programmer, at all. <toxemicsquire4>But I do have intermediate experience with GNU/Linux. But not alot with guix <toxemicsquire4>I did ask on the mailing list how I could help, some said that I could help with packaging, but I don't know when to start <mark_weaver>yes, I was just about to say that "packaging" is the best way to get started for anyone. programming skill is rarely needed there. <mark_weaver>as for "when" to start: whenever you are motivated to do so :) <toxemicsquire4>mark_weaver: I also ment where.I do have some packages in mind, though I don't think their very simple to package; vidalia, <mark_weaver>vidalia might not be too hard, dunno. we have 'tor' already. <mark_weaver>but it might be better to find something easier to get started. <mark_weaver>I don't know enough about how vidalia works to know. <mark_weaver>toxemicsquire4: also, it's helpful just to try running guix and reporting any problems you run into. <nkar>toxemicsquire4: isn't vidalia deprecated? <mark_weaver>I guess the one caveat I should mention is that, just like the other fully-free distros, it won't run any hardware that requires non-free drivers or non-free firmware. <toxemicsquire4>mark_weaver: That's my problem. I have a proprietary wifi card. Sadly. I did buy a free wifi card, but it takes a very long time to ship where I live <nkar>toxemicsquire4: I mean the tor people seem to argue against using anything except the tor browser, which doesn't use vidalia any more. I guess it's because the browser is the major attack verctor, that's how fbi caught people using tor, for instance. <nkar>toxemicsquire4: can't you use eth0 for a while? <nkar>toxemicsquire4: also, if you're new to guix and programming, I'd rather not install guix as a standalone system. at some point, you may want to install something that's not packaged, which you have no idea how to package, and it'll be frustrating. <nkar>I'd suggest to use it as a package manager <zacts>mark_weaver: so how can I properly build and install my own packages? <nkar>on top of whatever you use right now <nkar>zacts: with guix package you install it into your profile <nkar>guix build just builds it <nkar>(which makes it available in the store) <zacts>nkar: how can I make guix package also build my package from src rather than using the hydra packages <nkar>zacts: just add it to gnu/packages/<your package>.scm <toxemicsquire4>nkar: I actually did install Guix standalone. I loved it. It was very easy. And getting packages through guix package -i was a breeze. It's just that my desktop requires a more "mature" system(Debian) and my laptop is way more "experimental" and I di whatever to it. I would eth0 if I can, but unfortunately, I can't <nkar>zacts: there may be a way to use a different directory <mark_weaver>zacts: pass "--no-substitutes" to either guix-daemon or the user command to inhibit downloading binaries. <nkar>zacts: but I don't know off hand <nkar>toxemicsquire4: well, than the only option you have is to wait, obviously <mark_weaver>zacts: warning, it will require building a *lot* of stuff before you even get to the package you want to compile. <zacts>mark_weaver: oh I'll just use packages then <mark_weaver>because it needs to compile the entire toolchain, and all the associated tools, first. <zacts>mark_weaver: is there a way to get the packages for just the core build tools? <zacts>and then I can build the individual apps and regular dependencies myself? <nkar>toxemicsquire4: I don't know much about init systems to answer. guix uses it because it's in scheme, I guess <zacts>ok, now I know how to get the help for guix package: guix package --help <nkar>yes, it's on the webpage <zacts>zacts@linux-nw87-$ guix package guix package -i nvi <zacts>guix package: error: guix: extraneous argument <mark_weaver>zacts: we don't really have a concept of "core build tools". <zacts>I'll just use packages, and then I'll only build stuff that I'm patching then <mark_weaver>zacts: umm, look closely at the command you just pasted us. <toxemicsquire4>Is dmd planning to be more standard init like, or is it going to be more systemd like, more of a service manager <mark_weaver>but I can say that one reason we're not using systemd is because the systemd maintainers don't want to support any kernel except linux, and we want to support the hurd. <toxemicsquire4>mark_weaver: I'll make it simpler: Is dmd supposed to be a dropin replacement for sysvinit or does it want to take over anything that involves networking, logging, etc? Also, does Guile build on HURD yet? Because if it did, porting dmd would be the easiest thing <mark_weaver>dmd does not want to take over all of that other stuff, no. but it's not a drop-in replacement for anything. <zacts>ok, why is 'guix pull' downloading a bunch of .xz files? <mark_weaver>I've _never_ run "guix pull", not even once, so I couldn't say. <zacts>this is not the command I thought it was <mark_weaver>but I can tell you can "guix pull" populates ~/.config/guix/latest by default, and you can undo whatever it did by blowing away that directory. <nkar>is there a lightweight program that I could use to view images in jpg and png formats? <mark_weaver>fwiw, my preferred way of keeping up-to-date is to do "git pull", not "guix pull", and then I always run guix out of the git repo. <zacts>that's probably what I meant to do, and I misread git as guix there <mark_weaver>nkar: if you already have emacs running, you can just view images from emacs. not the best image viewer in the world, but it works for most purposes :) <nkar>but I've used it to view pdfs <mark_weaver>zacts: I actually put a script in ~/bin/guix that just does: /home/mhw/guix/pre-inst-env guix "$@" <toxemicsquire4>mark_weaver: I was looking at the tree and I noticed that the ROADMAP is waaaay off. It mentions Guix 1.0 during GNU's 30 year anniversary release <zacts>ok that is added to my guix.txt notes <nkar>hm, mine doesn't show the image, I guess it's built without some library, which is required <mark_weaver>zacts: this is a good setup if you want to run with your own custom modifications to various packages, because git can handle merging our upstream work into your private branch, or alternatively, rebasing your private work on top of our master branch. <mark_weaver>nkar: ah, it might actually be that you are missing some program in your profile that emacs uses. <mark_weaver>nkar: the default 'emacs' package in guix definitely supports viewing images. <nkar>right now, I'm using the one from trisquel :) <nkar>I don't have time to fiddle with this, so I'll just find something else <nkar>so far I've been using gimp, but it's crazy :) <mark_weaver>trisquel surely has no shortage of lightweight image viewers, but I don't know what's popular these days. 'gthumb' comes to mind, but I don't know if it's still the preferred gnome image viewer or not. <mark_weaver>toxemicsquire4: ha, you're right! that file needs some updates :) <mark_weaver>zacts: fwiw, I have my own branch called 'mhw', and I periodically do "git fetch" and "git rebase master" from my private branch. <nkar>while we're talking about software, mark_weaver, what color theme do you use in emacs? <mark_weaver>that way, my private commits are always floated to the top of my git history. <mark_weaver>nkar: I actually use black text on white, which I guess is the default. <mark_weaver>for most of my computing life, I used white text on black, but when I used the OLPC XO outdoors I found that it didn't work well in sunlight conditions unless I used black text on white. <toxemicsquire4>mark_weaver: I'm really surprised nobody noticed. I would predict a Guix 1.0 release in about 3rd Q of next year <mark_weaver>the problem was that the sunlight had to get in to reflect off the back, and that works a lot better when most of the pixels are transparent (white). <mark_weaver>when almost all the pixels are opaque with only a few pixels for light to get in, the reflection didn't work well at all. <zacts>mark_weaver: ok I did 'guix package -i nvi' and it's still building everything from source <mark_weaver>zacts: ah, it sounds like you haven't authorized hydra's key. <nkar>mark_weaver: too bad, I've been searching for a good dark theme for a long time, but I've always rolled back to the default one. I like how solarized (which also has a light theme) looks on screencasts, but it's too green-ish for my taste. though, I may get back to it at some point. <mark_weaver>hydra's signing key, that is.. i.e. telling guix-daemon that you trust binaries signed by hydra (our build farm). <nkar>haha, there's an image viewer called geeqie, guix should make it the default one just because of the name <mark_weaver>zacts: to enable binary substitutes from hydra, do this as root: guix archive --authorize < hydra.gnu.org.pub <mark_weaver>hydra.gnu.org.pub is in the top-level guix source directory <mark_weaver>it's also possible to set up your own private machines that will be used to do builds for you. <zacts>Ok, now I think it's working *zacts is excited about this guix package manager install <mark_weaver>(actually, I think I'm going to start doing that myself) <zacts>ok, sometime tonight or this week, I would like to add a few utilities <zacts>so I guess you borrow from nix whenever possible? <zacts>I want to import the 'tree' command <zacts>tree will visually display a filesystem, and it can show which files are eating up the most space <mark_weaver>although our guix-daemon is only slightly modified from nix-daemon, the way we build packages is totally different. <mark_weaver>they use shell scripts basically, and our package builds are guile programs. <zacts>cool. so what is the main advantage of package scripts being guile programs vs shell scripts? <zacts>or is it just a personal preference? <mark_weaver>well, scheme is a vastly more expressive language than the shell. <zacts>oh I guess the shell scripts are recipes <zacts>sorry, I'm thinking of distfile .info style files <zacts>not the actual install scripts <zacts>yeah, I see how guile rocks in this case <zacts>ok, /me is install emacs-24.4 now <mark_weaver>we do occasionally look at nix packages for ideas on how to solve harder problems, usually with packages that don't cope well with being installed in /gnu/store/... instead of the more typical installation locations, but most of the time I don't look at nix packages. <zacts>oh, how must I clean up old files in guix? <zacts>so I don't have stale packages eating up space <mark_weaver>do _not_ delete anything from /gnu/store manually. you'll bork your system badly. <mark_weaver>you can use "guix gc --delete /gnu/store/..." to delete individual store items, but it will refuse if there are any remaining references to it. <mark_weaver>older versions of your profile might point to those store items if you installed a package and later removed it from your profile. <zacts>once emacs is done, I'm going to work on importing the 'tree' command <mark_weaver>"guix package -d" will delete all older versions of your profile. <mark_weaver>it should be noted that in general, when using guix packages, you often need to set environment variables so that things will be found in ~/.guix-profile/ <mark_weaver>we mostly take care of the environment variables in the guix standalone OS install, but when running inside another system you often need to fiddle with them. <mark_weaver>well, not "often". I hardly touch them since first setting them up. <zacts>mark_weaver: still awake for a sec? <mark_weaver>but it took some time to find all of the ones I needed. <zacts>^ this is the official homepage for the command I want to import <zacts>they don't provide md5sum / sha512sum / etc.. <zacts>I am crossreferencing other makefiles for nix / bsd ports <zacts>what would your security policy be regarding including this? <mark_weaver>well, first: providing just a sha512sum or similar provides no security at all. <zacts>oh should it be gnupg signed? <mark_weaver>clearly, we need to be moving in the direction of every important upstream package being signed, but alas, many of the crucial ones aren't. <zacts>I can email the maintainer, they accept suggestions for improving their site <zacts>and the last commit was of this year <mark_weaver>guix package recipes include a cryptographic hash of the source tarball at least, so we'll notice if not everyone gets the same tarball. <mark_weaver>(in fact, on several occasions we've noticed when some upstream maintainers made some changes to their tarball and gave it the same name and version number) <zacts>so the question is: if we can match nix's checksums for this 'tree' utility, will you accept a patch to import 'tree' into guix? <mark_weaver>that would not be a reason to block inclusion into guix, even if nix didn't have the package. <zacts>cool, well I guess I'll begin my work on this <zacts>and I'll try to catch you tomorrow or something <nkar>zacts: wrt to emailing the maintainer, that'd be cool <nkar>ask them to make the key available on keyservers <nkar>it'd be cool if it's signed by someone else <mark_weaver>zacts: and it's good that you are thinking about this. I verify the digital signatures whenever they are available. <mark_weaver>and import the relevant keys into my keyring so that next time I'll already have it. <nkar>I also check the hash in nixpkgs if there's no signature <nkar>mark_weaver: sleep well :) <tadni>zacts: st should be really easy. <tadni>My big one, Stumpwm, is going to be a pain -- I think. <tadni>I'll probably need to do a build-system for CL, just for cl-ppcre and clx. <tadni>Stumpwm has a proper makefile though. <mark_weaver>zacts: we already have pstree, it's part of the 'psmisc' package. <mark_weaver>libreoffice is being worked on, on the 'wip-libreoffice' branch. <mark_weaver>someone is working on openjdk, I think. maybe bavier? <zacts>(don't worry I'm also referencing the guix package list) <zacts>but yeah, it's good to know what not to work on <zacts>so I don't redo work that's already been done <zacts>I'm starting with 'tree' as it's really really simple to build *tadni has been gearing up on getting his blog ready for the new-year, but has been sitting on a few patches. <tadni>Namely, the pretty-printing of use-xyz-modules (system, packages, services). <zacts>hydra seems to be really slow for me <zacts>downloading the racket package is taking a while <tadni>zacts: It is and it always is. <tadni>We need a better build box, on the main instance. <zacts>perhaps I'll setup my own build box for my personal packages <zacts>similar to what mark_weaver was mentioning <tadni>Also, eventually we will have some sort of self-hosting of binaries. Forgot the name of said feature, but modularizing this away from just a single source of trust -- I think is a huge asset. <tadni>iirc, davexunit was workign on it. <zacts>distributed deterministic builds? <zacts>that would be so cool, I hope it's possible <tadni>zacts: Kinda. It's more like, you have a prebuilt binary and you can run "guix whatever" and it makes it available to others -- not via hydra. <zacts>sounds like deterministic builds <tadni>zacts: Yeah, Guix is really doing stuff I've not seen other Distros/Package managers boast. <tadni>davexunit talked about this awhile ago, as kinda a "self-hosted aur" type system. <tadni>I like the notion that I can make, say a subdistro, and run a couple custom binaries of non-stable releases for people to use -- real easily. <rekado>zacts: I'm currently working on OpenJDK (or rather its many dependencies). <zacts>I think I'll try out the actual distro on my server <zacts>I'm thinking I'm going to possibly put NixOS on my main laptop for now, and then I'll put guix on top of that <zacts>eventually around v1.0 I'll likely switch full over to the guix distro <mark_weaver>civodul: fyi, I have my Novena board, and am currently working on bootstrapping guix on it. <civodul>mark_weaver: what are your thoughts regarding --strip-all? <civodul>it seems to be a can of worms, so i'm tempted to just revert it <mark_weaver>civodul: yeah, I was wondering about --strip-all myself. I'd also be tempted to revert it. <mark_weaver>civodul`: yeah, I was wondering about --strip-all myself. I'd also be tempted to revert it. <mark_weaver>civodul`: on my 'armhf' branch, I added a patch to gmp, and now "guix build -K hello" results in a VM overflow while trying to bootstrap. I'm at the point of trying to compile gcc-cross-boot0 <mark_weaver>civodul`: is there a circularity problem introduced by trying to patch gmp? <mark_weaver>my first guess here is that 'patches' cannot be used in some of the early bootstrap packages, presumably because the patching derivation requires inputs that depend on these bootstrap packages. <civodul`>mark_weaver: normally in early bootstrap, 'patches' is handled by %boostrap-guile <civodul`><origin> has a field to specify the guile to use *civodul` checks the details <mark_weaver>civodul`: might the problem here be that (packages-sources gmp) is used as an input to gcc-cross-boot0? <mark_weaver>maybe that's not handled by whatever arranges for patches to use %bootstrap-guile? <civodul`>see 'bootstrap-origin' in (gnu packages bootstrap) <civodul`>it's the thing that makes sure <origin> uses %bootstrap-guile <mark_weaver>civodul`: right, and it looks like that should handle origins in inputs properly. <mark_weaver>I need to get a proper scheme backtrace to see where the loop is. <mark_weaver>civodul`: the infinite recursion happens between gcc and tar. <mark_weaver>civodul`: it seems that the problem is that the 'origin' with 'patches' uses a non-bootstrap 'tar' as an input. <mark_weaver>well, that's my guess anyway. in any case, the infinite recursion is that gcc-boot0 uses gmp's source as an input, and that recurses back on gcc, etc. <civodul`>package-with-bootstrap-guile is supposed to DTRT <civodul`>try putting an explicit (bootstrap-origin foo) there <mark_weaver>civodul`: however, it should be noted that I can build gcc-cross-boot0 itself without hitting the infinite recursion. <mark_weaver>so the problem is elsewhere, but still related to adding a patch to gmp. <mark_weaver>the two other things I tried that led to infinite recursion were: "guix build hello" and "guix build -S gmp" <mark_weaver>but "guix build -e '(@@ (gnu packages commencement) gcc-boot0)' works. <mark_weaver>"guix build -e '(@@ (gnu packages commencement) gcc-final'" hits the problem though. <mark_weaver>civodul`: ah, that's the problem: 'gcc-final' inherits from 'gcc-boot0', but it overrides the inputs, again using (package-source gmp). wrapping *that* with 'bootstrap-origin' fixes the problem. <mark_weaver>unlike many of the other *-final packages, gcc-final is not wrapped by 'package-with-bootstrap-guile', although it inherits from a package which was wrapped with it. <mark_weaver>okay, this looks to be going well. I'm now natively building armhf bootstrap tarballs. <mark_weaver>bah, I spoke too soon. problem compiling glibc-intermediate <mark_weaver>checking for .preinit_array/.init_array/.fini_array support... ../glibc-2.20/configure: /gnu/store/cb4aacihlv662xm32ba8pv5kw55d7a3h-bootstrap-binaries-0/bin/fgrep: /gnu/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-bash-4.3.30/bin/bash: bad interpreter: No such file or directory <mark_weaver>civodul`: fgrep in bootstrap-binaries-0 is a shell script, with the following shebang: #!/gnu/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-bash-4.3.30/bin/bash <mark_weaver>civodul`: what do you think is the problem fix, if anything? <mark_weaver>do we have any way of making executable shell scripts in the bootstrap tarballs? <mark_weaver>a hacky workaround would be to replace all instances of 'fgrep' with 'grep -F' in the configure script during bootstrap, but it doesn't seem very nice. <jmd>mark_weaver: I had to place symlinks for the eeeeeeeeee paths. <mark_weaver>jmd: well, users will hit this again and again, every time we update something in core-updates. <mark_weaver>egrep and fgrep are the only scripts in bootstrap-binaries <mark_weaver>maybe, in the bootstrap binaries, we could modify 'grep' to look at argv[0] such that we could just make 'egrep' and 'fgrep' links to 'grep'. <mark_weaver>looking at the grep source, it looks like it should be very easy. <mark_weaver>alternatively, we could make a second-stage 'bootstrap-binaries-0' that simply modifies those shebangs to point to an existing shell. <mark_weaver>better yet, I could just modify 'package-from-tarball' to handle rewriting shebangs to use the bootstrap bash binary <mark_weaver>the replacement fan for the MIPS build slave just arrived. cool <zacts>ok, I had some problems with my openSUSE install, so I'm going to put guix on Slackware <zacts>for now, until I can run guix as my full distro <mark_weaver>zacts: what problems did you have? changing the distro underneath seems like a very big hammer to solve some unspecified problem, and may not even help. <mark_weaver>guix doesn't really use anything from the host distro except the kernel <civodul`>mark_weaver: we can't have executable scripts in the bootstrap tarball, because we don't know the location of 'sh' in advance <civodul`>but so far, 'fgrep' and 'egrep' haven't been needed <civodul`>not particularly elegant, but the easiest thing to do, i think <mark_weaver>well, I don't know how many other things are going to try to do the same test on arm. <mark_weaver>and who knows how many configure tests are going wrong because of broken egrep and fgrep? <civodul`>actually, it may be easy to change %bootstrap-coreutils&co in (gnu packages bootstrap) to patch them <mark_weaver>right, I was thinking of something along those lines. <mark_weaver>I guess an easy fix would be to modify 'package-from-tarball' to take the bootstrap bash as an input, and fixing shell shebangs in bin/ <mark_weaver>hmm, I wonder why 'tcpdump' doesn't support live packet capture on my guix system. <civodul`>mark_weaver: i would add an 'sexp' argument to 'package-from-tarball', and have it paste that after the tarball unpacking <civodul`>so you would use that to pass code that patches the files <mark_weaver>civodul: hmm, although both 'patch-shebang' and 'patch-shebangs' seem to assume that executable searched for in the path has the same name. will that be the case for the result of (search-bootstrap-binary "bash" system) ? <mark_weaver>well, I guess I could have it use the bash from within the binary tarball instead of a previously-existing one. <civodul>mark_weaver: patch-shebang (singular) takes an optional search path <civodul>so you could use (list (getcwd)) as the search path here <civodul>well (list (string-append (getcwd) "/bin")) <civodul>i'm happy to help get Guix on the Novena ;-) <davexunit>maybe all the bootstrapping will be done by the time I get mine ;) <civodul>somehow, the xorg update made my touchpad highly sensitive and hard to use <mark_weaver>civodul: we have xf86-input-evdev now, which maybe is being used instead of the older xf86-input-mouse driver <mark_weaver>civodul: it would be interesting to know what happens if you remove the "ModulePath" for evdev in the xorg server config. and it would be interesting to see the difference in the xorg server log output between those two cases. <mark_weaver>I would have hoped that the latest evdev would be as knowledgable about trackpads as the earlier drivers. <civodul>just looked at the diff of the Xorg logs and i can't see any obvious clue <civodul>evdev uses "AlpsPS/2 ALPS DualPoint TouchPad", which is probably the right thing (the old Xorg used the 'mouse' driver and didn't seem to know it was a touchpad) <zacts>mark_weaver: oh no, it wasn't a guix related issue <zacts>I just gave up on openSUSE in general, and I missed a Slackwareish install <civodul>mark_weaver: great, thanks for patching the hardware! <zacts>I didn't give up on openSUSE exclusively because of any guix issues <zacts>the problem with openSUSE is that they use a ton of non-official repos for basic stuff. <zacts>I already had a mixed up install in general, and I wanted to start clean. <zacts>also openSUSE was too bloated for my needs <mark_weaver>civodul: it may be that we're missing some database of trackpad settings for udev