<Acou_Bass>civodul: thanks for replying earlier - those are theinstructions i followed hehe <Acou_Bass>but dont worry about it for now - ill install unencrypted for now and look at it further if the installer gets updated to support it hehe <lfam>How can I refer to gcc in #:allowed-references? gcc is unbound. I assume I need to refer it some other way? <bavier>binutils doesn't install liberberty? <paroneayea>lfam: I'm always impressed with your reviewing when I look at the Guix list btw <lfam>paroneayea: Thanks for the compliment! I'm trying to help in the ways I know how, and since I'm still learning Scheme, reviewing patches seems like a good use of my time. <lfam>And when I first sent a patch, the response was helpful and encouraging, so I'd like to pass it on :) <lfam>paroneayea: It seems we fixed the first one in December. I'm not sure about the other two. Does it even apply to our package? That is for Debian LTS aka Squeeze <lfam>Okay, I'm stuck trying to apply #:allowed-references to openssl. I took mark_weaver's advice, and now I can make it work in principle, but it still chokes on gcc. Gcc isn't bound in that context <lfam>I wonder how I can refer to it? <civodul>bah, the new debbugs.el thinks everything is latin-1 <NiAsterisk>"Jookia I think the T400 can run 1080p video since it has hardware decoding (I think)" yes it can. <NiAsterisk>even T60 can run 1080p videos, the t400 is just better at it. <civodul>lfam, mark_weaver: email sent for 22139 :-) <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>Hm, maybe that's not the best approach <lfam>mark_weaver: I'm trying to address #22831: OpenSSL should not depend on Perl. We patch the origin to remove the shebang, but the configure phase is somehow recreating the shebang. <mark_weaver>NiAsterisk: we still have gnupg-2.0 and gnupg-1.4 in Guix. Last I checked, which was admittedly a while ago, I needed gnupg-1.4 for Gnus. <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 <paroneayea>which will be good news for my talk this week on guix :) <NiAsterisk>mark_weaver: currently it is "error in process filter: Process epg not running [2 times]" ad infinity, no matter what I change and try. <lfam>Thanks mark_weaver, that did the trick <lfam>Now I just have to figure out how to use #:allowed-references correctly <lfam>Of course, I'm not sure *why* that fixed it, since c_rehash.in had the same shebang before. <davexunit>Jookia: what debian package needs to be installed for graphics acceleration on novena? <davexunit>and I thought I had the etnaviv driver installed given the names of some packages that I saw when I did a dist-upgrade <Jookia>davexunit: Let me find the package list I installed manually <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... <NiAsterisk>it's awful, user-fiendly and needs to die as soon as we have something better. <NiAsterisk>good software does not require "crypto parties" for people to "eventually" get it. it just works. <Jookia>davexunit: there's no need for it to <mark_weaver>lfam: it probably broke when we fixed the timestamps of patched origins to be at the unix epoch. <davexunit>Jookia: but gfx acceleration must not be working <Jookia>davexunit: from what i've heard you want " -vo=opengl:backend=x11egl:es=yes " <Jookia>davexunit: Not sure what the story is about WebGL but it might not support GL ES with the Debian build <lfam>mark_weaver: I bisected, and the issue started when we updated to 1.0.2e (86c8f1daf8) <lfam>Of course, that only shows when the problem manifested itself <Jookia>Basically etnaviv currently implements GL ES and OpenGL 1.4, so the fanciness that mpv is expecting (OpenGL 3) isn't going to happen, instead GL ES is what's needed <mark_weaver>NiAsterisk: it's easy to piss on other people's efforts when you haven't tried doing it yourself. <davexunit>Jookia: hmm, that set of flags didn't work for me <davexunit>error while parsing opengl parameter (x11egl <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. <_`_>gpg is “user-fiendly”? <mark_weaver>gnupg-2.0 is still maintained, and you can keep using it, so I'm not sure what the problem is <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 <_`_>So it's a fiend to users? (even a typo of user-friendly is still questionable, it's bad because it's user-friendly?) <Jookia>davexunit: If you join #kosagi on OFTC I'm sure you'd get a lot of better information <paroneayea>I thought I was told "don't install texlive-texmf, just install texlive" <davexunit>paroneayea: you mean it propagates texlive-texmf? <mark_weaver>paroneayea: the Andreas was trying to make is that texlive-texmf should not be in your profile directly <mark_weaver>I don't know why he said that, so I'm not necessarily agreeing with him, but that's what he meant anyway :) <paroneayea>I mostly want it for beamer but I'm really wary of pulling down > 1gb substitute right now from hyda <mark_weaver>there's a hack for that, to build texlive-texmf locally. <davexunit>guix environment texlive -- guix package -i --no-substitutes texlive <davexunit>but this is probably not exact. I will wait for mark_weaver to return :) <paroneayea>I'm setting up my talk hacking environment. I've been switching between org-beamer and org-reveal to do things <mark_weaver>this is from lfam: guix environment texlive-texmf -- guix build texlive-texmf --no-substitutes <paroneayea>I like the look of the reveal.js presentations, but building it is another dive into node.js things <rain1>I'm on a fresh guix install but I can't use sudo <rain1>sudo: /home/rain/.guix-profile/bin/sudo must be owned by uid 0 and have the setuid bit set <paroneayea>davexunit: yeah this one was for the talk at Stripe this Friday, but maybe I should also use org-beamer for that reason too: we can both easily collaborat on pdf'sville <davexunit>rain1: that's as designed. sudo needs to be installed to the system profile where it can be setuid root. <davexunit>sorry thought you were talking about a guix talk :) <paroneayea>and probably there will be stuff to reuse when it comes between this talk and the one we giveat libreplanet <paroneayea>I'm giving a talk at Guix this friday at Stripe! <mark_weaver>rain1: on a GuixSD system, setuid programs only exist in /run/setuid-programs/ <paroneayea>so it'll probably overlap with the stuff we're doing at our LibrePlanet talk, so I might as well use org-beamer <rain1>so ill guix package -r sudo then some how install it differently? <mark_weaver>that should have been put before the other things in your PATH <paroneayea>set up the environment with substitutes for building it, then build without substitutes :) <mark_weaver>rain1: /run/setuid-programs should be put early in your PATH, or else you'll get the wrong one. <mark_weaver>rain1: GuixSD arranges for that by default, but maybe you changed your dot-files or something? <rain1>I did i must have got it wrong <mark_weaver>or maybe there's some case where it gets overridden, dunno. <davexunit>you are putting your profile before the system profile. <davexunit>I mean, that's OK if that's what you want, but you need to be careful <davexunit>I actually have my own profile set before the system profile in $PATH <davexunit>just make sure you don't install things that ought to be setuid binaries <rain1>I was reading the texinfo manual for shepherd but I can't use herd <rain1>error: connect: /home/rain/.config/shepherd/run/socket: No such file or directory <davexunit>you need to be root to talk to the shepherd running as PID 1 <davexunit>I run another shepherd as my normal user for non-system related services <rain1>yeah I'm interested in shepherd <rain1>icecat complains about your HTTPS cert because it doesn't know about Lets Encrypt <rain1>will study this init.scm, ty <rain1>it's easy to add an exception, just reporting it <davexunit>not the first time I've heard this complaint <rain1>I'm really excited about Lets Encrypt and want to use it too <davexunit>rain1: my config is messy, but there's some fun stuff to see in there, such as procedures that create shepherd services. <rain1>I would like to know if there are any basic thtings i can do to help guixsd? <davexunit>rain1: in my experience, just by using guix and guixsd you'll run into things that you want to make better, so you hack on them. <mark_weaver>rain1, davexunit: fwiw, davexunit's site works for me in IceCat on GuixSD <mark_weaver>rain1: do you have 'nss-certs' installed in your system profile? <mark_weaver>oh, actually, it shouldn't matter.. IceCat uses its own private certificate store <mark_weaver>anyway, IceCat tells me: "You are connected to dthompson.us Verified By: Let's Encrypt The connection to this web site is security" <rain1>I wonder why mine doesn't know about lets encrypt <rain1>I'll see if i can work it out <davexunit>ACTION realized that a system upgrade knocked out his custom gitweb theme. <Jookia>it's GuixSD's imperative to make all systems functionally the same <davexunit>so I'll try to address the issues when I generate new certs <davexunit>I need to set up a cron job so that they are regenerated weekly or monthly <_`_>davexunit: do you use the official client or something else? <davexunit>_`_: the official client, as packaged in guix. <_`_>was just curious, thanks <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 <Jookia>Who even thought up bundling package managers <Jookia>davexunit: "When libraries set up their .gitattributes with export-ignore, the tests/examples/docs are excluded from the dist archives.." <davexunit>it's like no one understands *why* 'make check' is a thing <Jookia>On the surface it makes sense to have a package manager per language kind of <paroneayea>davexunit: Jookia: yeah it's a pretty depressing article. <davexunit>I think language package managers are a good way to quickly share *code* to make it easier to get started. <davexunit>but when they try to do more, which they all do, it's bad. <paroneayea>davexunit: yes, though it's natural for development documentation to turn into deployment documentation, with iffy results <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>guess how long that terrible deployment documentation has stuck around <davexunit>I run mediagoblin from the "development" virtualenv <paroneayea>as a developer of python stuff, that *was* how I deployed things to servers for years <paroneayea>this is one reason I have high hopes for "guix environment" <paroneayea>it has the "up and running fast with hacking" thing <paroneayea>but also guides users towards sane packaging directions without too much extra work <davexunit>getting a dev environment built puts you well on your way towards a real working package recipe. <paroneayea>hopefully we can move fast enough to become a real alternative to all the static madness <Jookia>I think 'guix import' is a killer feature <paroneayea>there's no way I would have finished mediagoblin's dep packaging without it <paroneayea>you can now hack mediagoblin from a pure "guix environment", with one exception <paroneayea>you have to create an empty virtualenv that you run "python setup.py develop --no-deps" in <paroneayea>because pytest needs to be able to "find" mediagoblin's paths and stuff... <paroneayea>and having a package put in the environment profile with the present working directory! <Jookia>I have no idea what that means but you could write some fancy container code <Jookia>I know eric s raymond puts "." in his $PATH <Jookia>Is there a reason why pytest relies on this behaviour? <paroneayea>the scheme would know what pwd you (or it) is in and make a package for it <paroneayea>Jookia: yes, but it's hard to explain this late at night ;) <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>Will MediaGoblin be deployable using GuixSD and Shepherd? <davexunit>paroneayea: spot gave a talk about "open source fails" to a small group on students when I was in college. ***mv is now known as marxistvegan
<davexunit>"Chromium doesn't have an initial configuration process. (Answer: Well, gee. I wonder if that would be useful.)" <Jookia>I wonder if the next logical step is to use dependency package bundlers to fork projects with your own patches, ala Google <Jookia>Oops my bad, keys weren't imported <Jookia>paroneayea: Btw with latest Novena drivers, Crawl is more than playable :) <Jookia>civodul: o/ I'm testing my GRUB patches and I think I have them mostly tested for review <civodul>i'll add it to my list of things to review... <Jookia>Heh, it replaces the vm-refactor patch I did <Jookia>It does some refactoring to in my not-so-subtle attempt to abstract some GRUB code <civodul>refactoring in this area sounds welcome :-) <Jookia>civodul: Any objections to a patch to discuss setting localstatedir to /var by default? :P <civodul>my gut reaction is rather negative, but then i can see why you're asking <civodul>so not sure, but we can discuss it, sure <alezost>ACTION would like to have --localstatedir=/var by default <Jookia>I think something (anything) should be done to stop people from building a Guix incompatible with the 'official' Guix by default <Jookia>I think localstatedir is a standard Autotools thing that shouldn't be changed? <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 <civodul>but note that people may have a different localstatedir too <civodul>it really depends on how they installed the thing <civodul>but let's start or restart the discussion on the list <civodul>maybe i should reply to the previous thread on that topic? <Jookia>Restarting the discussion would be great- yeah :) <civodul>it's a cache of hydra.gnu.org (same signatures, etc.) <civodul>right, but it's a cache, so it has to be "warmed up" before it's (hopefully) faster <civodul>the more we use it, the more cache hits are likely <Jookia>Also I found a bug in my last patch which my testing has found so I'll have to revert to some 'simpler' code <Jookia>I mentioned the other day but I may try getting GNUnet support for propagating binaries this year sometime <civodul>be sure to check out last year's GSoC <efraim>I wish I had good internet speeds like that <civodul>well, that's from my workplace connection... <Sleep_Walker>food for thought - in case you haven't heard about IPFS: https://ipfs.io/ - it could be interesting alternative for distributing binaries... <efraim>using wget, 1.33 MB/s for hydra.gnunet.org, 308KB/s from hydra.gnu.org <Jookia>I honestly feel unsafe using the Internet without Tor these days <Jookia>Interesting, though you can tell everyone apart here <Sleep_Walker>I mean that if I'd like to eliminate non-interesting cases in all the traffic, I'd suspect Tor users as people who have something to hide <Sleep_Walker>with the information leaked by browser and all other applications I'm afraid that it would be still possible to collect interesting metadata <Jookia>Yeah, you have to do a lot of manual configuration to stop leaking <Jookia>But at the same time, it changes the threat model from your ISP to the connected server <Sleep_Walker>I'm far more concerned by the people able to compromise Tor gate than the ones compromising my ISP :) <Jookia>Compromised exit nodes are probably common, but they don't have much data outside what you give them (encrypted connections, etc) <Sleep_Walker>jookia: so you monitor your network traffic all the time? <Sleep_Walker>well, what if some poorly written site switch from https to http <Jookia>Then an exit node will know I'm reading that site, and if it's in one of the four sites I'm signed in to I'll have to change my passwords <Sleep_Walker>what if your emacs mode installed from github tries to access unsecurely some remote server <Jookia>I don't really care if it's HTTPS unless I'm authenticating <Sleep_Walker>jookia: that exit node will obtain web browser fingerprint <Jookia>Yeah, my Tor Browser fingerprint' <Jookia>Just like all the other Tor users <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. <cby>rekado: Oh ok, makes sense <cby>rekado: I'll look into it, thank you <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 :) <Jookia>marusich: Do you think wpa_supplicant should be in the default image? <marusich>The default has wicd, which seems good enough. <Jookia>I wonder why the live USB has no wicd <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. <marusich>Maybe it was there and I just didn't realize it. I don't think it's there, but I might be mistaken, since I assumed wpa_supplicant was the thing to use. <marusich>Not entirely new, but still have much to learn; I've been using it off and on for a few months. <Jookia>wicd-service is part of %desktop-services I think? from what I know the live USB doesn't include wicd <Jookia>Perhaps this is something that should be considered to make things easier <marusich>I've packaged one measly little package, but it was rather difficult to even set up email for me using GuixSD, so being productive in it has been a little bit of a blocker to hacking on it <marusich>Though, the difficulty re: email is probably more due to my inexperience using emacs for email etc. than anything else. But I'm getting the hang of things. <Jookia>My mail scripts are all done using Bash and Mutt <marusich>I used to use vim, but I think I like emacs a lot better. <marusich>Anyway, despite the fact that my computer thought it was 1969 until a little while ago, it's actually quite late where I am. I should get some rest. See you on the email lists :) <Jookia>Nini, hope to see you around too :) <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.) <mark_weaver>on a cache miss you need to wait for hydra to build and compress the nar on-demand, which is quite slow <civodul>a good test is "sudo rm -rf /var/guix/substitute/cache && guix build libreoffice -n" <civodul>(to force a redownload of the narinfos) <efraim>I'm looking at Pjotr's patches on the mailinglist, they're all update patches <rekado>efraim I looked at them too and wanted to apply them after making sure all dependent packages can still be built. <rekado>but I don't think I can get it done today <efraim>looks like he forgot to add periods to the end of the commit messages <mark_weaver>ACTION is tempted to write a new version of 'fold-port-matches' that doesn't, on almost every byte, call 'append' with a relatively long first list. <efraim>I'll be mostly afk for a few hours, I'll get it running on my machine and see how it goes <rekado>hmm, I think it's wrong that our icedtea package retains a reference to gcj. <rekado>it's supposed to be used for bootstrapping only. <civodul>mark_weaver: that would be great :-) <civodul>mark_weaver: also, we might want to use mmap at some point <mark_weaver>civodul: I'm not sure I see an advantage to mmap in this case, since we'll always have to read and scan the entire file anyway. <mark_weaver>I haven't researched the issue, but I guess that mmap is mainly a win when you might not need to read the whole file <mark_weaver>and it raises complications, e.g. dealing with large files in smaller address spaces <mark_weaver>the particular pattern that 'replace-store-references' scans for is relatively easy to deal with <mark_weaver>ignoring the initial 'store' location for the moment, there's always "/", followed by 32 nix-base32-chars, followed by "-" <mark_weaver>so there can be no overlapping matches, or even overlapping potential matches <mark_weaver>when encountering a "/", you can always simply reset the matcher <mark_weaver>and matching the base32 chars could be done by looking up the byte in a vector of booleans of size 256, which is fast for the Guile VM. <mark_weaver>with a simple counter for number of those bytes found <mark_weaver>and then after finding this tail, you could, optionally, verify that the 'store' path precedes it <civodul>i don't have the bandwidth right now to work on it, but i'm happy if you do or if you write down the ideas in a bug :-) <civodul>i mentioned mmap mostly as a way to avoid the repeated 'get-u8', though it's unclear whether that'd be a win... <NiAsterisk>i guess something is happening on hydra at the moment, maintenance or whatever? <NiAsterisk>ok. might be that I did not pay attention to that detail <civodul>no no, it's just that we're experimenting with a new cache <civodul>and for the cache to be useful, it's best if there are several people using it :-) <piyo>hello is there an announcment about hydra.gnunet.org? <civodul>i don't want people to hard-code the machine name in their configs <efraim>do r packages build quickly? would I be better off passing --no-substitutes for testing pjotr's patches? <rekado>efraim: they usually build fairly quickly. <efraim>33 minutes to download the tarballs I needed for building, it didn't download R or the built dependencies yet <mark_weaver>openssl-1.0.2g is now available at ftp://ftp.openssl.org/source/ <mark_weaver>civodul: do you think your recursive grafts code is ready to be used for this openssl update? <piyo>civodul: using h.gnunet.org with my raspi2/arm, debian jessie foreign guix, upgrading to guix-0.9.0.f888c0b <civodul>mark_weaver: at worst we'll have to remove the OpenSSL graft and wait for the rebuild <civodul>so it seems there's not much to lose <mark_weaver>civodul: when updating to a new version of openssl, what do I need to do to ensure that the graft can work? specifically, regarding the file name change. <mark_weaver>if you have time to handle this update, maybe that would be best? <civodul>ACTION .oO( when will C & ambient authority cease to be the norm ) <civodul>"Builds that are not configured with "enable-weak-ssl-ciphers" will not provide any "EXPORT" or "LOW" strength ciphers." <wingo>that divide-and-conquer vuln is pretty fun too ***vimuser is now known as emacsuser
***emacsuser is now known as vimuser
<davexunit>civodul: unfortunately, people want to move to supposedly safe languages that are very young with problematic build systems like Rust or Go. <civodul>heads-up: OpenSSL graft/replacement pushed to master <NiAsterisk>i forgot that haskell has a whole warehouse of dependencies.. I "only" wanted to install pandoc "quickly".. grr <civodul>if something goes wrong, comment out the 'replacement' field of openssl <rekado>NiAsterisk if you need just a markdown renderer I recommend peg-markdown. <NiAsterisk>no, I need something for a "make wiki" which has pandoc in the instructions and renders mediawiki pages. <rekado>I'm again trying to debug slowness when a shared store is mounted on NFS. <rekado>in the daemon code I could only find a couple of redundant syscalls, but that's only about 400 instances that don't matter much. <rekado>what's taking a lot of time seems to be the code in guix/build/union.scm <rekado>in the strace output I see about 1400 lines of "brk", which I assume is guile waiting to get more memory. <rain1>isn't that sbrk? i think brk is just finding how much you have <rain1>(so it seems odd to call it more than once) <taylan>rain1: doesn't seem so. see manpage. <rain1>oh im very sorry, that was totally wrong <rekado>maybe that's related to growing the hash table in guix/build/union.scm. <rekado>be that as it may, I think I should make some efforts in trying to figure out how to reduce the number of syscalls in there. <rain1>How does one enable XDG_CACHE_HOME? I just noticed it in the guix sources and it sounds like something good to have <rain1>shall I just add XDG_CACHE_HOME=/tmp/.xdgcache/ to my bash profile <rain1>il try that idon't know what will happen <rekado>it's usually "$HOME/.cache" when XDG_CACHE_HOME is not set. <rain1>oh so there's no point in me setting one <rain1>I was looking into why 'updating list of substitutes' can be so slow <lfam>Doing a package update with no substitutes returns almost immediately, while doing it with substitutes takes a while to download stuff. Can that be right? <efraim>it has to check what substitutes are available <lfam>But when I do it with substitutes, many substitutes are downloaded, even though I have just upgraded all my packages without substitutes. <lfam>It seems like upgrading without substitutes isn't working at all <lfam>Or at least, it isn't having any immediately obvious effect <efraim>it has to update one of the sqlite dabases in /var/guix/db <efraim>I don't remember what it's checking for though <myglc2>Just ran make check on git pull of current commit 'caeadfd' & got 6 failures. 99MB test-suite.log. Should I report it? <lfam>Oh, I know what the issue is. These command lines are not equivalent: <lfam>`guix pull && guix package -u --no-substitutes` <lfam>`guix pull && guix package -u . --no-substitutes` <lfam>The first one matches no packages, the second one matches all packages <lfam>Sorry, I didn't mean to send that line yet <lfam>myglc2: Yes, in general I'd say you should report the failures. I'm going to run `make check` too and see what happens <myglc2>lfam: Thanks. What to report? The build log? A subset of the test-suite.log? <lfam>myglc2: I think it gives some instructions when there are test failures. Is there anything there? <rain1>yeah i think it would be cool to try alternative like torrent or ipfs? <lfam>davexunit: Did you read about hydra.gnunet.org in the log? <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. <rain1>haha somehow I now have youtube with sound working but the video is black <rain1>it's very hard to get it to work perfectly <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 <lfam>myglc2: Please send the logs! <lfam>"Currently, the graft and the package it replaces (bash-fixed and bash in the example above) must have the exact same name and version fields." <lfam>That's a little confusing in practice, but I'd say this grafting mechanism seems to have worked here! <lfam>A *huge* improvement over rebuilding the entire graph in a panic <lfam>I found myself reading the man page of the new openssl store item to make sure of the version <myglc2>lfam: Took a long time here too with -j 5 on 3.4 GHz. Sent the logs, thanks. <lfam>myglc2: I don't remember it taking this long. <civodul>rekado: re slowness on NFS, profile derivation are definitely i/o intensive <myglc2>lfam: git commit c22a132 works here, so I'm backing down to that FTM <lfam>myglc2: Okay, just be aware that c22a132 does not contain the OpenSSL security update released today <lfam>The only difference between c22a132 and current HEAD (caeadfd) is that openssl update <lfam>paroneayea: It seems to work for me! Although the grafted replacement has the same name and version as the package it replaces, so it doesn't *look* like it works at first. <bavier>how does the cve linter react here? since the version is the same, does it know that a CVE fix has been grafted? <lfam>myglc2: It looks like I'm getting the same failures <davexunit>I updated my profile and am in the process of updating my system. <paroneayea>davexunit: I notice you commit .pdf files along with your presentations... I've debated off and on over time if I should do this <paroneayea>currently I don't, though at one point I kept them in git-annex <paroneayea>I have less trust that a presentation will be regeneratable from orgmode into the future correctly though <davexunit>so I can send people links to the presentation from the git repo viewer <lfam>We may have another opportunity to test the grafting mechanism: CVE-2016-2381 on Perl <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 <mark_weaver>I don't see a way to improve it without storing a copy of the directory structure of the store items in the sqlite database, which would be quite a major change <mark_weaver>actually, I'm not even sure how that would work, because the build process would not have access to that database <mark_weaver>it may be that we should use FUSE to create a new filesystem that's optimized to take advantage of the special access restrictions of /gnu/store <efraim>gotta keep the documentation safe from DROWN :D <davexunit>I was able to update my user profile and system without issues <efraim>i'll try to post it to the mailing list tomorrow, got two different outputs for the result <efraim>84 minutes total, including building openssl <NiAsterisk>i have an extended telnet client, what's the best location for it? admin.scm? <lfam>efraim: I missed your earlier messages. A reproducibility failure in something? <efraim>i grafted gtk-2 twice, with different outputs <lfam>efraim: The outputs had different hashes in their names? Or they failed '--check'? <efraim>grafting '/gnu/store/xqjpwf69w4i7nnb6bzsik2gaxlr2mzs4-gtk+-2.24.28-doc' -> '/gnu/store/20nsw4bq1sqbi8s9g818b3zmn9rjp1i7-gtk+-2.24.28-doc'... <efraim>grafting '/gnu/store/40jl47c0ny3x3i9yl68hlppcdb9ac0nz-gtk+-2.24.28' -> '/gnu/store/mh1119blkddypks8cha7l4rxnzjb319g-gtk+-2.24.28'... <efraim>grafting '/gnu/store/40jl47c0ny3x3i9yl68hlppcdb9ac0nz-gtk+-2.24.28' -> '/gnu/store/w3kxwwi4lxdm1s2pfcdk8jvmyvxdqbkb-gtk+-2.24.28'... <efraim>grafting '/gnu/store/xqjpwf69w4i7nnb6bzsik2gaxlr2mzs4-gtk+-2.24.28-doc' -> '/gnu/store/rwi0378js9f3vakslnj0siy77a9vhfzi-gtk+-2.24.28-doc'... <civodul>efraim: it's the same message twice, no? <efraim>it lists a different hash for each time it was grafted <efraim>guix gc --references is identical, except where they reference themselves <lfam>OpenSSL builds reproducibly for me, FYI <lfam>What do you mean? It points to pinentry? <efraim>the original pointed to pinentry <civodul>so the thing is to diff their derivers <civodul>something that's always tedious, we need an emacs mode or something <civodul>the builders of these grafts differ just by the order in which outputs are listed (the 'old-outputs' variable in (guix grafts)) <civodul>the order is getting reversed somewhere sometimes <NiAsterisk>well.. it's a MUD and enhanced telnet client... still admin.scm? <efraim>looks like the openssl update broke offlineimap <efraim>ImportError: /gnu/store/s7wk5hilw7crarg44m7anibqa2fba4ll-python-2.7.10/lib/python2.7/lib-dynload/_ssl.so: undefined symbol: SSLv2_method <lfam>SSLv2 seems totally broken at this point. Can offlineimap be configured to not use it? <efraim>no idea, i'll have to take a look at it tomorrow <efraim>or hope they take a look at it before me :) <lfam>I'm sure they will notice very quickly <ecraven>I'd like to generate a transcoding server, using mostly ffmpeg and some scripting.. I'd like to throw up new vms if I need more <ecraven>not much change involved, it should just run the given setup reproducibly <ecraven>I can define fixed versions of the packages, and then will be able to replicate the setup exactly for some years, right? (as long as the sources remain available)? <lfam>ecraven: That sounds really cool. I'd love to see your configuration when it's working. We should have a place to share things like that <ecraven>lfam: I have a 24-core machine for this, from uni.. I'll just need a small script to coordinate fetching videos and running ffmpeg to transcode them :) <ecraven>and I'd love to *not* have to set up this system by hand. I've used nixos before, but really want to give guix a try (Scheme!) <lfam>You could make a package for your script, and then even that could be set up automatically for you <ecraven>I'll write it in guile, if possible :) <lfam>You could also make a service for it, and then the configuration could be automated and reproducible. The GuixSD dream :) <efraim>`man openssl` shows 1.0.2f at the bottom <efraim>speaking of ffmpeg, we haven't packaged 3.0.0 yet <ecraven>efraim: no hurry, things should work with 2 for now :) <ecraven>is there a good tutorial on how to get guixsd onto a new system? <lfam>efraim: That's how I checked, and I saw the correct version <lfam>ecraven: I'd build the manual from git, since there have been many changes to those instructions since the web version was last updated <ecraven>I guess there's no epub target for the documentation? <lfam>I guess you are checking for it ;) <lfam>I usually do `make doc/guix.html` and then view it in a web browser <ecraven>I'm commuting, so that'd be a good time to read the manual. PDFs are ok, but EPUBs reflow better <lfam>I like EPUB as a format. It would be cool if we could build it. I wonder what sort of changes it would require. <ecraven>it's normally similar to html, just a bit more restricted <ecraven>how do I get a new git checkout into a state where I can run make doc/..? <lfam>ecraven: bootstrap and `./configure --localstatedir=foo`, where foo matches the localstatedir of your current Guix installation <ecraven>I don't have a local guix installation :) <ecraven>current git checkout, seems gnu/packages/weechat.scm is missing, make fails <lfam>If you plan to install Guix on your system, it's probably best to use /var. Otherwise the default (/usr/local/var I believe) should be fine <lfam>I think that some of the IRC stuff was recently reorganized <ecraven>lfam: I'd prefer to play with it in a VM first <lfam>ecraven: I'm referring to installing Guix the package manager with your current OS, not the full GuixSD installation <ecraven>lfam: yes, but I'd prefer to try it in a vm, not on my current system :) <lfam>Did you check out `guix system vm-image`? <lfam>Built in way to generate QEMU virtual machine images <ecraven>nope, just starting out, trying to compile the docs in order to read the manual :) <lfam>Okay, there is new information about `vm-image` in the manual too <lfam>Hm, I'm trying to graft a Perl security update and I see the bootstrap binaries are being downloaded. I better not do this in the cafe :p <ecraven>hm.. it seems make doc/guix.pdf does not generate the png images from dot automatically :-/ <lfam>Hm, it fails for me because I don't have tex in my environment <ecraven>thanks for your help, I'll read the manual, then come back with questions :) <lfam>Did you get it to build? <ecraven>I'll check the makefile tomorrow, see what my problem was <ecraven>guix.pdf should depend on the pngs, probably <lfam>Okay, it looks like the PDF generation needs some love <ecraven>.. which it doesn't, so fixing that should fix things :) <lfam>It would be really awesome if you could send a message to bug-guix@gnu.org about this :) <ecraven>lfam: I'll see whether I can fix it tomorrow, then I can send a patch :) <ecraven>aw, just nano and zile, no emacs on the install disk? :p <lfam>Heh, it's supposed to be a minimal system. You can easily create a customized installer by editing 'gnu/system/install.scm' and then using `guix system disk-image` as described in the manual <ecraven>great, I'll shut up now and read the manual, then come back better informed :) thanks again for your help, see you tomorrow! <paron_remote>I get the mysterious message "system error" and no ability to log in <ecraven>just a short followup, an epub generated along this random google search result (https://github.com/ikrukov/epub) seems to work fine, it just doesn't include the images (which can surely be fixed) <paron_remote>anyway, rebooted into the new system, seems to be working fine <paron_remote>(the "occasionally when I boot into guix" thing has been happening very occasionally for a few weeks, but a reboot fixes it) <wingo>so it seems you can make cgroups for anything. there are some cgroups that are specially known by the kernel and which correspond to resources, like cpuset or memory or so on <wingo>but you can mount a cgroup with any old name <wingo>which allows you to label a group of processes, even if a process does the double-fork dance <wingo>that seems to indicate that elogind should indeed create a cgroup hierarchy directly <mark_weaver>efraim: regarding SSLv2 being broken: the OpenSSL update removed SSLv2 support intentionally. that's the fix for DROWN <wingo>and place sessions in ad-hoc sub-groups of its hierarchy <wingo>paron_remote: scrolling give a v retro moiré effect :) <mark_weaver>that's a drag about offlineimap being broken though :-( <mark_weaver>well, it gives me confidence that the graft worked, anyway :) <mog>paron_remote, how is that image possible <wingo>mark_weaver: i searched mailing lists and the logs and didn't find somethign about offlineimap; so sorry to bother you but what is the problem? <paron_remote>mog: probably did a "take a screenshot without the cursor" thing <mark_weaver>wingo: some python code is trying to dynamically link a symbol SSLv2_method that no longer exists <mog>no i mean that the eyes arent all looking at same point <mark_weaver>ImportError: /gnu/store/f0jzhl04iyaqv56yj92cd9bk57p3inqx-python-2.7.10/lib/python2.7/lib-dynload/_ssl.so: undefined symbol: SSLv2_method <lfam>mark_weaver: The OpenSSL update removed support for SSLv2. Can we disable Python's use of it? <wingo>so it is a python 2.7 problem in a way <lfam>I think I'm wrong. The update disabled SSLv2 but did not remove the possibility of building with it <mark_weaver>I don't have time to look into it right now, but if you want to, that would be great! <lfam>No, definitely should not reenable sslv32 <civodul>paron_remote: re "system error", it might be that elogind was not started yet, but pam_elogind tries to talk to it <civodul>i've seen it when explicitly stopping elogind, but not otherwise <wingo>i wonder what would wedge it into that state <wingo>i have never seen it but that doesn't say much :P <civodul>paron_remote: re x11, twm is flat design, i guess it should be in fashion again? :-) <wingo>right but i wonder why elogind would fail to start / be available / etc <paron_remote>civodul: wingo: I don't really know but that seems likely <civodul>but i think mingetty does not explicitly depend on elogind <civodul>so that could happen in theory if you type very fast ;-) <paron_remote>slim crashes and I get "system error" when trying at the getty <wingo>looking in my logs i see elogind getting respawned a couple of times <wingo>i guess we are hitting shepherd's respawn limit in some cases/ <wingo>of course we should never need to respawn <wingo>so that's the bug, that elogind deps are somehow not present <civodul>it seems it doesn't leave any log though <wingo>and of course whatever is printed out on the console by elogind is lost, sadly :P <civodul>we could try 'guix system vm' and console=ttyS0 <civodul>well i'm going to bed :-) but we should definitely investigate <wingo>could be a mising dep on udev or something <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. <lfam>I guess not. They both seem to resolve to the same IP <lfam>Much thanks to however is providing the resources for the mirror! <lfam>mark_weaver: I'll try to look into the python issue in a little while. How can I reproduce that error message? 