<reepca>I just went ahead and typed out what I had on my desktop system, seemed faster than installing git, cloning, and modifying. Also seemed faster than looking up how to download just one file from a git repository.
<reepca>now I just need to find where firmware.scm is on this system...
<mark_weaver>it should be in /gnu/store/*-guix-*/share/guile/site/2.0/gnu/packages/firmware.scm
<mark_weaver>but fwiw, I would recommend downloading our git repo and building it, so that you can more easily and flexibly play with guix
<reepca>that firmware.scm doesn't have the patch applied for some reason
<mark_weaver>it's probably old. have you run 'guix pull' or equivalent?
<mark_weaver>if not, you're probably running 0.11.0, with all the package descriptions as they were at the time of release.
<reepca>I haven't run guix pull on the system since installing it about an hour ago, but I init'ed it from a system freshly compiled with the patch
<mark_weaver>reepca: the issue you're facing is that every version of 'guix' installs an older version of itself, unfortunately. that's because 'guix' contains the sha256 hash of the source code of every package in it. and we cannot build a source tree of 'guix' that includes the hash of itself.
<reepca>I'd probably switch to that setup after I've learned enough to use guix as my main system (I read somewhere that guix doesn't do dual-booting well?) and can have it on my more-reliable laptop hard drive.
<mark_weaver>catern: (although to be clear, I'm not proposing to add support for this to guix itself)
<mark_weaver>catern: it's just my best idea so far of how to allow you to hack it without getting burnt :)
<catern>mark_weaver: I just want to check that this suggestion isn't totally misunderstanding of Guix: We could completely change the direction of Guix and instead of baking-in paths with hashes, we could reference hash-less directories and use bind-mounts before running an application to construct a root filesystem which points to the right versions.
<catern>not suggesting that as an actually solution
<catern>(oh sorry I didn't notice you said you were going to concentrate before pasting that)
<mark_weaver>catern: no, that can't work because in general a single UNIX process is built from many libraries, and it can't have all of those different views of the filesystem at once.
<mark_weaver>I don't know of any system that does better in that way
<catern>well... let's see. libraries are in-process so they should be able to function in the same namespace. the place where you might need to cross namespaces is when you invoke another binary. when you invoke another binary, can't you just set up another namespace?
<catern>sorry I really don't want to keep you from the CVE - no need to answer :)
<mark_weaver>I've thought about that, and just trust me, it would be a mess.
<mark_weaver>even if you somehow changed namespaces every time control flow passed from one library to another within an executable (which would be massively expensive), you'd end up with weirdnesses like this: when you try to 'ls' a directory that's in a namespace that's different for everyone, it would be anyone's guess which view of showed you.
<catern>i had one idea for briding between namespaces: you could (with some hacks I have ideas on) separate the /root/filesystem/referenced/with/absolute/paths from the current/working/directory/referenced/with/relative/paths
<mark_weaver>it might show you what the system wants the 'ls' code to see, namely what it was meant to link to, etc.
<catern>since programs generally look up resources in absolute path directories, and you can pass relative paths for interactive things
<reepca>question... if I have a file firmware.scm in, say, /root/, and I pass --load-path=/root/ to guix system reconfigure, and in my config.scm I have (use-package-modules firmware), should it use the firmware.scm in /root/ or the one it was built with?
<mark_weaver>anyway, this would be a fundamentally different design from guix, from the ground up. if you want to play around in that space, feel free, but I think you'll find it's a rats nest.
<mark_weaver>reepca: you need to pass --load-path=DIR where $DIR/gnu/packages/firmware.scm contains your modified version. and $DIR should not contain any other .scm files.
<mark_weaver>so using /root/ is a bad idea, better make a dedicated directory for this.
<mark_weaver>e.g. create /root/guix-modules/gnu/packages/firmware.scm and pass --load-path=/root/guix-modules
<mark_weaver>(in general, a module that contains (define-module (foo bar baz) ...) will be looked for in $DIR/foo/bar/baz.scm where DIR is in Guile's load path)
<mark_weaver>and (use-packages-modules foo) loads the module named (gnu packages foo)
<reepca>it doesn't seem to be working... I have /root/guix-modules/gnu/packages/firmware.scm, and I'm running guix system reconfigure --load-path=/root/guix-modules /etc/config.scm, wheree config.scm has (use-package-modules wm ratpoison certs firmware), and yet it's saying that it can't find a package defined in the firmware.scm given in the load-path
<reepca>interesting, I set GUIX_PACKAGE_PATH to the same thing (/root/guix-modules) and now it works
<mark_weaver>hmm, I guess maybe --load-path is not honored by 'guix system'
<reepca>reading through 7.5 in the manual it only specifically says that GUIX_PACKAGE_PATH is honored by all user interfaces, is --load-path also supposed to be?
<mark_weaver>it's a "common build option", so it probably should affect "guix system reconfigure".
<mark_weaver>common build options are supposed to be honored only by a subset of our commands, but I guess that's one of them.
<ng0>nothing is wasted if it helps some cause.. in this case, find serious bugs in guix like the shepherd/grub one
<reepca>Hm, so if I init'ed onto this flash drive from a system with a patch applied, and then I reconfigured on that system without explicitly including the patch, it would be reverted, right?
<reepca>In which case I should figure out how to modify service information without recompiling (if that's possible), because ntpd freaks out without a -g flag on my laptop for some reason
<reepca>bavier: I finally got it figured out and got the system reconfigured with the directory b43 renamed to b43-open in the patched firmware.scm, but /var/log/messages has this to say about my latest boot: "b43 ssb0:0: Direct firmware load for /*(DEBLOBBED)*/ failed with error -2".
<reepca>I'll let you think about it while I go eat supper
<lfam>I had read the disclosure of CVE-2016-7543 but I forgot about it :/ I've been busier at work these past few weeks. In the future I'll ping guix-devel when I don't think I can do something quickly enough so that I don't forget about it again
<mark_weaver>my aim is for my system to avoid any references to the old bash, and that's proving to be tedious
<lfam>I have to admit, the prospect of grafting bash is intimidating. I don't think I know all the different bash packages we have
<lfam>If you think I can help you, please let me know
<reepca>I got this message building from git: "ERROR: Missing interface for module (charting)", but it seems to be nonfatal. Wonder what's up with that.
<reepca>I'm having a problem reconfiguring the system using ./pre-inst-env, because pre-inst-env refuses to look at GUIX_PACKAGE_PATH and it doesn't listen to --load-path, but I need it to keep the patched firmware.scm when I reconfigure...
<reepca>guix system reconfigure is *still* running... I hope we manage to fix this without having to recompile the kernel again.
<mark_weaver>civodul: another issue is that (package (inherit p) <overrides> ...) does not apply the same overrides to the 'replacement' field, if any, so I felt the need to add a 'package/inherit' macro for use in several places to handle grafts properly for bash.
<mark_weaver>(package/inherit p overrides ...) expands to (let loop ((p p)) (package (inherit p) overrides ... (replacement (and=> (package-replacement p) loop))))
<mark_weaver>but I've hit two grafting bugs: (1) glib:bin is not getting replaced by the graft of 'gnome-session'
<mark_weaver>so we end up with the grafted 'gnome-session' referencing an ungrafted 'glib:bin' which itself references a bunch of ungrafted stuff including the old buggy bash.
<mark_weaver>and (2) in geiser and emacs-dash, the mapping passed to the grafting includes two entries with the same key: the same old 'bash' store item being mapped to two different outputs: one is a 'bash' with its inputs replaced but with the old 'bash' not the updated one.
<civodul>efraim: we have "freeimage-CVE-2015-0852.patch", which is prolly not the one you want
<efraim>Yeah but I don't have a git clone on my phone (yet) and I haven't installed an ssh client
<reepca>I mean, technically a phone *could* be implemented 100% in hardware... you can only really classify it as a general-purpose "computer" when you try to change its function. Which actually seems pretty hard for phones as far as I know.
<civodul>mark_weaver: i can give the Bash thing a try while you sleep
<jmd>Most linguists consider singular they to be incorrect use of english.
<wingo>certainly some linguist do think that. my point was not to insist on grammar but rather to nudge us towards inclusiveness :) if you personally don't like singular they, fine, "he or she" / "his or hers" etc is not bad. but i think in guix we want to make an environment in which people of diverse backgrounds feel welcome, so we should avoid referring to our users with masculine pronouns. that's all :)
<wingo>back to regularly scheduled complaints about builds not working :)
<ng0>About the gentoo bug we got in debbugs.. apart from VMs, I could try to get yet another laptop and install a native Gentoo-Guix there. The VMs work, but what I miss/can't debug easily (still works in a vm kind of) is hardened-gentoo etc
<wingo>"cycle detected in the references of `/gnu/store/4y5dlv3cvzs6z7a6gcjmy7q07067dwwc-gtk+-3.20.9-bin'"
<ng0>one of my build machines is a huge electricity eater... "Model name: AMD FX(tm)-4300 Quad-Core Processor"
<mark_weaver>unfortunately, you can't use an i5 without also letting their "Management Engine" also run, which runs a proprietary OS with complete domination over your machine, including the ability to respond to requests over the network even when the machine is turned off.
<mark_weaver>(without the host OS being able to see those packets)
<ng0>my temporary roomie is like a busy pidgeon. touring around the country (and also in austria) with poetry slam.. I've seen him maybe 5 times in the last 3 weeks. Now he was here for not one hour until he went on the road again. busy life..
<ng0>why everything is broken and guix is less broken :)
<paroneayea>davexunit: right after "real devops rebuild all the time" I'd also point out there's a value in being able to guarantee that the version of the system you built locally and tested in a VM is the same version that'll run remotely
<paroneayea>oh ok that belongs in "true reproducibility" nm :)
<roptat>rekado, so I added (xfce-desktop-service) to my system, rebuilt it and rebooted, but still no good
<paroneayea>I'd also point out in containers that containers can be useful as an isolation mechanism, but *not* as a packaging solution
<bavier>there must be some points that could be made about why "corporate folks" should maybe still care about reproducibility
<paroneayea>davexunit: also we talked about the "state management" in guixops being writing out scheme files, which I think is good
<paroneayea>davexunit: though I'll also point out that I'm not sure such state management is the only way to go. One way is indeed to "track" the state of machines... but iirc propellor by joeyh has you describe the machines declaratively, and then logs into each machine and checks the state
<davexunit>paroneayea: I think state files are a "bad thing"
<paroneayea>davexunit: so maybe declarative is best (and in fact, if you want a command to "add things via the command line", you can have writing out scheme automaticlaly oh wait maybe this is what you meant)
<paroneayea>davexunit: so, I want to use this for more than just "cloud systems"; I want to be able to update all my home machines with it, for instance, and my router and etc eventually... so writing out a list of all the machines to be updated would be a good way to go
<paroneayea>davexunit: so, it might be possible to do both things.
<paroneayea>davexunit: I might have some time to play with some of this on sunday
<paroneayea>my brother is coming over and he's trying to set up an environment to do some guix hacking, and I'll be seeing if I can do a remote deployment to my new home server by playing with guile-ssh a bit
<paroneayea>I don't expect anything permanent to come out of it, but maybe I'll get a better sense of how things go. Or I can look at your old prototype.
<davexunit>now that we have an openssh service remote deployment should be easier
<lfam>mark_weaver: I'm looking into updating gpgme to the latest upstream version (1.7.0). I'm wondering about the line you added to the package definition which passes "GPG=gpg2" to #:make-flags in e6a83df1.
<ng0>what is the 'package X was replaced by package Y' option called again? any example paclkage i need to look at?
<rekado>roptat: in that case could you try booting into the first system that was installed using the release?
<rekado>roptat: if X behaves differently then it might give us a clue as to what’s going wrong with the latest version.
<rekado>roptat: you should be able to select the first system in GRUB
<ng0>what I want to achieve: "vim" was replaced by "vim-minimal", so I can add vim-all or vim-maximal .. I know that just making vim the vim-maximal would work, but that would affect peoples profiles so I don't know how to do this wothout upsetting all the vim users here
<rekado>ng0: you could also just add a vim-maximal package inheriting from “vim”, no?
<ng0>but then vim would still be vim-with-almost-no-features
<ng0>i don't know memorize much about phone technology. i just know gsm has some flaws
<ng0>read something, and yoz don't need it so it's difficult to quickly recall it
<ng0>like I learned spanish and french but I have a hard time replying
<ng0>the test suite of vim is always fun to watch.. like your editor just crashed and does things on its own
<ng0>deity... poah. I think I need to update vim. https://github.com/vim/vim/issues/1070 what are those version like v8.0.0032 ? can they be used at our side or is this just pre-release? the issue reads like it was fixed in some release after 8.0
<kyamashita>It looks like v8.0.0031 is the current version according to www.vim.org
<rekado>davexunit: re your ops brainstorm document: I always dislike it when people speak of “Turing complete”, because it doesn’t mean much. I guess you can do computations with Puppet if you tried really really hard.
<kyamashita>ng0: Vim version patches are here: ftp://ftp.vim.org/pub/vim/patches/8.0/
<rekado>it only becomes a problem when you are forced to operate in an imperative setting, I think
<rekado>in Puppet I absolutely hate not having proper Ruby at my disposal but only because I’m not really declaring the target state but working around the limitations of an imperative configuration management system.
<rekado>I find it disgusting that I regularly have to run “puppet agent --test” repeatedly for new deployments because the order of declarations matter.
<rekado>after the fourth time it usually passes without errors.
<rekado>arguably that’s because our team is terrible at using puppet.
<rekado>but I think that puppet makes it really easy to give up
<rekado>the worst part about puppet is that I have no guarantees about the state of the system.
<rekado>I cannot just “ensure” that all packages I have not declared are absent because that’s not the same as not having installed them
<ng0>actually.. i think if i understood all of what bash.scm does, vim is similar. they are numbered.
<ng0>but because i don't i think 5 more patches will not hurt the patches dir
<rekado>it’s not reproducible and the solution to many problems is just pouring more junk over the configuration file and rerunning the agent often enough to make it pass without errors.
<reepca>After finally waking up, I see that my guix system reconfigure didn't succeed because something called "gnu-ghostscript-9.14.0" was "410, Gone". I hope this doesn't mean it's going to have to rebuild linux-libre all over again...
<lfam>That test keeps us from building certbot (Let's Encrypt tool)
<lfam>I tried building python-cryptography with python-3.4.5 on core-updates, but then *other* packages started failing, so I made the bug report :)
<lfam>The weird thing is that it fails on core-updates for both python-3.5 and python-2.7. So, either some backported bug fix broke it in both release series of Python, or the problem comes from something besides the Python interpreter
<nckx>ACTION just subscribed to oss-sec, because he's too good for this world and doesn't get too much mail already. Let's see how it goes...
<lfam>nckx: It's not a very high volume, especially compared to guix-devel
<civodul>lfam: re dbus replacement, perhaps we could have set 'version' to "1.1012" (no dot) so make it easier to distinguish it from the vulnerable version
<nckx>lfam: oh good, that was my main concern (though I guess that would have some unpleasant implications).
<lfam>civodul: Can you explain more? I don't get the significance of the dot
<civodul>lfam: now it's possible for a replacement to have a version number different from the original package, as long as the length is the same