<lfam>Jookia: What are test plans? <lfam>I don't think Guix knows either. It just runs the commands in e.g. a Makefile, according to whichever build-system is selected in the package definition <Jookia>Well, it knows enough to run them while I can't :( <lfam>You must study the relevant Guix build-system and the package's build system. After a certain point there is no escaping this :) All the Guix tools were created by people who studied existing build systems and abstracted them for you <mark_weaver>alezost: I guess we should change our example configs to use "en_US.utf8", both because that suffix is needed for other locales and because of the (surprising) problem that myglc2 encountered. <Jookia>lfam: Perhaps no escaping it now, in future I imagine there'd be better debug tools <Jookia>mark_weaver: I get locale errors when using en_AU.utf8 <Jookia>Well, gdk-pixbuf seems to use the standard gnu build system's check phase :\\ <lfam>I would increase the silent time and set it running in the background, while digging in to what a "test plan" is and how gdk-pixbuf's test system works in the foreground <Jookia>lfam: This would be a lot more helpful if parallel builds worked <kristofer>how can I customize ./configure options for grub in my system definition? <lfam>Jookia: What do you mean? <Jookia>lfam: Guix never seems to build two packages at once <Jookia>mark_weaver: What should I set it to? <mark_weaver>set it to the maximum number of build jobs you want to run simultaneously. <Jookia>I've set it to two before but it doesn't seem to care <mark_weaver>ah, I have a vague recollection that our 'guix' client always overrides those options, and so maybe you need to pass that option to the 'guix' build commands. <mark_weaver>Jookia: btw, I should note that by default, Guix passes -jN to 'make' when building things, so that parallelism is done for each build. <mark_weaver>when you run too many things in parallel, the overheads associated with limited cache sizes tends to decrease efficiency. <mark_weaver>there are always several phases of builds (and sometimes the entire builds) that can't be run in parallel, e.g. 'configure'. <Jookia>I understand- I'd just rather use all my CPU time <Jookia>So if a test was going to take hours I could do something else in the meanwhile <lfam>But I believe I will need to provide the paths of inputs at build time. Is the best course of action to do something what's done in the mumps package? <lfam>...something *like* what's done in the mumps package? <kristofer>should I modify the package file in /root/.config/guix/latest/gnu/packages/grub.scm? I'm pretty ignorant to the guix package conventions <Jookia>kristofer: I think you should override the package somehow- not sure how <kristofer>there is a #configure-flags argument.. is there a way to pass configure flags in my system definition? <lfam>#:configure-flags refers the "./configure" scripts used in the GNU build system. What are you trying to configure in GuixSD? <kristofer>I need to configure grub with --target=i386 --with-platform=efi <mark_weaver>kristofer: to change build-time configuration of packages, you need to change the package definition itself. <mark_weaver>kristofer: you can't edit anything in ~/.config/guix/latest/ <mark_weaver>latest is a symlink to a directory in /gnu/store, and guix assumes that nothing in there will ever be modified <mark_weaver>if you do modify things, guix will break in non-obvious ways. <kristofer>what might you recommend for modifying the package? <mark_weaver>to change the definition of the 'grub' package, you should checkout guix from its git repository, build it from source, make modifications there and run guix from there. <mark_weaver>and this is a good idea anyway, because it's the only sensible way to be able to contribute to guix <mark_weaver>kristofer: important note: make sure to pass --localstatedir=/var to guix's ./configure script. <mark_weaver>see the "Building from Git" section of the Guix manual for more details, but it misses that bit about --localstatedir=/var <Jookia>Can you not specify the path to packages when running Guix? <Jookia>the Guix packages, like guix/gnu <mark_weaver>Jookia: there's a GUIX_PACKAGE_PATH environment variable <Jookia>Ah, yes. Could that be useful when maintaining your own package set? <mark_weaver>see section 7.5 (Package Modules) of the Guix manual. <mark_weaver>although I prefer to instead work and run guix from my private git branch, which allows not only adding my own packages, but making other arbitrary modifications to guix, while still allowing me to easily incorporate upstream changes <Jookia>That sounds like a good way to do it, though I'd still find it annoying not using the 'guix' command <mark_weaver>I use the guix command. I make ~/.config/guix/latest a symlink to my built git checkout. <Jookia>Oh! I thought it was ONLY to the store <Jookia>I'm a little curious why Guix doesn't let you override packages <Jookia>Well, if you could then the GRUB issue would be simple- just override the GRUB package :P <mark_weaver>well, I just told you all how to easily maintain arbitrary changes to Guix. <mark_weaver>just freely edit whatever you want and immediately use it. <kristofer>mark_weaver: is your approach reasonable while using the installation image? <Jookia>Well yes, but overrides are kind of a Nix thing- maybe they're not in Guix? <Jookia>Come to think of it, Guix doesn't have something like nixpkgs/config either <mark_weaver>one warning about GRUB, btw: it's the only package that if you install a broken one, you won't be able to easily boot into an older generation of the system. <mark_weaver>break anything else: the kernel, libc, whatever, and those are all per-generation things. <kristofer>no worries, I'm trying to get it installed on a macbook <mark_weaver>but GRUB needs to stay quite stable. we need to be very careful about GRUB. <Jookia>so many people using macbooks and guix <kristofer>Jookia:I'm trying to install on a macbook now, and this efi issue is holding me back <kristofer>unfortunately I don't have the skills to libreboot <Jookia>It's probably not a Macbook 2,1 or 1,1 <Jookia>Anyways, clone Guix, edit the definition, build Guix, use that Guix <Jookia>Wine, you say? What free software are you running in Wine? ;) <phogg>Wine's notepad.exe. But srsly, non-free games. <Jookia>You should try to get hooked on free software/culture games :) <CompanionCube>ACTION would not want to even think of packaging steam for guix <Jookia>I don't have any graphics acceleration so I get to live without games for a while <phogg>Jookia: I can't count the number of hours I've put into nethack. <CompanionCube>iirc the NixOS people end up using a chroot to get it to work <Jookia>Though once I do get graphics acceleration I'm going back to dungeon crawl <Jookia>I have a hard time engaging the ASCII world <phogg>Jookia: or you could go back to playing hamurabi <Jookia>I could, I've been looking at the bsdgames package <phogg>Jookia: I didn't know it included hamurabi <myglc2>Here is a dumb question... how do I reboot or shutdown my headless guixSD server. 'halt' give me 'error: connect: /var/run/shepherd/socket: No such file or directory' <Jookia>It doesn't I don't think, but it's text-based from what I know <phogg>ACTION plays his own implementation when he feels nostalgic <Jookia>Angband might be good but I'm not sure if there's a free version around <myglc2>lfam: `sudo -i halt` gives the same result. The top of pstree is 'dmd' <Jookia>myglc2: Did you just update Guix? <lfam>myglc2: I had that same issue in a VM. I ended up killing the QEMU emulator. It's worth an email to bug-guix@gnu.org <myglc2>Its been running a couple days w/only minor changes. <lfam>It happened when I upgraded from dmd to shepherd <lfam>The transition was not smooth <mark_weaver>myglc2: this is a one-time problem having to do with the change from dmd to shepherd. <myglc2>That is what I was hoping and why I was trying the shepard commands <Jookia>If dmd's running, perhaps you could check an old profile for the dmd binary and use that to halt <myglc2>I can go in the next room and reboot the machine. Is there anything I should do before I do that? <mark_weaver>myglc2: /run/booted-system/profile/sbin/halt might work <myglc2>OK now dmd has disappeared sheperd is on top... WOW! <myglc2>And now halt works, but you knew that... <kristofer>should I modify the grub package before I bootstrap guix from git? <kristofer>bootstrapping guix from git I'm getting error: possibly undefined macro PKG_CHECK_MODULES, GUILE_MODULE_AVAILABLE <davexunit>kristofer: you don't have ACLOCAL_PATH set correctly to find guile's autoconf macros <davexunit>kristofer: do you already have 'guix' available to you? <rekado>"guix import" is the preferred way, but we don't have enough Ruby packages in Guix yet. <rekado>using "guix import" and contributing the package expressions to us would help, though. <davexunit>kristofer: okay, then the recommended way to produce a guix development environment is via 'guix environment guix' <davexunit>this will spawn a shell in which all of the dependencies needed to build guix are available. <kristofer>wow, the guix environment [package] is powerful <myglc2>when I do 'guix system reconfigure config.8.scm', does guix cache a copy of 'config.8.scm' somewhere? <mark_weaver>it's up to you to manage that file, maybe in a version control system. <mark_weaver>or at least, keep a backup copy of a known-working version <kristofer>tests/lint.scm passed.. make test seems frozen now <kristofer>does it usually take awhile to make test guix from git? <mark_weaver>kristofer: yes, some of the tests take a long time. be patient :) <mark_weaver>kristofer: it would be good to report the details to bug-guix@gnu.org, but for now I wouldn't worry about it. <mark_weaver>it probably has to do with things needed for the "guix environment --container" or "guix container" functionality <Jookia>I'm starting to think the reason these tests are going so slow is that there's constant swapping and I'm having an IO bottleneck <Jookia>Very low CPU usages, very high swap usage and iotop seem to confirm this hypothesis <mark_weaver>Jookia: I have a vague recollection of some security flaw in gdk-pixbuf found recently having to do with large images that resulted in integer overflows, and that along with the fix, some tests were added that involved huge images. <Jookia>mark_weaver: well, this is taking up quite a lot of memory- perhaps under the 4G mark but over 2G <Jookia>mark_weaver: Unfortunately I need to find a way to up the RAM ***necronian_ is now known as necronian
<Jookia>mark_weaver: I'm not sure if it's a single test or more than one. On top of that, is disabling tests a good idea? One could argue 4GB minimum is a good idea for building <mark_weaver>IMO, the requirements for building packages that are needed for a typical desktop setup should be buildable on a typical desktop machine. <Jookia>Is 2GB of RAM a typical desktop machine? <Jookia>Though, back in 2009 I had 4GB on my high-end desktop <mark_weaver>Jookia: I don't know, but actually I'd prefer for such packages to be buildable on machines that are modest by today's standards. <Jookia>Hmm, would build machines limit resources to 2GB then to enforce this? <Jookia>I like the idea of 4GB maximum given that's the maximum of a 32bit ARM chip like the Novena <mark_weaver>Jookia: that's only a per-process maximum, and it's actually 3GB iirc <Jookia>I'm running 4GB on my Novena right now somehow- yeah, 3.6GB max <mark_weaver>and we wouldn't have to enforce such a limit specially, because our builds for 32-bit machines run in 32-bit mode. <Jookia>I'm planning to do that this month <Jookia>I'm getting use to Guix building + bootstrapping through my T400- I'm unsure if it's more or less powerful than the Novena given it only has two cores <Jookia>Does this account for parallel builds? <mark_weaver>For those of us who don't want, within our machine, a second all-powerful supervisor CPU running a complete proprietary operating system, with direct access to all system RAM, the CPU, BIOS configuration, disks, network connection (such that communication is possible in both directions without the host CPU even being able to see that traffic), etc, both Intel and AMD appear to be dead ends. <Jookia>This is true :) Low power is good too <mark_weaver>machines like Novena, with free board level design, hardware chosen based on the availability of free hardware documentation, and as friendly to free software as possible, are the only hope I see for the future of freedom in computing. <mark_weaver>it's important to support such work, so I felt strongly compelled to vote with my dollars and support the Novena project. <Jookia>I see! I do wish one day we'll have a free FPGA on a board like this- though the future does look bright in that area <Jookia>The Libreboot X200 has a minimum of 4GB <Jookia>Well, that's what francis sells them with :P <mark_weaver>The term "Libreboot X200" does not just refer to the ones francis sells. <Jookia>Sounds good to me, that system has a minimum of 4GB when buying. The only devices I can think that would have lower RAM would be things like Chromebooks? <mark_weaver>or old Thinkpad X200 machines that have been converted to use Libreboot. <mark_weaver>I don't want to make life difficult on people who have older hardware. to be honest, I'm one of those people, so I suppose I'm biased. <Jookia>Me either, but it'd be surprising if 2GB of RAM could build things like IceCat <mark_weaver>Jookia: it can. I know because I've recently done it on my Libreboot X60 with 2GB of RAM. it wasn't even that painful. <mark_weaver>Jookia: the key is disabling debugging symbols in the build, which we do. <Jookia>mark_weaver: Oh really? Maybe it's just this test. Could you try building gdk-pixbuf <zacts>I'm hoping to switch full-time to GuixSD soon <mark_weaver>Jookia: C++ debugging information tends to be very large, at least for some styles of programming. <zacts>my last attempt was close, but I forgot part of the install process to get grub-install to work with gpt <zacts>then I got busy with life and school <zacts>and I needed something right away, thus I'm on Debian 8 <Jookia>mark_weaver: gdk-pixbuf is actually required by GRUB's background image surprisingly <zacts>I'm gradually using emacs a bit more. I'm like a vimmer who is a closet emacser <zacts>I want to use emacs, but I still use vim by habit. <zacts>anyway, /me idles until I find the time this week to hopefully try again <mark_weaver>Jookia: I know, it's for converting the guix grub logo from rsvg to pixmap. <mark_weaver>Jookia: actually, we use *inkscape* of all things to do that conversion. <Jookia>That explains the inkscape dependency, which I thought was a little odd <mark_weaver>Jookia: this was very painful for me on the Lemote YeeLoong, which is a very underpowered MIPS-compatible machine to put it mildly, and where I have always refused to use substitutes. <Jookia>Why refuse substitutes? Stubborn like me? <mark_weaver>Jookia: I tried to change it to use rsvg-convert from librsvg, a much simpler program, but it failed to render the rsvg correctly. <zacts>oh, also.. I want gnu guix laptop stickers eventually <mark_weaver>Jookia: I wanted to make security a higher priority on that machine that on others. because of its relative simplicity, non-updatable CPU, etc, it seemed a good fit for that. <Jookia>mark_weaver: Ah, I build for dogfooding reasons. I feel like if the common person can't build Guix, it'd be a form of centralization-by-accident <zacts>oh how are reproducible builds coming along, have you guys made much progress towards that goal? <mark_weaver>zacts: there has been some progress, yes. we've been gradually finding and fixing sources of non-determinism, and we have tools now to make it quite easy to test for non-deterministic builds, e.g. by running builds multiple times and comparing the outputs, and challenging substitute servers by verifying that your local build matches what the substitute server gives you. <Jookia>Reproducible builds are more of a brute force thing <Jookia>I wonder if it'd be sensible to put all Guix packages on a HDD and sell it, or perhaps all the source- Whichever is lighter. Surprisingly, not everyone has an Internet connection. <mark_weaver>Jookia: the problem is, the build outputs become out-of-date too quickly to make such a mechanism for distribution practical <mark_weaver>it would be far too expensive for users to keep up-to-date that way, and old binaries with security holes are not of much interest. <Jookia>Perhaps a stable branch of Guix would be a good idea, especially for people that want to compile on slow machines? Grafting could help lessen this problem <kristofer>I am building guix from git! The tests have been running for awhile.. in fact, the last one test completed was lint.scm, almost 3 hours ago. Does that seem normal? <mark_weaver>what kind of machine are you running on? how much ram? <mark_weaver>fwiw, I wouldn't feel the need to run the full test suite at this point. <kristofer>I just ran make test.. I honestly don't know the convention to run from git.. <kristofer>I'd guess adjust some symlinks, but otherwise I don't really know how to use guix <mark_weaver>kristofer: just prefix the commands with "./pre-inst-env", e.g. "./pre-inst-env guix build emacs" <mark_weaver>while sitting in the top-level directory of the source tree <kristofer>I'm trying to modify the grub package to use gpt/efi instead of the mbr <mark_weaver>and after you see that it works, you can make ~/.config/guix/latest a symlink to it, and then you can omit the "./pre-inst-env" part. <mark_weaver>kristofer: so then, just make the changes to the 'grub' package and try "./pre-inst-env guix build -K grub" <zacts>I wonder if builds could be proved to be non-deterministic via something like what is taught in the book The Little Prover (from the Little Schemer series of books) <zacts>(since most of Guix sounds to be a functional paradigm) <mark_weaver>the -K asks to keep the failed build directory if the build fails. <zacts>like using deductive logical proof methods, along with the actual emperical testing of such things <zacts>but I'm a total novice here... <mark_weaver>I always use -K for untested packages, e.g. when I'm modifying or adding a package, so that I can debug in case of failure. <zacts>I'm just recently learning that reproducible builds even exist, and I only recently learned the lingo 'reproducible builds' <Jookia>kristofer: Make sure to set the state dir <mark_weaver>zacts: build systems are very complex, too complex for such proofs to be practical at our current abilities. <zacts>I'm thinking something like a DSL similar to coq for Guix <zacts>(my apologies for these novice questions then... :-P) <mark_weaver>in theory, build systems could be a lot simpler, and written in such a way to make such proofs easy, but in practice packages use build systems based on vast amounts of shell code, and it's a mess. <zacts>oh so do the shell ./configure && make scripts add state? <zacts>that adds too much complexity? <zacts>with the variable amount of options you can set for those <mark_weaver>autoconf was specifically designed to make use of the tools that would likely be available on any unix-like system. <zacts>mark_weaver: this might be an interesting research avenue for someone like me though <mark_weaver>the configure scripts that it creates are basically a portable bootstrapping mechanism. <zacts>to see how I can improve the correctness of a system like guix in terms of non-deterministic builds <zacts>what about working around the autoconf scripts? <mark_weaver>and because unix-like systems all have something like a bourne shell in practice, and programs like grep and ls and sed, etc, those are the tools that are used by configure scripts. <zacts>and makeing a guile version of mini-autoconf / mini-gnu-make? <zacts>so just bypass make and autoconf altogether <mark_weaver>and all of those tools are very complex and imperative in nature, with lots of state, etc. <mark_weaver>for purposes of writing proofs, I guess it's difficult to prove things about that. the behavior of the tools aren't even precisely specified. <zacts>like guix could provide a vagrant-like environment with all the tools so to speak. Kind of like a virtualized env <zacts>and then guix doesn't even use the Makefiles <zacts>it has a mini-make in guile scheme, that configures everything <zacts>I hope this even makes sense <zacts>I'm trying to communicate an idea, but I don't know how well I'm doing at it <mark_weaver>zacts: I can sympathize with your desire, believe me. but there are many thousands of packages that are needed on a modern desktop system. <zacts>so avoiding Makefiles is not feasible? <mark_weaver>well, many hundreds at least, and thousands that are needed in a distro to satisfy users <mark_weaver>it's not that it's not feasible, it's just that it's too much work for a small group like us to accomplish. <zacts>ah I see... so that would be tons of work. (lol) cool <zacts>mark_weaver: well maybe I can research solutions in this direction <zacts>on the side, if they are useful then cool! otherwise, at least I'll learn a ton <mark_weaver>zacts: if you want to accomplish that goal, here's what you'd need to do: convince most developers to switch over to such a system. that's the hard part. <zacts>well I mean at least we may not have a perfect system, but I can improve guix to be _better_ than it was before <zacts>mostly for a self educational process <mark_weaver>there might be another way: write tools that are able to automatically convert typical packages using autoconf/automake/etc. <zacts>I'm just fascinated by this kind of idea of not needing to rely on a central package builder for trusting packages <zacts>at least maybe a core could use this <zacts>so you could have a core system that is truly reproducible <zacts>and then other packages might be a bit less non-deterministic <mark_weaver>such a tool would never be able to handle the general case, but maybe you could get away with only converting a subset of the cases, if such a subset covers a large enough number of packages. <zacts>indeed, so maybe I can help with a subset of those cases <zacts>like if I get a single gnu package on guix to be truly reproducible, that would be a great learning experience for me <mark_weaver>zacts: still, I'm not sure how much that would buy us. <zacts>(maybe dmd, or something don't know) <zacts>mark_weaver: probably it would buy me more than the project. For educational reasons. <zacts>but I would also be contributing in other more useful ways at simultaneously <zacts>this would be a side project for me <zacts>but I'll let you guys guide me with what makes the most useful sense too. <zacts>please steer me away from hitting my head over and over on a brick wall! :-P <zacts>regardless, I need to install a full GuixSD system first this week <zacts>then I'll look at improving and porting new packages <zacts>I'm just day dreaming a bit here... (from my newbie excitement of all these new concepts) <mark_weaver>zacts: well, to be honest, I'm not optimistic that anything useful would come of that. if you're asking me how I think you could be most useful, I would say that you should spend at least a third of your time doing less ambitious work that's helps us in the short term, like packaging software that we need or solving problems that are biting users today. <kristofer>when I ./configure guix what should the prefix=? <mark_weaver>I can certainly sympathize with thinking big and wanting to make a groundbreaking contribution, don't get me wrong. <zacts>mark_weaver: heh, I'll take your advice here. I'm thinking more like in the next year or two for these brainstorms. I guess I'm also asking so I even understand these concepts in the first place. <zacts>I sometimes do get ambitious indeed <mark_weaver>but it's easy to fall into a pattern where you spend most of your dreaming about what you will do some day, but never actually accomplishing much of anything. <kristofer>it's looking for /usr/local/var/guix/daemon-socket/socket, which doesn't exist <lfam>krisofer: usually it's /var/guix <zacts>that's probably also from being quite academic too. Anything seems possible in the academic world. <zacts>but then you hit reality, and other libs and interactions you have to work with <mark_weaver>zacts: I've found that a reasonable compromise is to allocate at most a third of your available hack time on "blue skying", as it is sometimes called. <lfam>I think one has to spend some time "in the trenches" to know what problems need to be solved <zacts>so 2/3's real work, and 1/3 brainstorming... <mark_weaver>I think it's good to think big, but IMO it's good to balance that with more short-term practical work. <zacts>indeed, well I'll bbl. I've got to get something to eat. My stomache rumbles. Also, this conversation is getting probably a bit off-topic by me at this point <mark_weaver>I see Guix as a project that could eventually become radically more sophisticated and advanced than it is now, but it will never get there if it dies because not enough people do the practical work today to make it an attractive system for people to use. <mark_weaver>kristofer: you need to pass --localstatedir=/var when configuring guix. <mark_weaver>kristofer: well, more generally, you need the localstatedir to match your existing guix install, and both GuixSD and our binary installer use /var as the localstatedir. there's where the database of packages lives. <kristofer>lfam: just to clarify, prefix=/var/guix? perfect <kristofer>I typed up the other message a few minutes ago... had to make a bottle for the baby <kristofer>do I need to startup a new guix-daemon after building from git? <mark_weaver>I wrote that localstatedir (usually /var) is "where the database of packages lives", but that was unclear and perhaps misleading. <mark_weaver>it's the database that stores metadata about the set of entries in /gnu/store <mark_weaver>the set of package descriptions is not centralized at all, and are not known to the daemon either. <mark_weaver>they only live on the client side, and each user on the system can run their own copy of guix with their own set of package descriptions, their own build systems, etc, and they can all share a single daemon, which works with lower level descriptions called "derivations". <mark_weaver>kristofer: you can use the same 'guix-daemon' that you already had running. <mark_weaver>it's usually okay to run a very old 'guix-daemon' and it doesn't matter. <zacts>I also see how the documentation on install instructions could be improved <zacts>hopefully patches from me in the somewhat near future <zacts>I don't want to keep saying I'll do something, and then it doesn't happen <zacts>so I'll say, when my patches are posted that will rock, hopefully <Jookia>localstatedir should be /var/gix by default <Jookia>Is there a HTTPS clone for Guix? <mark_weaver>Jookia: no, localstatedir is /var, and then guix uses $localstatedir/guix <xd1le>mark_weaver: i think git cloning via the https protocol <mark_weaver>xd1le: we have the 'git' package, and it supports cloning via https. <xd1le>mark_weaver: as in i think Jookia means for the guix repository itself <xd1le>(but i didn't read previous discussion) <Jookia>Cloning by git:// isn't useful for Tor users <Jookia>(You're going to hear a lot of Tor whining over the next month) <kristofer>any pointers for building and installing grub for efi instead of bios in my system configuration? <Jookia>kristofer: You're on your own but I can maybe help push you in the right direction? <kristofer>my process has involved cloning guix from git, modifying gnu/packages/grub.scm (#:configure-flags --target=i386 --with-platform=efi) <kristofer>currently attempting to ./pre-inst-env guix system init /mnt/desktop.scm /mnt <kristofer>which might not even make sense, I'm not really sure what to expect from grub upon completion, if it makes it at all <kristofer>I'm also wondering how I might just use the kernel as a bootloader. I checked out the configuration and it includes EFI_STUB_whatever. I have never loaded a kernel that way before though.. still doing research <Jookia>Kernel as a bootloader would be interesting, but you still need the BIOS to load the kernel <Jookia>Woo I got git:// working over Tor <Jookia>Guess who's going to be building Guix over USB2 external drives :| <Jookia>I have 16G of free space in the install I'm using- any tips for turning this in to a cache? <sneek>Welcome back civodul, you have 2 messages. <sneek>civodul, alezost says: ahem, something went wrong with renaming: I've just tried to boot a system (on commit 171a0a1) and got "kernel panic". The same system on commit 6d97319 boots successfully. I don't even know whether the problem in shepherd itself or I introduced a bug to guix source :-( <sneek>civodul, alezost says: nevermind, I got a wrong swap-devices in my system config. I never noticed it with dmd, but with shepherd I got kernel panic <Jookia>civodul: Perhaps it's not needed- I just found I could free up 60G if I delete some photos and music <civodul>sneek: tell alezost the wrong swap/kernel panic story is weird <sneek>alezost, civodul says: the wrong swap/kernel panic story is weird <lfam>I never knew sneek could be used to give a message to someone _now_ <lfam>The package definition for python-passlib sets PYTHON_EGG_CACHE to /tmp. Is that a safe choice? <civodul>sneek: later tell alezost the wrong swap/kernel panic story is weird <sneek>civodul, civodul says: he's dumb <Jookia>Making room on an SSD to build Guix is sure 'fun' <lfam>civodul: What is your workflow for examining non-deterministic builds? Do you have a clever way to keep the results of multiple rounds? <Jookia>"network-interface-names" tst fails on my machine <civodul>lfam: i use --rounds=2, and if things go wrong, then i enter "manual mode" :-) <civodul>manual mode is: i build once and save the result with "cp -a" somewhere <civodul>then i "guix gc -d" the thing and rebuild <civodul>and finally i use diff or diffoscope on the result <lfam>Okay, that's exactly what I've been doing. <lfam>I noticed that there have been a lot of updates to diffoscope. <Jookia>What does this mean: "(lset<= string=? names (all-network-interface-names))" ? <civodul>'lset<=' tests whether one set is included in another <civodul>so it says whether 'names' is a subset of (all-network-interface-names) <lfam>diffoscope has been updated to use python-3 according to pypi. I'll try updating it tomorrow. <Jookia>Is there a guix repl command or something that can give me a Guile that can (use-module (guix build syscalls)) ? <Jookia>My virtual ethernet doesn't show as an interface <civodul>Jookia: the REPL command is called 'guile' :-) <civodul>so you can run guile, and from there: ,use(guix build syscalls) <Jookia>Guix is doing some strange stuff - it's ignoring an interface in /proc/net/dev <civodul>ACTION has to go afk for a couple of hours <Jookia>Can a regex wizard fix " (make-regexp "^[[:blank:]]*([[:alnum:]]+):.*$"))" to allow dashes? <Jookia>Done, I think I have my first patch <efraim>the diffoscope update needs some new packages to be packaged <Jookia>Would replacing 11 characters with 2 require a copyright header change? <efraim>I have a Pentium4 with 1GiB of ram, and 20GB IDE drive and a 320GB SATA drive, if I make the 20GB drive all swap and make /tmp a 10 GiB tmpfs, will that work out well enough? <Jookia>efraim: a 20GB IDE drive won't be able to replace RAM <efraim>yeah but the ram in the box is maxed out and that's what I have <Jookia>Well, you could try- why not use an ext4 partition as /tmp ? <sneek>suitsmeveryfine, you have 1 message. <sneek>suitsmeveryfine, lfam says: I have to leave. Good luck! <Jookia>Wasn't there a project for using GPU RAM as RAM <civodul>i'm jealous: GNU Hurd is on Phoronix and we're not <efraim>we get mentioned in the hurd article <civodul>davexunit: i was under the impression that major distros were largely absent from the distro track <davexunit>civodul: it is upsetting to hear that red hat wants to lower the importance of distros to being a docker host. <civodul>maybe they're trying different strategies in parallel <civodul>beta-test emacs: guix build emacs --with-source=ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-25.0.90.tar.xz <davexunit>someone already complaining that you don't have to provide a checksum <civodul>yes, it's not authenticated, which sounds curl|sh-ish <civodul>we should fix it, we have everything to do so ***piyo`` is now known as piyo
<davexunit>your slides always look great, too, civodul. <davexunit>I don't know how you guys find the time to make things so unique and cool. <Phlogistique>I was surprised by the sheer number of Guix talks at FOSDEM <davexunit>I wonder if rekado's HPC lightning talk generated any interest. <davexunit>Phlogistique: it sure helped to have a devroom dedicated to Guile for half the day ;) <Phlogistique>indeed; though they had a Guix talk in the microkernel room I think <Phlogistique>(Otoh Nix had only one talk, about porting it on Genode too in the microkernel room) <Phlogistique>also Guix was feature prominently in every reproducible build talk <civodul>Phlogistique: i'm surprised there weren't more NixOS talks though <Phlogistique>yep, though he said that he did not really know about it and he needs to look into it <Phlogistique>maybe next year there could be a "functional package management" room <davexunit>nix and guix teaming up in a dev room sounds like a good idea. <Phlogistique>or "new-ish approaches to package management" to include Snappy and friends <davexunit>mark shuttleworth gave a lightning talk about Snappy <civodul>fun, that's the room i was in on sat. :-) <civodul>but i think lightning talks were on sunday <davexunit>civodul: how did the distro dev room folks react to your talk? <civodul>i think they liked the frozen pizza ;-) <civodul>there were a number of questions, which is nice <davexunit>civodul: I loved the frozen pizza analogy, and I only read the slides! <civodul>rekado & i came up with this analogy this summer <civodul>Phlogistique: which devroom was that? <civodul>niksnut & i met him (i guess?) at the reproducible build summit <Phlogistique>What he wanted to says was "please use structured and documented metadata in your package format" <Phlogistique>he said that both Nix and Guix use code to describe package, so it is not a structured format, so I told him about drv files <Phlogistique>which is not exactly what he meant with "structured format for package metadata" I guess. <taylan>some amount of custom code seems inevitable in many package recipes, sadly <davexunit>Phlogistique: that sounds like not a great idea. <davexunit>we derive great value from data and code being the same. <Phlogistique>davexunit: yeah, what they do in the end is that they put shell code in a YAML file. I am not sure why they think it is awesome <civodul>an object is just data that's already been parsed <civodul>doesn't Vagrand use shell in yaml as well? <davexunit>Vagrant is configured using a Ruby file, thankfully. <Phlogistique>davexunit: yes. at some point they had the build tool automatically update their recipes, but they do not do that anymore <davexunit>I think the search for a cross-distro standard for packaging is a fool's errand. <Phlogistique>I think they have not heard about lenses tools such as Augeas, which would probably help them <davexunit>what works for Debian could not work for us, vice versa, same for other distros. <davexunit>the container community are also clammoring for a standard format for containers. <davexunit>the idea that containers are a *thing* to them and not just a runtime environment is scary, but even if they agree on a standard, Guix could never follow that standard. <davexunit>because their standard will be based around disk images, which Guix containers do not use. <_`_>Why does guix even have to care about a container standardization fueled by docker? <davexunit>I was trying to point out what I feel is a futile effort to standardize these types of things. <_`_>I don't think there really is a “container community”, just docker's unwarranted ubiquity due to an influx of sysads who are foolish enough to run `curl|sh` everything. <davexunit>_`_: LXC, rkt, and other folks are trying to fight Docker's ubiquity and want interoperability <davexunit>but, much like the FHS, whatever standard they produce would surely be unusable by Guix. <_`_>Docker's efforts at standardization are less about standardization and more about declaring omnipresence, imo. <nee`>I'm just lurking most of the time <pizzaiolo>oh apparently I was already subscribed to you <_`_>davexunit: more lxd than lxc. Even though they're by the same people lxc wouldn't benefit from any type of standard format. lxd might. ***Digitteknohippie is now known as Digit
<davexunit>civodul: we need to add xwidget support to that emacs pre-release testing command. <davexunit>but you can actually open an emacs buffer with a webkit widget in it now <civodul>webkit is still a bit scary to me ;-) <davexunit>webkit is scary, but widgets in general is cool <civodul>i had seen a demo at the GHM in 2013 or something <rgrau>davexunit: do you know if there's any kind of interaction possible with the webkit browser (from elisp) or it is a black box? <davexunit>civodul: did you happen to see my email with the awscli patches? <davexunit>I'm curious what your thoughts are about it. <civodul>davexunit: no, haven't caught up yet <davexunit>I will definitely wait for you before applying the patches. <davexunit>basically, I have packages a client for the amazon web services api, and I'm unsure if its acceptable. I know of two other free software projects (eucalyptus and openstack) that implement parts of this API for compatibility, but I'm still not sure if that's good enough. <davexunit>the majority of the patch set is not controversial, however. <alezost>I noticed that there is no /dev/disk on GuixSD anymore (I swear it was there in the past) <sneek>Welcome back alezost, you have 1 message. <sneek>alezost, civodul says: the wrong swap/kernel panic story is weird <alezost>indeed, I got it because (swap-devices '("/dev/disk/by-label/swap")) didn't work :-) <alezost>can anyone on GuixSD check if they have /dev/disk ? <bavier>alezost: I don't see a /dev/disk on my guixsd <alezost>bavier: thanks for confirming. I wonder why it disappeared <bavier>I don't recall the last time I did a system reconfigure on this machine <myglc2>did guix pull and reconfigure yesterday, no /dev/disk here either <mark_weaver>alezost: I also used to put (swap-devices '("/dev/disk/by-label/jojen-swap")) in my config, and had to revert to using /dev/sdaN because /dev/disk went away <alezost>mark_weaver: same for me; do you know why there is no /dev/disk anymore? <mark_weaver>we currently use kernel configs from jxself, and he tends to sometimes change his mind about how to configure things <mark_weaver>it's possible that it was due to something he changed and we picked up <mark_weaver>maybe something was built into the kernel and then became modularized, and we need to add the module to our initrd, or something. <alezost>mark_weaver: thanks for the explanation! I didn't think about potential changes in a kernel config <mark_weaver>alezost: actually, it might be udev's job to populate that directory, so maybe that's where the problem is. <lfam>So, the upstream 'file' package has some Python bindings that can be built, and are a dependency of the current version of diffoscope. I wonder how best to build these. They will require the python-build-system. <lfam>Should I try to shoehorn multiple build systems into the file package? Try to build them with an ersatz "trivial" build system in the file package? Create a separate package? <lfam>Or perhaps it is enough to just copy the files somewhere and do wrap-program "by hand"? <NiAsterisk>anyone used guixsd with libreboot around here? I discovered that my screen might be supported now and I could go to one of the local hacker labs to dump&flash it. were there libreboot specific "beware of this when using guixsd" notes already? I know somebody worked on an cryptdisk instruction.. <davexunit>NiAsterisk: I think it's pretty straightforward if you aren't doing full disk encryption <davexunit>I installed GuixSD on a Libreboot X60 last year and I didn't have to do anything special <NiAsterisk>okay.. nothing about GRUB or anything? and if I would it would be obviously according to the notes <davexunit>there might be something GRUB related, since Libreboot has its own GRUB built-in. <davexunit>I defer to those that actively use Libreboot machines to give further advice. <davexunit>I simply can't remember much about my experience, I'm realizing. <NiAsterisk>thanks! would #libreboot be trafficed by guixsd users? or should I simply wait for someone else to reply? <davexunit>they might know a thing or two about it there, from what others have reported. <davexunit>they might at least be able to tell you a bit about GRUB <NiAsterisk>I'll give it another try. I wanted to do this a year ago. <davexunit>I want to ask the libreboot folks what my best option is for a motherboard that can be used for a media center PC. <NiAsterisk>this t400, last generation which could run libreboot etc, intel based with no amd gpu, runs 1080p okay iirc. <lfam>I thought maybe it is fine to keep using the old diffoscope, but I'm hitting what seems like a bug already :( <lfam>Oh, that's not it. `cp -a` did something unexpected. It copied a tree without updating the internal symlink references <lfam>How close do you sit to your TV? ;) My opinion as a projectionist is that resolution only matters when you are within a foot or two <lfam>The quality of the compression is what really determines picture "quality" <NiAsterisk>davexunit: do you have a /boot/grub/libreboot_grub.cfg on your system generated by guix? <davexunit>NiAsterisk: I don't have any libreboot machines. <NiAsterisk>oh, okay. then you installed it for someone else. sorry <davexunit>NiAsterisk: oh yes, I forgot this detail! my bad. I borrowed a Libreboot X60 from the FSF. <davexunit>I borrowed it to make sure one of the first Guix releases where GuixSD could be used on bare metal actually worked. <NiAsterisk>If I can get libreboot running here, I can get wifi without the 9db antenna external usb dongle with the cable plugged into usb. which is not a bad thing, but annoying because the usb connector part is in the way. <NiAsterisk>well I could also try to just hack the bios whiteliste, but would be happier with lb <lfam>It's part of fdisk, right? <kristofer>I thought so.. I have fdisk, but I don't have gdisk <efraim>according to debian, gdisk is its own package, but gnu-fdisk has fdisk and {c,g,l}fdisk <kristofer>i'm trying to figure out how to make a hybrid mbr/gpt setup <lfam>Where can I learn about the Guix builders' environment? For example, what time is it? Is there a /tmp? Thinks like that? Is it documented in the manual somewhere or should I use the source? <lfam>There might be a timestamp getting into some .pyc files <lfam>Hm, I see that python-2 sets a variable to prevent that. I wonder if that is not happening with python-3, or if I am having some other issue. <lfam>It looks like our fdisk only installs bin/gnufdisk <myglc2>Should I use mcron/sheperd to run updatedb? Or is there a better way? <myglc2>By better I mean, e.g. run it after each guix pull instead? <m_kim>Hello, I just update GuixSD (previous update was Jan 16) and get Kernel Panic after "udevd[...]: Starting version 3.1.5". Problem was related to incorrect swap partition. When I boot previous system state and perform "mkswap /dev/sda2" new system become bootable. Previous system was configured also with swap and displayed swap related errors during boot. <alezost>m_kim: I also got a kernel panic because of a wrong swap. I think it's a shepherd (our init system) bug: dmd (our previous init system) wasn't so sensitive to such errors <rekado>davexunit: re slides: Thanks! I made them with Inkscape, one file per slide. <rekado>I don't enjoy trying to bend LaTeX into shape, so I don't usually use beamer. <alezost>myglc2: currently there is no any "guix way" for updatedb <davexunit>alezost, myglc2: stateful things are handled in the service layer <davexunit>you could create a service that periodically rebuilds the search index <davexunit>ideally, you would extend the mcron service for this. <lfam>I made a trivial one for my user but it is truly trivial. Not even a stop action. <lfam>It should be extended to use the Guile interface ***JamesJRH_ is now known as JRHaigh
<rekado>plus flags for "male female caucasian indian asian". How odd. <lfam>Indexed by ethnicity??? That's disturbing! <lfam>Created yesterday. I wonder if it is some report of FOSDEM attendees. <lfam>Maybe you can find a website that links to it <rekado>I think so too. Maybe a dump from peta.fosdem.org <lfam>What is peta.fosdem.org? I can't resolve DNS for it <lfam>Whatever it is, why are they making lists of people by gender and ethnicity? I think that's wrong. And then putting it on a public site? <NiAsterisk>oh srly? you must login to report things on pastebin.com <lfam>Somebody who went to Fosdem and knows a lot of people should decide if that's what it is, and if so, ask Fosdem organizers about it. <NiAsterisk>penta.fosdem is for speakers to interact with, or what is it? <lfam>But would they really be collecting that sort of information? I'm surprised anyone would give it to them. <lfam>But somebody, somewhere, either collected it somehow or judged it themselves <lfam>In a few days, the link may show up on other sites through Google <NiAsterisk>assuming won't help. maybe asking fosdem is the best thing right now <lfam>It was just a guess. I don't know if all those people were there or not. <NiAsterisk>maybe it was just public information + stereotypical prejudical additions of a/s/l <Jookia>Did someone make a mistake at FOSDEM? <lfam>I don't like it when people make those kinds of lists. <davexunit>I didn't go, but I was registered as a speaker <NiAsterisk>josé bollo spoke at fosdem (further down the list) <Jookia>NiAsterisk: It's interesting it doesn't include indigenous 'races' <rekado>well, gender is an optional field in penta. <rekado>mine is not listed and I didn't give one in penta. <Jookia>Would anyone actually tell their ethnicity to a conference <NiAsterisk>some people assume(prejudical,stereotypical) ethnicity through names, maybe this happened here. <lfam>It's common to be asked that in the US but I thought it would be less common in Europe <rekado>"I am trying to find our how many men vc. woman and whites vs. people of color are speakers at FOSDEM." <lfam>Sure, let's just share this information on a public site for anybody to copy. What could go wrong? <civodul>yes, and unfortunately we already know the conclusion <davexunit>I have a github account. should I ask them not to share this information publicly? <pizzaiolo>love how he sorts whites from [all the rest] <lfam>I would be careful how you ask. You might end up with your name out there for the wrong reasons. <NiAsterisk>if all goes wrong you could just aks github to handle it? <davexunit>well I worry about being flamed on twitter and such about it. <lfam>rekado found it on pastebin <davexunit>civodul: it sort of is, yes. it's like a paste site that is also a git repo. <Jookia>"please fork it and add more info", I wonder what this is for <lfam>and then traced it back to github.com <NiAsterisk>the text is cut off from the description.. and it reads very unsettling <civodul>but seriously, people find it normal apart from here? <lfam>You have to read the page source. It says "create some graphs." <lfam>Find what normal? Making lists of people by gender and ethnicity and then publishing them? I find that extremely disturbing. <davexunit>on one hand, the speakers appeared publicly at a conference, but on the other hand aggregating it like this weirds me out. <civodul>but there's a risk of being flamed if we say it's not OK to create a file like this? <lfam>I'm very ambivalent about this. <Jookia>It's one of those ethical things where it could probably be handled a lot more responsibly, like using tallying rather than naming people <davexunit>civodul: there are some people that could see someone complaining about this as some sort of oppresive reaction. <civodul>but as you said lfam, it may look "OK" in North America, but not in Europe <civodul>Jookia: yes, and the person could keep it private <lfam>This list would NOT be okay in USA. I just meant that it's normal to be asked your ethnicity on official forms here. It's always okay to leave it blank. <civodul>even if we were all speaking in public etc. <NiAsterisk>even if it was for "some sort of graph" the approach is stupid below BBC History. <Jookia>civodul: True, but they seem to want help- The 'right' way to do this would be to have names in a 'TODO', then the tally and then with each commit wipe off a bunch of names and update the tally <Jookia>NiAsterisk: They're not, they're searching Google fori mages and video <davexunit>I basically try not to say anything publicly about this sort of stuff. <NiAsterisk>you can ask people if you are really interested. <lfam>A tally would be better than a list of names. I wonder how to communicate this in the most sensitive and polite way? <lfam>The other possibility is that this person will tire of the project and abandon it. I think that happens with most personal projects. <Jookia>lfam: Probably by writing a private message. There's a lot of people who haven't been marked so cutting it short now would stop more damage. It'd also make it look less censorey <lfam>I'm not sure the risk to my reputation is worth it. <NiAsterisk>i don't know much about fosdem. I had the feeling that there already is some approach in direction of diversity going on, which should be communicated, as in ,yes there's room for improvement but we know it and are capable of reflecting it on our own. something like this <lfam>Also, I have never done anything with fosdem so I can't even claim a personal stake <NiAsterisk>if I would follow fosdem for some years I could and would comment privately, but I don't so I am not in the position to reflect on this. <lfam>It's sad it still takes so much courage to say "don't make lists of people by race or ethnicity" <NiAsterisk>even if it was just a mental note for the person for this post, it is bad practice to post their assumptions of ethnicity and a/s/l on github publicly <NiAsterisk>I could do it.. but from fosdem itself it would be better I think. I am okay with dealing these kinds of topics, but I have a gap about fosdem and wether I could say their assumptions are right or wrong, the rest is fairly okay to point out why what they have done is not optimal and any person with the ability to reflect would aknowledge this. <bavier>davexunit: I saw your note in #guile about texlive; could we just put '#:substitutable? #f' in texlive's arguments for now? <davexunit>I'll defer that decision to someone else more familiar with the details. <NiAsterisk>my friend and flat mate could send them an email with more professional rooted knowledge, but they are super busy with university currently. <NiAsterisk>I would say redirect it to someone in the permanent staff at fosdem with the gist, the pastebin, the twitter post (https://twitter.com/jeena ) and the blogpost and see what they recommend. <Jookia>davexunit: Do you think /var should be the default statedir when building Guix given how I and someone else have hit the same issue when using Guix in Guix? <bavier>it would be interesting to do some build-time introspection for any given package on whether it would be better to build or substitute <pizzaiolo>civodul: ĉu iu tradukis Guix(SD) al esperanto? <davexunit>Jookia: it's the GNU Autoconf convention for the default prefix to be /usr/local <davexunit>because to do so would be surprising in a different set of ways <davexunit>our documentation must mention this detail, right? <Jookia>I don't think the documetnation mentions the problem of the statedir <pizzaiolo>civodul: tio estas nur por la retejo, ĉu ne? <civodul>davexunit: what was the patch you wanted me to look at again? <civodul>pizzaiolo: no, this is for program strings and for package descriptions as shown by "guix package --search" <civodul>davexunit: but what's the subject of the message? <davexunit>civodul: let me look, thought that was in there. <davexunit>civodul: "[PATCHES] Add awscli and 7 pre-requisite Python libraries." <civodul>i see efraim commented on the technical part <davexunit>I've incorporated most of those suggestions. <civodul>so AWS is basically a hosting service, except that it's programmable and all that, right? <davexunit>it's like Linode, Rackspace, Digital Ocean, etc. <Jookia>A cloud of pollution from big data mining :P <civodul>davexunit: i was trying to know what it really is, so "cloud" doesn't help :-) <davexunit>civodul: you can create new VMs there, setup DNS, create load balancers, and a million other things I guess. <civodul>damn, our web site doesn't mention FSDG <civodul>well anyway, the FSDG has nothing to say about services <davexunit>Eucalyptus explicitly uses the AWS API to make migration easier for people since they can continue to use the same tools. <bavier>speaking of website, is the "expand" link on the package-list page broken for everyone, or just me? <davexunit>if it proves to not be OK sometime in the future, we'll yank it. :) <civodul>bavier: oh right, we were waiting on roelj, who is himself waiting on the gnu.org web folks, which could take forever or more <civodul>roelj: did you hear from them lately? :-) <bavier>that's for the build status icons, correct? <roelj>civodul: Yes, sorry. I received a reply just before leaving to FOSDEM. <roelj>But I'm not convinced that it'll work now. Hold on <roelj>Does hydra.gnu.org use Apache? <civodul>roelj: no, it uses Hydra (the software) with nginx in front of it <civodul>Hydra is written in Perl and it uses "Starman" <roelj>Hmm, the solution given to fix the problem is to add a 'Access-Control-Allow-Origin' to gnu.org. <lfam>There are only two, sorry for the double-post <Jookia>I'm not going to be happy if these involve DNS leaks over Tor <lfam>I'm testing the update now <Jookia>lfam: Wow, that's a painful DH error <civodul>roelj: ok; could you email the details?