<NiAsterisk>argh. I gpg2.0 was no problem. gpg2.1 and Gnus is a major pita. I can decrypt messages again, but encrypt and sign? nope.
<lfam>Can someone suggest a regex that can match a generated Guix shebang? I want to match a shebang such as #!/gnu/store/x2p2biyybcb2wac77qz9468asc5fm48i-perl-5.22.1/bin/perl but I don't care about the contents of the hash
<lfam>So, the important parts are the #! at the beginning and the /bin/perl at the end
<lfam>So my plan (for having a fix ready for tomorrow) is to apply the patch or substitute after configure
<NiAsterisk>2.0 worked. 2.1 makes me scream inside. I would really prefer some documentation somewhere which I can't come up with through searches, or even snippets which still work, but I can't... I created my current keys with 2.1, so no idea if using 2.0 works..
<lfam>I want to preserve the effect of this patch: gnu/packages/patches/openssl-c-rehash.patch
<davexunit>I couldn't find a list online, but maybe I just didn't look in the correct place.
<Jookia>davexunit: I just took what the repo offers and manually downloaded, but apt-get should work fine if you know the package names: http://sprunge.us/UXAS Apprently xobs-beta only updates explicitly installed packages
<NiAsterisk>oh great. gpg2.1 is not compatible with 2.0 in some ways...
<Jookia>davexunit: Maybe I got them wrong, that's pasted from what someone said on IRC. From my experience mpv's drawing using X acceleration will play 720p, not sure about 1080p or if GL helps with that
<mark_weaver>it's also easy to piss on people for making incompatible changes when you haven't tried maintaining a piece of software for 15 years or more.
<NiAsterisk>i don't piss on efforts when I say that the usability sucks. that's not even my statement, it's the experience from years of trying to get people to use and explain GnuPG to them. , nothing public yet, more or less all covered at EDN and linked projects like secushare etc, code participation of myself is currently in design phase. currently I am doing other works around these projects. still I don't "piss" on
<Jookia>"At which point the only remaining objection is disk space usage. The answer on this front is simple: It's 2016. I can buy a 3 TB hard drive for under $100 after shipping. Your point is invalid. " Or bandwidth use
<Jookia>But everyone has American fibre connections these days and nobody's on 3G
<davexunit>paroneayea: "by viewing composer as a compiler"
<davexunit>because compilers just download shit from the web all the time
<paroneayea>and the goofy virtualenv setup for quick hacking
<paroneayea>and later people were like "well we don't have a real deployment *guide*"
<Jookia>I think the first red flag when I went from C to something higher level was that the package manager couldn't uninstall packages and to resolve dependency hell was to wipe the sandbox and try again
<paroneayea>and so some people came along and made a deployment version of my development docs and I was like, "hm okay, but I'd prefer real packaging, but I guess this can be something interim"
<paroneayea>so it wouldn't be for proper python packaging upstream, but having this cheat would make "guix environment -l guix.scm --pure" a lot more usable for many packages I've worked on
<Jookia>Interesting. Perhaps it'd be worth bringing up some cheats for Guix environment? I know there's some more cheats we could do for development, such as using binfmt_misc to replace shebangs but it sounds like it'd be better to put that kind of stuff in containers
<paroneayea>Jookia: I'd like to test my cheat before I really publicize it
<Jookia>civodul: Do you see any solution to this that could work out of the box? It's a remarkable situation with a package manager that assumes itself will be in a certain place and one problem is that the store could be corrupted accidentally
<rekado>using hydra.gnunet.org now, but updating the list of substitutes still seems very slow.
<rekado>(I just updated Guix so "guix environment guix" needs a lot of new substitutes)
<rekado>right now hydra.gnu.org is much faster than hydra.gnunet.org, but maybe that's just because of the initial update step
<rekado>now as I'm downloading on one machine from gnunet and on the other from gnu I see that both have about the same download speed for substitutes, gnunet being slightly slower (150-200KiB/s for gnunet vs 160-350KiB/s for gnu).
<cby>hi, I am trying to define a new Perl package (Text::BibTeX, that builds various C shared library) and it fails on the validate runpath phase because the libs cannot be copied to the store during the strip phase (reason: Permission denied)
<rekado>cby: libs should only be installed into the current package's output directory, not into other packages' directories.
<rekado>you may be able to overwrite the target location with configuration flags.
<rekado>back to using hydra.gnu.org. Downloading substitutes from there is considerably faster.
<Piece_Maker>heey guys, i got an error with guixSD installation last night - the packages all downloaded, then when it started compiling certain packages, the libinput one failed saying that there is a file missing in the mtev dependency package... weirdly i didnt get this the night before
<marusich>Hooray! I've installed GuixSD on a Libreboot X200 laptop. The only strange hiccup was that ntpd was stuck in a restart loop, perhaps because the system clock was stuck at 1970, until I stopped ntpd, set the time with ntpdate, and then started ntpd again.
<marusich>I was also surprised when I rebooted after running "guix system init" to find that wpa_supplicant and cryptsetup were no longer installed. I guess they're in the installation image but not in the config.scm I made, which was based on the default
<marusich>On the plus side, everything else works just fine so far. I basically copied my home directory over from another guix machine, and everything is in its right place. Wicd also made connecting to my wireless super easy once I logged in.
<marusich>Anyways, just wanted to report in and say thanks again for such an awesome distro :)
<marusich>I wasn't very familiar with configuring wireless from the command line in linux, so I started by using wpa_supplicant in the installation image, and did not think until later to use wicd after reboot.
<NiAsterisk>mark_weaver: I am sorry I had a very rough day yesterday and it wasn't wise on my side to try with gpg afterwards. in general my rejection of average-people usage of cryptosoftware today still stands but to understand it must be put into a bigger picture I might be able to get recorded later this year. If I was angry or something it was not intentional.
<rekado>when I do "guix build icedtea" it downloads substitutes for all outputs (i.e. "out", "jdk", and "doc"). Can this be avoided? Is this a bug?
<mark_weaver>NiAsterisk: no worries, I probably reacted to your comments more strongly than warranted also...
<NiAsterisk>most likely, yes. but it's a counterposition I am used to :) all good
<civodul>rekado: this is expected: "guix build icedtea" means "build the derivation of icedtea", which includes all its outputs
<civodul>conversely, "guix package -i icedtea" pulls only "out"
<rekado>civodul: ah! I often use "guix build $something" to make sure the package is available in the shared /gnu/store to minimise waiting time for users.
<civodul>rekado: re hydra.gnunet.org, we're still on a cold cache because few people use it currently, it seems
<civodul>on cache hits it seems to be faster, and also it can have a much larger cache than hydra.gnu.org, which is why i'm relatively hopeful
<rekado>shouldn't I be seeing better download speeds, though? How is this related to caching? (I'm pretty ignorant about these things.)
<myglc2>lfam: Not obvious what to do w/ 99 MB test-suite.log. I will attach the 50 KB make check log to bug post & save the other log. I want to work around this. Do you think I should roll back to an earlier commit and try again?
<lfam>myglc2: There should be one log for each test that failed. If the full log is too big, those individual logs should provide valuable information.
<efraim>i do most of my youtubing with youtube-dl through mpv
<rain1>yes that's a very nice way that always works (unless country restriction)
<rain1>I just feel it should work.. so I keep trying things
<myglc2>lfam: Log includes 6 tests failed: store.scm guix-daemon.sh guix-build.sh guix-package.sh guix-system.sh guix-gc.sh and compresses (gz) to 7 MB. So you think I should post it? BTW, did you make check work?
<lfam>myglc2: Amazingly, `make check` is still running on my machine!
<lfam>I think the tests are run in parallel, so I can't say exactly what step it's on. The last line is the gem test
<myglc2>lfam: OK, Thanks. my post of compressed logs failed. So I sent the smaller log with a note that the previous commit works.
***samis is now known as CompanionCube
***mattl_ is now known as mattl
<rain1>what is the trick to guix environment with extra stuff available?
<mark_weaver>rekado: regarding guix/build/union.scm, I optimized that code and tried my best to minimize the number of syscalls. however, there are a lot of stat(2) calls, and that's probably what's slowing things down a lot on NFS
<NiAsterisk>guix runs (yet) on neither of: irix, aix, ultrix, dolphinos, osf1, sunos, bsd/386, freebsd, hp-ux, cygwin. right? some are juts historic and this program I have at hand is old, if I leave out all of these and just use linux (not the makefile, I catch stuff from a sort of setup file), there'll be no hard feelings.