IRC channel logs
2015-12-18.log
back to list of logs
<piyo>40G to debian 40G to guixsd the rest to swap and the bootloader <tsyesika>aeva: I know i'm late to the party with this but the US courts ruled you can't be compelled to reveal your password as it counts as self incrimination, i'd stick to a password <tsyesika>ACTION is guessing you already know this but felt like she'd mention it anyway <foreverska>I asked this yesterday but unfortunately my history doesn't go back that far to see if someone responded. What will be the stance on "releases"? <mark_weaver>foreverska: I see your question in the backlog, but I don't understand what you're asking. GNU Guix has released about every 2-4 months. <foreverska>Sorry I'm more referring to GuixSD. You know how with most other distros you "subscribe" to stable/testing/exp etc. <foreverska>Well I guess that's a feature of the package manager. It's just not often distros have a choice in release styles due to their coupling with a package manager. <codemac>Hey - building guix for my raspberry pi, and wondering what the best way is to build the bootstrap binaries was <mark_weaver>codemac: guix won't work on the RPi, because our armhf port requires armv7 with neon, but the RPi is only armv6 <davexunit>RPi2 is ARMv7, if that's what we're talking about, though. <davexunit>mark_weaver: I'm doing a security update for ruby <davexunit>it will require a lot of costly rebuilds because ruby is an input to qt <mark_weaver>yes. I wonder if it makes sense to add it to the existing security-updates branch. <mark_weaver>I suppose it really depends on how many things need to be rebuilt <mark_weaver>I guess not that many things depend on ruby, so maybe it's best to just have its own 'ruby-update' branch. <mark_weaver>and then maybe I'll rebase the 'security-updates' branch onto the 'ruby-update' branch. <davexunit>mark_weaver: just FYI, this is the issue fixed with Ruby 2.2.4 <mark_weaver>davexunit: okay. I remember seeing a mention of a ruby security flaw, but I didn't investigate, so I'm ignorant :) <codemac>mark_weaver: I know our armhf port requires it, I'm attempting to do another port for myself. I don't know how that process works for guix so I thought I'd give it a go for just a "user guix", not gonna mess with the rpi craptastic kernel situation. <codemac>I'll also have an AArch64 board soon which should be fun <mark_weaver>codemac: do you really think it's worth the effort of making a new port just for that fatally flawed and outdated piece of hardware? <davexunit>mark_weaver: 'guix refresh -l ruby' says that 257 would surely be rebuilt <mark_weaver>I say "fatally flawed" because it can't even boot without a huge amount of non-free software. <codemac>mark_weaver: ... it's my time, I'll spend it how I choose. I have one so I thought I'd learn how to port. I'll figure it out on my own. <mark_weaver>codemac: yes, of course, it's your time to spend as you wish.. <mark_weaver>but the other thing is, it's going to take an absurdly long time to build everything on an RPi. probably on the order of multiple weeks of continuous compiling, assuming it even has enough RAM. <mark_weaver>where by "build everything" I mean "build a minimal base system" <codemac>I know I'll need cross compilation, was just looking for help with how to create bootstrap binaries. <codemac>I'd like to be able to depend on guix environments for every computer I use, it'll make my life much happier, so I'm in the "instal it on all the things" mode <mark_weaver>see the "Porting" section of the manual, and search the git history for the commits where I added the armhf-linux port. <mark_weaver>I don't think this particular quest will make your life happier, but maybe I'm wrong. <mark_weaver>and I speak as the person who created our armhf-linux and mips64el-linux ports. <mark_weaver>porting to AArch64, on the other hand, would definitely be time well spent. <codemac>I'm assuming you didn't build them all on the actual hosts no? Or does cross compilation for guix not work the way I imagine? <codemac>I'm trying to balance my desire to run guix on everything with your experienced advice :P <mark_weaver>guix can cross-compile individual packages (although many packages don't cross-compile successfully), but it's very awkware to do things that way. guix is primarily designed to do native compilation. <mark_weaver>so, for both armhf-linux and mips64el-linux, I used cross-compilation only when creating the first iteration of the bootstrap binaries, and from there it was all native compilation. <foreverska>It says "the newest for your distribution" but what does that mean exactly. Who decides what is newest? <mark_weaver>when you run "guix pull", the current state of the 'master' branch in our git repo is copied to your machine, compiled, and ~/.config/guix/latest is made to be a symlink pointing to that fresh copy of 'guix'. <foreverska>So I'm supposed to update packages singularly or is there a way to freeze packages from pulling? <mark_weaver>if that symlink doesn't exist (e.g. if you've never run 'guix pull'), then the recipes used are those that were compiled-in to the current version of guix you're running (i.e. the 'guix' command that you run) <mark_weaver>"guix pull" doesn't actually change any of the software that's installed in your profiles. your profile doesn't change until you run "guix package" and update or install packages. <mark_weaver>it's good practice to upgrade all packages in your profile together if possible, but you needn't do that if you don't want to. <mark_weaver>foreverska: exactly, "guix pull" is like "apt-get update" and "guix package -u ." is like "apt-get upgrade" <mark_weaver>we don't currently have stable branches, but it would be good to have them at some point, where only minimal security updates are applied. <foreverska>Because in the current state if I don't want to break my system I would have to --do-not-upgrade on certain packages every time I -u <mark_weaver>well, we have easy rollback, so if something breaks you can roll back easily and reliably. <foreverska>fair. I may explore this for build environments initially. My only complaint with the releases of debian is they don't always match up with the rest of my team's Ubuntu releases. <foreverska>And I don't feel like installing ubuntu VMs where plymouth is somehow a required component... <mark_weaver>I should mention another way to use Guix that might be useful for you. I never run "guix pull". Instead, I run guix directly out of a 'git checkout'. I maintain my own private branch, periodically rebasing my local patches on top of current upstream master (merging is another option). <mark_weaver>on one of my machines, my branch is mostly frozen and I cherry-pick patches of interest to me from upstream master. <foreverska>If you wrote your own SDL, Guix could theoretically be pointed towards a personal git? <mark_weaver>I'm not sure how "If you wrote your own SDL" relates to the rest of that sentence, but as for the latter part, it's not just theory. On my machine, I run my own private branch of 'guix', stored only on my local hard disk. <foreverska>Sorry *.scm" I was looking at the SDL package when I wrote that. <mark_weaver>the git method is the most flexible, but there's another easier way: set GUIX_PACKAGE_PATH to a directory containing *.scm files with your local package recipes. <foreverska>Certainly a lot less overhead than maintaining an aptitude server. <fps>the nice thing about using one's own git checkout is that you can search through the commit history <fps>in a sense the git revision history spans another dimension in the list of packages.. i someone at some point in time packaged a particular version of something <fps>you can put it in your /gnu/store <fps>maybe the guix tools should embrace that to a larger extent? i.e. guix package -A foo would not only search the current package definitions, but all there ever were? <fps>this is also related to another thing that irked me a little bit about guix's package definitions: <fps>many of them are quite flexible, almost functionally depending on a version string :) <fps>but then that's not exposed as a function :) <fps>but the version field is fixed in a particular commit <fps>looks like a lost opportunity to me <fps>i'll post my musings to the ML, maybe someone else finds them entertaining :) <fps>s/i someone/if someone/ <fps>yohohoho, it's christmas time, have you all been nice? <efraim>native-search-path didn't work for gccgo-5. for next time i looked at gcj and i'll be adding -Wl, -rpath=$(libdir) to the makefile <efraim>i tried adding lib to RUNTIME using native-search-paths but it didn't work for me <efraim>looking at gcc.scm more I probably should've tried with libdir instead <efraim>but i looked at the package definition for gcj, which involved patching the makefile to add glibc/lib to the runpath so it links correctly, which is what I need for gccgo <efraim>/gnu/store/yz1gpp326fwmjgg03ii464k9l94zyc5h-gccgo-5.3.0/libexec/gcc/x86_64-unknown-linux-gnu/5.3.0/cgo: error: depends on 'libgo.so.7', which cannot be found in RUNPATH ("/gnu/store/qv7bk62c22ms9i11dhfl71hnivyc82k2-glibc-2.22/lib"), and for gccgo-5.3.0/bin/{go,gofmt} <efraim>no, its part of getting go into guix, so its only on my machine atm <efraim>gccgo-5 provides go-1.4, which bootstraps go-1.5 <efraim>gccgo-4.8.5 provides go-1.1.2, which can build go-1.4 to build go-1.5, and that seems a bit too much <civodul>ah, we already have gccgo, but the older one, right? <efraim>anyway, gotta go for a bit to the store <civodul>ah you want to bootstrap the "real" Go with GCC, i see <efraim>much better than downloading their bootstrap binary <tsyesika>civodul: hey, paroneayea said that there is a campaign for a new server, outside of the US <tsyesika>civodul: is there any info anywhere about it? my main curiousity is where it'd be hosted <wingo>tsyesika: civodul mentioned a possibility of hosting at a local co-op in bordeaux; we could also ask switch.ch, which hosts some nix-related things <rekado>efraim: RUNPATH patching worked for me with GCJ; there used to be a similar problem. Have you tried a similar phase as GCJ's "add-lib-output-to-rpath"? <rekado>efraim: never mind, I just read your message where you say you'll try this next. <rekado>updated Julia to 0.4.2 (required lots of changes), but the tests time out and I cannot see why :( <tsyesika>wingo: okay, i wonder how much bandwidth guix uses, probably a fair amount <tsyesika>well anyway, i'd be willing to donate money to the cause of not having the server in US depending on the country chosen <wingo>what countries are on your evil list? <tsyesika>that's a good question, i'd prefer none of the 5 eyes nations (US, UK, australia, new zealand and canada i think) erm other than that i suppose others are fine <tsyesika>that's not to say others are good, it's just i wouldn't withhold donations for servers in those countries <tsyesika>they seem to have pretty terrible survallance laws iirc <tsyesika>i donno, i'd have to look up what the choice country is but i'm more or less going to have the same requirements of most in here i think <tsyesika>the main issue i have is the NSL in the US <tsyesika>so anywhere would be an improvement more or less <Steap>tsyesika: there are no free countries :( <fhmgufs>I onlx read no repositorys found. The other files work as normal. <tsyesika>Steap: it's difficult to find countries which respect one's privacy, indeed <Steap>tsyesika: one might argue that, by nature, the State is always a dictatorship :) <tsyesika>Steap: I am not such a person :P I love government, i just think there are lines although I don't think this is a good channel for general political ideology discussions <fps>tsyesika: did you get your packages downloaded during install? <fps>tsyesika: if not you might try pulling the substitutes from my little substitute server instead of hydra <fps>so i can hackz all your boxen and stealz all your accountz :) <fps>oops, that must have been my subconscious taking over <kmicu>‘fps came not to bring reproducible builds, but to bring cyber warfare.’ ― ancient scrolls. <fps>yeye, i also use a quantum computer to break all ze hashes <fps>so challenging that server will gain you nothing :) <rekado>just a heads-up: I've started to dump a couple of R package recipes to the ML. We will release a new pipeline soon and I need to make sure that all dependencies are available via Guix. <rekado>the packages are all pretty simple, so reviews shouldn't be too hard. <rekado>"we" is the bioinfo group I'm working with. <rekado>I'm getting tired of the physical aspect of computers so I'm moving more into using and making software. <civodul>so Guix will be part of the pipeline, or just a way to install the pipeline? <rekado>it's not very complicated but there are many dependencies that are difficult to install otherwise. <rekado>somebody said "...docker..." and then I just had to show them that we really don't need and don't want docker for this. <rekado>of course we could also offer a mock docker file that sets up guix and runs "guix package -i the-pipeline". <civodul>or make sure Guix is on everyone of their machines ;-) <Steap>rekado: if you can convince people that they do not need Docker, you've got sick communication skills :D <Steap>Heard about CORBA, but that has always been a thing of the past to me <Steap>"seems nice, but people use something else" <civodul>Steap: untrue; pretty much everyone here uses it <rekado>Steap: for some reason people trust my judgment on this matter. I didn't even have to try to convince them. I guess it helps that I've been doing little else but package stuff for Guix for the past year. It just works for us. <civodul>anyone know if gfortran has a specific search path env. var., or if it honors C_INCLUDE_PATH or something? <davexunit>someone is working on making deb/rpm packages for software at work. Docker is the build tool. bleh. <davexunit>the hoops we have to jump through to package things seem so... archaic <davexunit>working through this project is a good reminder of just how good we have it with guix <davexunit>I don't have to worry about which tool to use to do build isolation (docker, vagrant vm, something else) <davexunit>I don't have to worry about the issues around running 2 apps that require different ruby versions <rekado>civodul: re gfortran: sorry, I don't know. <civodul>rekado: on closer inspection, it's simply CPATH <civodul>davexunit: you could do the same thing with Guix and do a side-by-side comparison ;-) <davexunit>civodul: the problem is that there's *lots* of Ruby libraries to package <davexunit>I have a coworker here that is also interested in using guix <davexunit>but we'd got a consult working on our packaging stuff <davexunit>the gmp-bugs discussion isn't going all that well <kmicu>ACTION ’s TL;DR ⸮ ‘You are rude if you criticize rudeness publicly. It’s ok to be rude when you are tired, m’kay. Core contributors have a privilege to be rude, m’kay. You are not from our tribe — go away.’ Original issue not addressed. ¯\\_(ツ)_/¯ <civodul>well Niels is genuinely trying to address the issue <civodul>but he thinks it's a personal issue, and that all i want is an apology <rekado>does anyone here have some practical experience with maven and these pom.xml files? <rekado>I try to read them but don't understand. <rekado>do mavens just mean different things by the word "dependency"? <rekado>or is this a declaration of circular dependencies? <rekado>I'm beginning to wonder whether we could replace maven with a simple java/maven-build-system. <rekado>maven will download dependencies. <rekado>it also does dependency resolution, trying to figure out compatible versions based on constraints in the various pom.xml files of all dependent projects. <davexunit>I wish I knew more about java build systems to help <rekado>ah, these "dependency" tags are part of "dependencyManagement", i.e. they tell *other* projects something about the modules provided by the package. <rekado>that's different from plain dependencies, apparently. <rekado>so, in the case of modello, the only dependency is junit. <fps>btw: it's a general rule i found that critique is best formulated privately, even in response to a perceived rudeness <fps>otherwise the other person cannot back down [depending on "maturity"] <fps>and i fell into the same trap :) ignore :) <davexunit>the result of this thread is that the GMP devs don't see a real issue with what happened and we won't be receiving more help trying to fix the potential bug ludo saw <mark_weaver>well, there are two separate issues here: (1) the bug itself, and (2) the rude response <mark_weaver>even if there is no acknowledgement from them that (2) is a problem, I don't see why we couldn't make progress on (1) <mark_weaver>although in practice, it may be that they won't work on (1) because they are turned off by the discussion of (2) <mark_weaver>that remains to be seen, but I guess we should submit a proper bug report as they requested and see what comes of it. <davexunit>I have a feeling that they aren't going to be too motivated to work with us <davexunit>or help us do things "the right way" in a way that isn't sending us a "let me google that for you" link <lfam>Maybe I will try it as a holiday gift to everyone :) <bavier>would be nice if it played a nice crackling sound sound to go with the flame <lfam>bavier: pull request? ;) <mark_weaver>it's as if the #:hide (zlib openssl) in the (guix licenses) import in (gnu packages linux) is somehow not being honored, but it worked for me and hydra was able to evaluate this jobset in the past, before I rebased it onto the 'ruby-update' branch. <mark_weaver>I have to go afk for the rest of tonight, and tomorrow will be a full day of child care as well, so I won't be able to investigate this soon. <lfam>mark_weaver: Do you know if anyone is working on the recent grub2 CVE? If not I'm going to test the patch and submit it tonight or tomorrow. <mark_weaver>lfam: i don't think anyone else is working on it. if you'd like to do it, that would be very helpful! <lfam>It will be my introduction to GuixSD. Thankfully the vulnerability works in VMs :p <mark_weaver>lfam: I'd like someone to test it on a bare metal machine before installing the update though. <lfam>mark_weaver: Fair enough. I'll see about digging an old i386 laptop out of the pile. <mark_weaver>it's very important that we don't break grub. if we break any other package, users can generally select an earlier generation of our system in the GRUB menu to recover, but if we break grub itself, then that might not be possible. <lfam>Yes, that's why I'd like to start in a VM <mark_weaver>lfam: but if you post a proposed patch, maybe someone else can test it. I'd expect it to be easier to find someone willing to test it than someone willing to prepare the patch. <mark_weaver>I can't do it because I use Libreboot, which includes its own GRUB burned into the boot flash. I don't use the GRUB that Guix provides. <lfam>mark_weaver: Well, I'll be sure to send it to the list. <civodul>mark_weaver: we've had that warning in (gnu packages linux) for a couple of weeks <lfam>civodul: Feel free to ignore my updated Lua patches for the time being. I'm getting close to a working Prosody package and that can serve as the true test of the Lua patches. <civodul>lfam: noted; though i didn't mean to ignore them :-) <civodul>lfam: let me know when you think i should look at it again <lfam>I didn't perceive that you were ignoring them. I just don't think they are worth studying right now. <rekado>lfam: thanks for working on prosody! <lfam>rekado: You're welcome! It's been slow...