<paroneayea>lfam: the situation is so bad that I was unwilling to deliver on my "premium hosting" promise from the last campaign until I knew of a better solution, because even I didn't want to deploy my own software with that state of the world
<paroneayea>and to be fair, mediagoblin made its share of mistakes, amidst a nest of mistakes, because I just *didn't know better*, and nobody was giving me better advice either
<davexunit>that's the way it is until we upgrade our servers
<rain1>clearly guixsd is able to download things somehow, it could be kind to expose that
<lfam>You can easily create your own installation image with `guix system disk-image --image-size=1024MiB gnu/system/install.scm`. So, you can edit install.scm to provide some package in the installation image.
<NiAsterisk>hm.. so I did some changes in a new branch, did guix environment guix , did configure and build inside this branch, left the environment, tried `guix environment --container --ad-hoc emacs-popup -- guix build emacs-popup and I get "emacs-popup package not found" am i still doint it wrong?
<mark_weaver>rain1: but it should also be mentioned that most of what you need to "guix package -i wget" from the installer are things that you'd need to download anyway for the subsequent "guix system init"
<mark_weaver>(assuming that you "guix pull" before doing both of those steps)
<lfam>./pre-inst-env sets up the environment for you
<lfam>NiAsterisk: The reason you got that error message is that you didn't use ./pre-inst-env. Instead, your Guix was looking for emacs-popup in the upstream package database, rather than your git checkout.
<lfam>Also, since using a binary substitute and building from source are transparent in Guix, `./pre-inst-env guix environment --container --ad-hoc emacs-popup` will build emacs-popup for you if it is not already built.
<lfam>Afterwards, you will be in a container that has emacs-popup on your PATH.
<mark_weaver>rain1: there's one iteration that should happen within two weeks, where the FSF is upgrading the hardware underlying their VMs, including the one that hosts hydra.gnu.org. and, independently of that, we're building a new bare-metal box to replace hydra.gnu.org that we hope to deploy within two months.
<lfam>Sometimes it really is faster to build from source with --no-substitutes.
<lfam>Also, if you are iterating over a package you are working on, you might get all the substitutes on the first try. Then, subsequent iterations can use --no-substitutes and be much faster!
<mark_weaver>rain1: right, that's always an option, but it should be noted that it's quite a lot of stuff to build, given that at our base we do something roughly analogous to Cross [GNU/]Linux From Scratch.
<lfam>Oh, I forgot rain1 was building a new system. Yes, that would take a while :)
<davexunit>NiAsterisk: when you do 'guix environment --container', you cut off access to the guix daemon and all that stuff.
<mark_weaver>davexunit: regarding your question earlier about what automounts removable drives in gnome: I'm not sure, but I think that's udisks' job. we have a (udisks-service) in %desktop-services, but maybe we need some additional configuration to specify that things should be mounted automatically. policykit might also fit into this, dunno.
<davexunit>mark_weaver: ah, okay. I might look into udisks sometime if I find the motivation. :)
<calher>When I DL a tarball, do I get the hash from `guix hash <tarball>'?
<parabool>is it of any concern if a gpg fingerprint is exactly the same as shown on a website, but with an extra space right in the middle? ie 13EB BDBE DE7A 1277 5DFD B1BA BB57 2E0E 2D18 2910 (this is not guix, but can't seem to find an answer elsewhwere)
<mark_weaver>gvfs is different. iirc, the idea is that GNOME programs access the filesystem via gvfs instead of regular POSIX calls, and that allows programs using gvfs to access files over FTP and SSH semi-transparently.
<rain1>ah i shouldn't edit it manually, ill read the dhclient manual
<calher>BTW, the docs I have on my system do not include the most recent manuals with the shepherd change, even though my system now has shepherd because of getting things straight from git on the root account. i guess it was all the package definitions or something from git.
<mark_weaver>calher: ah, I see. well, that version of the hello package includes 'gawk' in the inputs, so it needs to access the 'gawk' binding from (gnu packages gawk)
<mark_weaver>rain1: why do you feel the need to edit /etc/resolv.conf? what did dhclient do wrong?
<calher>OK; took it out of my definitin. -- Ugh, I need to change back to Dvorak, my fingers are getting tied.
<NiAsterisk>hm... are packages in melpa just .el files? the corresponding .git listed in the file in melpa contains more than just .el files. with emacs-build-system (I used elpa import) I get an error on "no tar file"
<mark_weaver>calher: "guix build -f" requires that the final expression in the file evaluates to a package object. so if you want to do it that way, you need to add "mcwm" (without the quotes) to the end of the file.
<mark_weaver>(define ...) evaluates to #<unspecified>, hence the error.
<mark_weaver>note that the example in the manual just has (package ...) as the final expression, without the 'define'.
<iyzsong>calher: yeah, mcwm don't use `configure', you should delete the 'configure' phases and set 'PREFIX', see 'dmenu' for example.
<calher>iyzsong: Oh crap, I forgot the GNU Build System assumes a configure script.
<NiAsterisk>I'm using the emacs-build-system without any changes so far. is this something okay for guix, or should I removed README.md, Cask, .gitignore, .git/, Makefile and travis.yml before installing? https://ptpb.pw/4rG3.txt
<lfam>paroneayea: I just noticed that in python2-wtforms, python2-setuptools is more properly a native-input.
<lfam>Heh, fair enough. In that case, I'd add a phase before the install phase that makes the directory. Then, I'd send the bug report without the patch. I think they'll know how to fix it. The other option is to ask the mailing list for help.
<davexunit>civodul and rekado (I think) put out a paper awhile back that has a section about Spack
<xd1le>why the need for that when you can just use fpm's
<xd1le>ah, does it predate when nix became relatively popular/known?
<yvm>Trying to install GuixSD with 'desktop' I got test_format_newc FAIL when testing libarchive-3.1.2. Also message "If tests fail or crash, details will be in: /tmp/nix-build-libarchive..." lied: there is no such directory.
<jubalh>rekado: i tried it via the package manager, then people here told me i shall install it via git so i can update the lxqt packages. i did only a make and use ./pre-inst-env guix now. people told me like that it will use the git version
<mark_weaver>efraim: thanks for taking care of the postgresql update!
<mark_weaver>efraim: I already patched the bundled graphite in iceweasel. in fact, right now that's the only graphite fix in 'master'.
<mark_weaver>efraim: the fix for our main graphite package is in 'security-updates', and hopefully will be ready to merge later today.
<jubalh>rekado: but also in guix i dont see the package
<mark_weaver>jubalh: the problem is that our 'libqtxdg' package refers to an 'http' URL, so gnutls is not included as an input to the derivation that downloads it. however, at some point since we last updated that package, they started redirecting 'http' to 'https'.
<mark_weaver>jubalh: the fix is to change 'http' to 'https' in the code. I'll do that.
<jubalh>mark_weaver: so in the packge urls from http to https you so? okay :)
<jubalh>mark_weaver: let me do it i am trying to getting into packaging for guix :-) and i intended to update the lxqt package anyways
<mark_weaver>jubalh: do you have Guix built from a source checkout of our git repo?
<jubalh>can you explain to me what the pre-inst-env is doing exactly? i am using it but not sure what it actually does
<mark_weaver>jubalh: it sets several environment variables before running the following command, which configures guix to use all of the code within that directory.
<mark_weaver>whereas normally it would use the code within $HOME/.config/guix/latest which is a symlink created by "guix pull"
<mark_weaver>since I *always* want to run the guix from my git checkout, I make both ~root/.config/guix/latest and ~mhw/.config/guix/latest symlinks to my built git checkout, and I never run "guix pull".
<mark_weaver>pre-inst-env is just a shell script, btw, with lots of comments, so you can read the code.
<jubalh>its compiling qt now, so it will take some time. then i will try to update lxqt and send a patch :)
<jubalh>since i switched away from Gentoo i totally forgot how long it can take to compile a big package..
<mark_weaver>jubalh: qt is practically an OS by itself, with all of its bundled libraries and programs. it takes quite a long time to build.
<mark_weaver>hmm, I might be remembering wrong about chromium being in qt. I don't see it in qt-5.5.1 anyway. maybe it was bundled in an earlier version.
<Jookia>WebKit is definitely there which takes way too long to build. We should definitely keep JPEG support, but it's bringing me closer to finding out why it's broken in particular- this happens in the newest gdk-pixbuf version
<mark_weaver>Jookia: what is broken? the only issue I remember is that one of the tests required a lot of memory.
<Jookia>mark_weaver: The test requires lots of memory which can lock the machine up at worst or cause the build to fail at best
<Jookia>Google has the habit of bundling modified third party code and not putting it upstream
<Jookia>So you probably have like 5 versions of zlib on your system, only some updated properly
<mark_weaver>I try to keep up on security updates, but I've explicitly posted that someone else will need to take charge of keeping Qt's bundled libraries patched up. as for me, I've purged my system of anything that uses Qt.
<mark_weaver>my avoidance of Qt is not a principled stand, but rather a practical one. last I knew, no one has been keeping an eye on making sure security updates are applied to Qt's many bundled libraries, and I don't want to do it myself.
<lfam>mark_weaver: I asked about security policy and on #qt, and they pointed me at <https://wiki.qt.io/Qt_project_security_policy>. They publicly disclose issues on qt-announce, and have a private security-announce list for people like us. Think I should ask on guix-devel if anyone wants to try to get on that list?
<lfam>cbaines: My opinion is that people have to advocate for their patches. So, by asking here, you're doing a good job :) But you might have to ask on the mailing list again if there is no attention.
<lfam>dannym: If you look in `git log -p` for 'broken-tarball' you will see that it's an interesting case. I wonder if something changed in the last update to scheme.scm that broke it.
<NiAsterisk> @strace and lispf4: okay, will do as soon as I have a functional second system again.
<NiAsterisk>I wasn#t expressing that i think it's a guix issue
<NiAsterisk>:O friend brought back promotional posters to spread for a congress in berlin, looks very interesting, but 80-250 Euro for 2 days ticket is kind of an issue when you have to add traveling and hotel.