***Guest16702 is now known as cirno9
<cirno9>what should I do with it to test it? just booting it in qemu, or also building guix? <amz3>you can install guix ontop of another distro or boot *guixsd* image with qemu <amz3>mind the the *sd* suffix which means "software distribution" <amz3>cirno9: can you login as root without passwd? <amz3>maybe you can try to install screen with the following command: guix package -i screen <amz3>cirno9: IIRC you need to tell qemu to share the network connection <cirno9>i wasn't able to get networking inside qemu though, maye i need to do the briding thing <cirno9>if i can get networking ill do this and report <civodul>normally just "qemu-system-x86_64 -enable-kvm foo.img", and then "ifconfig ens3 up && dhclient ens3 up" <cirno9>oh wonderful! I had been trying vint <cirno9>with -net, but -enable-kvm works great! <civodul>you also need to prepare an image for the target disk <cirno9>my friend was having this problem too, I'll tell them how to get guix working in qemu <civodul>it can be created with "qemu-img create ..." <amz3>civodul: is there anything stoping us for building xfce images? <cirno9>cool :) doing guix system init now <civodul>amz3: basically "guix system disk-image gnu/system/examples/desktop.tmpl" and you're done <amz3>That's what I was thinking <civodul>oh, would have been nice to have Octave 4.0 <amz3>indeed, I need some thing like that actually <Steap>why don't we have ISOs again ? <Steap>And can I install guixsd by running "kvm -hdb /path/to/a/regular/file" ? <amz3>I think it's to avoid every budy from this planet to come and flood the channel ;) <civodul>i think you need "qemu-system-x86_64 -enable-kvm -hdb somefile the-image", or something equivalent <civodul>and we don't have ISOs because CDROMs are a thing of the past ;-) <Steap>yeah but people still use ISOs all the time <civodul>last time i stumbled upon an ISO, i had to use unetbootin so it would fit on a USB key <Steap>ACTION should free some space on his SSD to boot up a new VM :p <Steap>Or I could buy a 1TB SSD, that might be faster and cheaper. <Steap>Space is meant to be filled. <amz3>I should download wikipedia more often <Steap>And data is kind of like gas <Steap>it takes all the space it can <amz3>I used to say that all the time to my electrical engineers friends <mark_weaver>civodul: guix-devel built successfully on armhf on the second try :) <cirno9>I tried too package octave to help <cirno9>but I just noticed a slightly older version is already in the packages <amz3>that good news i think, it means it's easier to package the current version <carif>so in a kvm, I'm presented with the guixsd login screen. what's the default username and password? <mark_weaver>carif: best to switch to a text console, log in as root, and then set your user password from there. <carif>just echo what it says to me <carif>how do I get to a text console? <carif>feels like it some days; no I've been here before <carif>unfortunately my kvm host is intercepting those keybindings <mark_weaver>well, it's not important, especially if you're just testing. <mark_weaver>I don't usually like to log into a graphical session as root, just because it's a lot of complex software. <carif>cool, there's a mechanism to force the shortcut to the kvm, so I'm at VT0 <svetlana>Hi, are there plans or ETA on making a live CD image? <carif>awesome, i have a working image <amz3>svetlana: you can do it, it simple scroll up to read the command from civodul <mark_weaver>well, a disk image anyway. we don't yet have the mechanism to create an ISO <amz3>well one can create usb disk live image it can be enough for linux users <carif>mark_weaver, so at the end grub-install appears to fail and I need to 'grub install --boot-directory=/mnt /dev/sda' for my target disk drive /dev/sda. When I boot, I get the grub cli to which I must load the configfile with 'configfile (hd0,msdos1)/boot/grub/grub.cfg'. Then I boot. <cirno9>oh no, failed install grub2 after populating /mnt/gnuguix <carif>this might be unique to me since I'm doing this crufty kvm thing <carif>cirno9, did I do something wrong? <cirno9>I think I did something wrong, ill try again with a partition <amz3>what does it mean that there is no mechanism to create an iso? <carif>... other than not installing to bare metal ... as I progress maybe I'll buy a box for this. we'll see... <mark_weaver>carif: I've never tried to install inside a VM; I don't know what issues arise. <mark_weaver>amz3: I don't know the details, but ISOs have a different boot mechanism. not grub, but rather ISOLINUX. <mark_weaver>since everyone uses USB sticks, it shouldn't matter anymore, except for the fact that everyone knows how to boot an ISO image and other kinds of disk images can be more difficult.. <carif>mark_weaver, well with a little bit of futzing it appears doable. Looking at the email archive, others have managed too. It's a good way to "kick the tires" if you don't have a spare pc lying around. <carif>i was handicapped a little by learning qemu-img/kvm/virt-manager in parallel. <carif>fair enough, even that's dear <carif>ah, so I fumbled the boot device in /etc/config.scm. I needed to change '/dev/sdX' to '/dev/sda' and didn't do so. Therefore the grub2 install part failed. <carif>cirno9, so yes, I *did* do something wrong <mark_weaver>yenda-: he definitely has Scheme in mind, which he co-invented. <carif>so when I log into the session manager as my username 'mcarifio' with the correct password, what should I see afterwards? icons? a terminal? <mark_weaver>or at least the Scheme standards. the actual implementations usually have much more batteries included <mark_weaver>carif: it depends what window manager you're using. if ratpoison, then just a blank screen <yenda->on wikipedia it says he helped define star lisp <carif>mark_weaver, only used by celebrities <carif>ok, looks like I'm using 'ratpoison' and I do get a blank screen, ty <mark_weaver>it's a lot like "screen", but with Ctrl-T as the default escape char <dmarinoj>Yes. It will bring up a list of commands and the keys that they are bound to keys prefixed by C-t (control with t) <carif>dmarinoj, awesome, yup got it <daviid>mark_weaver: off topic, should i send the g-wrap [which is a non gnu project] release email to info-gnu@gnu.org? asking because it is an essential component to guile-gnome[clutter] which are gnu projects ... don't know <daviid>mark_weaver: i guess not, someone can forward it later anyway, sorry to bother you with that. <mark_weaver>daviid: I'm not sure, but I suspect it's not appropriate to post a release announcement for a non-GNU program to info-gnu <mark_weaver>bdwgc is an essential component to guile, but bdwgc announcements aren't posted there either. <daviid>yeah, agreed, i did not [just sent it], tx <davexunit>ACTION waits on newly built world downloads so he can wget the soon-to-be release image <davexunit>mark_weaver: I recently pulled master and got all the core-updates stuff <davexunit>so I'm just waiting to download a bunch of stuff again. I threw in a few other package updates while I was at it. <paroneayea>I wonder if we could have a flag so that if a package install flails, guix drops to a debugging prompt <paroneayea>that would realllly help me with working on packages-in-progress <paroneayea>I think with guile's trap tools, should be possible... <mark_weaver>well, civodul is the one to ask, but I suspect that the daemon does not support two-way communication to the build process inside the build container. <mark_weaver>the entire thing is designed to isolate the build from anything outside. <paroneayea>mark_weaver: so wrapping the code in some kind of "drop to debugging" would have to happen in the derivation itself <mark_weaver>and after being manipulated in arbitrary ways from the outside, we wouldn't want the result of that build to end up in the store. <paroneayea>mark_weaver: sure :) well, it would be for developers only :) <mark_weaver>also, the build probably will lack tools you need for debugging, such as gdb or strace or whatever. <mark_weaver>anyway, this is a discussion that should happen with civodul present and engaged. email might be best. <mark_weaver>I agree that something like this would be good, I'm just not quite sure what it should look like. <mark_weaver>we have "guix environment" to create an environment fairly close to the build environment. <mark_weaver>and we have the -K option to keep the failed build directory. when needed, I usually chmod -R that to my user, create a shell with the environment variables used in the build (by running "env -i $(which bash)" and then "source environment-variables". <mark_weaver>but I agree that we could use some more polished tools for this. <paroneayea>mark_weaver: I'd love a way to reproduce that :) <rekado->wow, nice comment in the sources of "radium": "qtractor does this. Check later what this is." <rekado->I'm done with this. I'll fork radium and clean it up. <rekado->It's an unpackagable, unbuildable blob. <amz3>rekado-: you do create music? <rekado->rekado_: yes, for some interpretation of the word "create" :) <sir123>It's supposed to be on line 10:2 <sir123>I can't for the life of me figure out why it won't make <amz3>sir123: I think the last line has an extra parens? right? <mark_weaver>sir123: you need to wrap the arguments list within another layer of parentheses, and put a quote in front: (arguments '(#:phases ...)) <mark_weaver>sir123: also, the parentheses are not balanced in the 'arguments' field. the entire rest of the package description is *within* the arguments field, as you have it now. <sir123>Looking at the other packages, that's what I assumed was correct <sir123>I keep doing make clean and make -j12 to remake, is there a faster way to test if it works? <sir123>I try to do another make, but it claims all packages are done so I'm puzzled <mark_weaver>if this is a new file, it needs to be added to gnu-system.am <sir123>the documentation doesn't mention that <mark_weaver>that's true. would you like to propose a patch to the docs? <rekado_>it's an attempt to fix the build of OpenBLAS on MIPS; a lot of packages cannot be built on MIPS because OpenBLAS cannot be built. <rekado_>would be nice if this could be fixed. <rekado_>Unfortunately I don't have a MIPS machine myself. <civodul>rekado_: me neither, but i second your effort! <davexunit>ACTION removes the disable-container-tests phase from guix-devel <effa>Hi, I'm trying to package a program whose tar doesn't generate it's own directory, but puts files in the current directory. I need to patch the source and I find that, as soon as you have a 'patch' field in 'origin', guix tries to generate a new patched tar. The problem I'm having is that it chooses the first directory in the current directory as the location of the source and only include the chosen directory in the patched tar. In <effa>this case the chosen directory is 'dir' and is empty, while the source is in 'src'. I've tryied with a snippet, but the source directory appears to be chosen before the snippet is run. Any suggestion? Thanks! <davexunit>bah, the container tests fail when building guix-devel. guess I'm gonna leave that phase active for now. <davexunit>well, they should be skipped on computers that can't run them, but they fail on my computer that can run them. <davexunit>so I'll have to investigate that when I have more time. <davexunit>time for the work day so I can't explore any more right now. <civodul>i think we just can't handle such tarballs for now <civodul>you *could* work around it by prodicing a custom 'method' for the origin, though <effa>what about an horrible hack and 'setq' the variable directory in a snippet? <civodul>you can't even do that because the snippet runs in a different module :-P <civodul>using a custom 'method' seems best currently <civodul>basically, write a procedure akin to 'url-fetch' of (guix download) <effa>and then I use it in 'method' or origin? <effa>will patch still be applied, or will I have to handle them in the new method? <civodul>effa: you use it as the 'method' field of the origin, in lieu of 'url-fetch' <effa>where should I best put such a procedure? <civodul>just above the package would be fine <effa>ok, I will try that. Thanks! <civodul>we'll put it in a better place later if the need arises <svetlana>I mean having an iso would make it possible to try a live cd out of the box. I am sure it is planned at some release I just don't know when. I'm not sure why I'm asking either as I don't yet have the hardware so it's more of a theoretical question. <civodul>USB slots are more common than CD players now <yenda>browse with icecat and you realize how few of the web is entirely <DusXMT>yenda: Not completely true; many scripts just don't have librejs-compatible license declarations <DusXMT>yenda: For example, in the past, browsing the Free Software Directory would raise the "Non-free javascript" flag <DusXMT>Also, on slower systems, LibteJS is incredibly resource-hungry and makes web-sites load _so_ slow... while NoScript makes them faster, and you select which sites you trust and which you don't <mark_weaver>rekado_: I'll try the OpenBLAS patch on MIPS. thank you! <mark_weaver>gst-plugins-base fails several of its tests on both MIPS and armhf :-( <mark_weaver>effa: you'll have to do something similar to what we did for mit-krb5: make your own custom 'unpack' phase. <mark_weaver>well, a custom origin 'method', as civodul suggested, has the advantage that 'guix build -S' would work as expected. it's the better solution. <mark_weaver>(sorry, I should read the whole backlog before responding) <mark_weaver>ACTION uses LibreJS, but has a few sites whitelisted, and sometimes has to temporarily turn it off completely. <yenda>I just turned it off I'm not ready yet :D <effa>mark_weaver: thanks for the suggestion! I'm using civodul's method it's working :-) <mark_weaver>rekado_: openblas builds on mips with that patch, although with no test suite I don't know if it works. <civodul>alezost: could you make sure to push the man-db & co. patches real soon? :-) <davexunit>I'm a qemu n00b, how do I boot the guix installer image in a vm. perhaps I should just build my own with 'guix system vm' <civodul>qemu-system-x86_64 -enable-kvm installation-image -hdb foo.img <civodul>and foo.img must be an image for the target disk <davexunit>civodul: so do I pass the disk image to 'qemu-img create'? <yenda>pip for python 2.7.6 is not available in guix packages ? <yenda>also is there a reason for python2 to be stucked at 2.7.6 ? <davexunit>we can try bumping to the latest, but that will of course require rebuilding lots of packages <yenda>isn't hydra rebuilding automatically anyway ? <yenda>yes because it's different, new version of python 2.7 have pip included which comes really handy for developpment. Isn't the whole point of guix to allow you to have different versions ? <civodul>rekado_: since OpenBLAS has 43 packages depending on it, could you wait until after the release to commit it? <rekado_>mark_weaver: the tests are run as part of the build phase. <yenda>what would be the best current alternative to use python2 and pip on guix ? <rekado_>I guess having "#:tests? #f" there is confusing. <rekado_>mark_weaver: if it builds that means that the tests have passed. <rekado_>civodul: when is the release? It's this week, no? <mark_weaver>rekado_: on mips at least, I don't see any output that looks like testing. <rekado_>that's a failure in running the tests. <civodul>rekado_: tagging later today, and officially releasing tomorrow <mark_weaver>rekado_: oh, interesting. I see nothing like that in the new build log. <rekado_>There should be output like "Test of subprogram number 1" and the like. <mark_weaver>I don't see anything that looks like a test suite running <mark_weaver>however, running 'file' on the build library looks like it's the right architecture. <mark_weaver>yenda: if you change the package bound to variable 'python-2', then you will have to rebuild a *lot* of stuff that uses it. however, if you make a new package, inheriting from 'python-2' but with a different variable name, then it won't force rebuilds, since it won't be the one that is used as build inputs for other things. <mark_weaver>yenda: our python 3 package inherits from 'python-2', so you can see an example of inheriting. <mark_weaver>just inherit 'python-2', and override the 'version' and 'source' fields. <mark_weaver>I would start by copying the 'source' field from 'python-2', with just the hash updated to match the tarball for your chosen version. <davexunit>yenda: 2.7.10 has a built-in pip? that's nice. <davexunit>though, of course, in guix land you would like guix to be your only package manager ;) <yenda>in guix packages updates are updates of the whole thing rather than patches ? <yenda>mark_weaver: when you go from lets say version 2.4.2.1 to 2.4.2.2 of a package the tarball and hash change. In pacman you only download and apply the diff. How does it work in guix ? <mark_weaver>well, it can be done either way, but as a matter of policy we download the new tarball <mark_weaver>if we chose instead to apply the diff, then the diff would *always* be applied, even for someone building for the first time. <mark_weaver>one of the core principles in guix is that builds are done the same way every time. <mark_weaver>so if they are built by downloading an old tarball and then applying patches, then that is always done for everyone. <yenda>I don't have the package definition in /gnu/, only store/ <mark_weaver>if you want to modify the source code of guix, you need to download it. best to work from the git checkout. <mark_weaver>nothing in /gnu/store must be modified, ever. the proper operation of guix depends on that. <yenda>yes I know I wanted to find /gnu/packages/python.scm <yenda>i want the package definition to create one for python 2.7.10 <yenda>but I'm also looking at guix import it looks like pip is useless with guix <yenda>I'd like to understand how to add packages though because I want to add sbcl and docker <davexunit>but these language package managers can most always be told where to install to <davexunit>for Ruby's gem utility, I just set GEM_HOME as needed. <yenda>pip installs in the virtualenv or globally with sudo <davexunit>yenda: pip + virtualenv should work nicely then <davexunit>I had a pip package written at one point but didn't push it <davexunit>there were concerns about how to make it do the right thing out of the box, which is not trying to install globally by writing to the pip store directory, which it wouldn't be able to do. <yenda>what's the point of virtualenv without pip ? <yenda>usually you get in a project that has requirements, you create a virtualenv, pip install -r requirements.txt and there you go <yenda>python without pip is like (insert metaphor of something that needs somethings else badly) <mark_weaver>yenda: I guess you will lose many of the advantages of guix by using another stateful package manager on the side. <davexunit>'guix import pypi pip' will get you most of the way there <mark_weaver>we have our own tools for creating environments for development. e.g. 'guix environment' which was written by davexunit here. <yenda>mark_weaver: what are the options when you join a project that has requirements ? at least it is contained within the virtualenv and doesn't really affect the whole system <davexunit>yenda: 'guix environment' works just like virtualenv, but for *any* package. <yenda>but for now I only need ccm so I was actually trying to figure out how to guix import pypi ccm, I get "tar xf failed with exit code 512" <davexunit>in a future release it will also be able to do Docker-like things. <yenda>I already have guix on 2/3 machines :) <davexunit>yenda: I get that warning with 'guix import pypi pip' but I still get a valid package snippet printed <davexunit>the thing to note is that it 'guix import' is just generating code snippets for you. <yenda>ok I wasn't sure if it was just a warning or somethign went wrong <davexunit>you still need to copy/paste that snippet in a scheme file <davexunit>and make the tweaks necessary for it to build successfully <davexunit>'guix import' is a boilerplate reducer. it takes as much of the machine automatable work away from you as it can. <yenda>davexunit: where should I put the scheme file ? <mark_weaver>yenda: if you have a built guix git checkout, then put it in gnu/packages/*.scm. otherwise, put it in a new directory and set GUIX_PACKAGE_PATH to the absolute path name of that directory. <davexunit>yenda: in this case, it would go in gnu/packages/python.scm with the other python packages. <mark_weaver>also, the module name in your file must correspond to its location in the filesystem relative to GUIX_PACKAGE_PATH <davexunit>if you intend to submit this as an upstream patch, that is. <mark_weaver>e.g. a module named (gnu packages foo) needs to be in $DIR/gnu/packages/foo.scm where $DIR is one of the components of GUIX_PACKAGE_PATH <mark_weaver>however, I would recommend that you build guix from it's git checkout, to facilitate contributing your work to us, and, if you like, to allow you to make (and easily maintain) arbitrary modifications to your private branch of guix. <mark_weaver>you can use 'guix environment guix' to create an environment that contains everything you need to build guix from git. <davexunit>mark_weaver: and '--with-libgcryptprefix=$(guix build libgcrypt | head -1)', too, right? <davexunit>and then in the future this will be much more straightforward. <yenda>mark_weaver: by buit guix checkout do you mean I'm gonna have to build the entire thing like hydra does ? <mark_weaver>yenda: no, only guix itself (the package descriptions, daemon, and support code) will need to be built <mark_weaver>the packages themselves are not built until you ask to build something. <mark_weaver>and the packages you build with the git checkout will be the same as the ones you've already got (modulo recent changes). <mark_weaver>so, it will take about the same length of time to build as "guix pull" takes. <mark_weaver>but then, you will never have to run "guix pull" again, and future updates will be vastly faster, because 99% of the time you can just run "git pull && make" <yenda>is GUIX_PACKAGE_PATH suppose to be a global variable ? <yenda>I can do the whole build at user level ? <mark_weaver>when you run a 'guix' command that builds anything, that's what's happening. <yenda>and when exactly do I put "--localstatedir=/var to configure and '--with-libgcryptprefix=$(guix build <mark_weaver>yenda: oh, yes, when building guix from the git checkout, you are doing that the old way, manually. <mark_weaver>within the subshell spawned by 'guix environment guix', cd into the git checkout, run "./bootstrap && ./configure --localstatedir=/var --with-libgcrypt-prefix=$(guix build libgcrypt | head -1) && make" <mark_weaver>maybe add a -j<n> to that "make" command, where <n> is the number of cores you have <yenda>ok thanks for the help I have to leave, I'll do all of this tomorrow <alezost>civodul: I'm going to push man-db commits now; isn't it too late? Also I would like to push "gnu: Add sox." patch I sent about a week ago, I've just tested it again (with the latest packages) and it worked. Is it ok? <civodul>alezost: that's fine for both, go ahead! <mark_weaver>civodul: when do you expect to cut the release? when should I plan to build an armhf binary tarball? <civodul>alezost: i was thinking it'd be great to have some sort of C-M-x that would build the package at point <mark_weaver>I'm currently building all of the things in my usual profile on armhf. <civodul>mark_weaver: i expect to tag within 3 hours, so building the tarballs after that <davexunit>I haven't been able to test the installation image yet, unfortunately, but I see that several people have reported that it works for them. <civodul>did i foget anything important in NEWS? <civodul>i had forgotten emacs-build-system, i've added it locally <davexunit>I didn't spot anything that I was involved with <davexunit>are he improvements to 'guix publish' listed? I don't have the source in front of me right now <mark_weaver>civodul: I don't see --do-not-upgrade mentioned anywhere in NEWS, although I don't remember if I added it before or after 0.8.2 <mark_weaver>hmm, making the binary tarball on armhf seems to have triggered a build of glibc. <mark_weaver>maybe because this is the first time I'm building a profile in the new core updates, which entails building glibc-utf8-locales, which I guess is based on a different glibc than the "final" one. <davexunit>mark_weaver: I could've sworn that running 'make PREFIX=/foo' didn't work for hoedown, but I must have done something else wrong. <davexunit>the Makefile explicitly sets PREFIX to /usr/local or something, I didn't realize that it's only interpreted as a default <mark_weaver>davexunit: variable settings passed to make on the command line override what's in the Makefile <mark_weaver>see section 9.5 (Overriding Variables) in the GNU Make manual. <ryouma>ACTION pops in to gauge progress on guixsd <ryouma>i'm just a leecher here, hoping everybody else will do the hard work, in my place, of creating a distro and make it good enough and popular enough that i can switch to it from debian, at which point i will contribute like a normal person :) <davexunit>ryouma: jump in the pool, the water is fine. <ryouma>what kind of booting does guixsd use? i have been frustrated by debian's grub and update-initramfs setup <yenda->tonight my goal is to switch to vanilla kernel <yenda->at least linux-libre made me realize how much hardware makers suck <ryouma>what do you do if you run guixsd and your video card doesn't work because the free driver no longer works for some moronic reason, or if you need the guest additions for virtualbox (which are in contrib in debian for some reason even though there is no nonfree code iirc)? <ryouma>my current problem with debian is update-initramfs; is guixsd's different? <yenda->ryouma: that's my story, you run vanilla kernel with ugly binary blobs <yenda->the graphic cards probably doesn't work because the firmware is proprietary. run demsg you should see "missing free firmware (non-free firmware loading is disabled" <mark_weaver>ryouma: since we have roll-back features, if you discover that the new version of something doesn't work anymore, you can always roll back until the problem is fixed. <mark_weaver>the BIOS used in virtual box can only be compiled with a non-free compiler. <mark_weaver>civodul: I just successfully built a binary tarball for armhf. not the final one, but I wanted to make sure I was ready to go. <civodul>i'm about to tag, if distcheck goes well <mark_weaver>ryouma: Guix is the first distro I've used where I could both be on the cutting edge, and also have a stable system that I can depend on. <ryouma>so non-free loading can be enabled? <davexunit>we do not support kernels with blobs, though. <mark_weaver>ryouma: GuixSD is 100% free software, without blobs. however, you can maintain your own private packages, or more generally, any modifications to guix in your private git branch. <ryouma>is the pm git based in some way? <davexunit>well, the guix source is maintained in a git repo <davexunit>but the packages themselves are just scheme expressions <mark_weaver>the most flexible method is to build and run guix from one's own private branch in git. <davexunit>so you can make your own package defintions easily <mark_weaver>you could also periodically merge upstream master into your branch, if you prefer. <yenda->I was ready to give up my gpu for guix, but even my onboard gpu has proprietary firmware so I don't have much choice until I have the money to change it. And since I would like to convince other people to use guixsd, I don't see myself telling "btw buy a new pc first" <mark_weaver>a less flexible method that some people might prefer is to put private package definitions in a private directory and set GUIX_PACKAGE_PATH to include that directory. <ryouma>yeah i will not buy a new video card until i get a computer with a free-compatible card (like presumably intel cpu onboard is the most likely to be compatible). (as it is now, wheezy free works, but jessie free does not.) <mark_weaver>civodul: I vaguely remember learning that ocaml includes camlp4, but maybe I'm misremembering. <yenda->but as mark_weaver told be the other day intel is the worst because even though the gpu might be free compatible at the system layer, the bios is not at all right ? and the northbridge chipset as it's own firmware with internet access ? <mark_weaver>however, we've managed to get the Thinkpad X200 and some similar machines working without that subsystem. <mark_weaver>there are some newer AMD boards that can run without proprietary blobs. <mark_weaver>but at present, intel graphics accelerators are the best option in the free world, it seems. <civodul>mark_weaver: the new version no longer does <ryouma>yeah, i think the thigns to try to avoid are amt, vpro, and maybe (but i am not sure) txt. but i heard amd has similar stuff though. (note: i'm ignorant.) <mark_weaver>it's a feature intended to allow tech support staff of a company to diagnose problems with employee machines over the internet <mark_weaver>toward that end, an independent processor that can access the network, regardless of the host OS, and iirc even when the machine appears to be off. <mark_weaver>the #libreboot folks managed to get the X200 working without that stuff. <davexunit>civodul, mark_weaver: do you have ideas about what we could do to visualize how many of our packages are fully reproducible, like how reproducible.debian.net does? <mark_weaver>davexunit: yeah, it would be good to make progress on that front. <civodul>given a big machine, we run a program that builds every package twice and compares the result <mark_weaver>I guess the most obvious idea I have is to build everything independently, compare them to what's on hydra, and make a list. <mark_weaver>civodul: I don't think it should be the same machine building both. that will miss a lot of issues, like dependencies on kernel version, hardware, ec. <davexunit>so, let's say there's N machines that build everything and we check if all N produce exactly the same thing <davexunit>we could then produce a time series of the progression (or regression) <mark_weaver>ah, I was just about to push fixes for libsbsms on non-Intel, and notice that the 0.8.3 is already there. I'll wait :) <rekado->civodul: tuxguitar has been broken on x86_64 for a while now. I suspect I'll have to build it with icedtea rather than GCJ. <ryouma>i thought the big thing with nix was that it already hashed configurations. is this only at source level then? <mark_weaver>ryouma: I don't understand your question. Guix uses a slightly modified Nix daemon, and is based on the same concepts. <ryouma>mark_weaver: it's a question based in ignorance, perhaps, but i thought nix controlled enough elements to ensure binary reproducibility ootb, thus guix wo8uld also already, but i guess not. in any case glad to see there's an effort to ensure it. <civodul>Nix & Guix have tight control over the build environment, which definitely helps <civodul>but there are sources of non-determinism that are beyond that <mark_weaver>sources of non-determinism that can leak into builds include: the clock, the random number generator, the kernel in use, the hardware details <ryouma>perhaps file metadata like ownership and umask? <mark_weaver>our methods of build isolation should take care of umask and most metadata. <mark_weaver>but the uid/gid of the build process is accessible, and could leak into the build outputs in some cases <civodul>mark_weaver: could you build the armhf tarball from commit 5d09263? <mark_weaver>civodul: looks like it will take about 90 minutes. going afk, but I'll be back before it's done. <civodul>mark_weaver: i can't find the screen of user 'hydra' <mark_weaver>civodul: no, I exited out of it by mistake, and the hydra daemons became orphans. <civodul>well apparently they're happy anyway ;-) <mark_weaver>I need to set the shell option on that shell to not exit on Ctrl-D <civodul>i wanted to stop the queue runner to get all the CPU to build the stuff on mips