IRC channel logs


back to list of logs

<lfam>I guess so!
<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?
<paroneayea>lfam: okay thanks for the review :)
<bavier>binutils doesn't install liberberty?
<paroneayea>lfam: I'm always impressed with your reviewing when I look at the Guix list btw
<paroneayea>keep it up! :)
<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 :)
<paroneayea>lfam: pushed, thanks
<paroneayea>closing the bug
<paroneayea>ugh, I wonder if we need to fix too
<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
<paroneayea>ah yeah
<paroneayea>ok :)
<paroneayea>I guess I should look more carefully before I raise alarms in here before I turn into
<lfam>It looks like the other two were fixed in 2.32.0
<lfam>And 2.32.1
<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.
<NiAsterisk>ACTION silently yells at GnuPG2.1
<civodul>lfam, mark_weaver: email sent for 22139 :-)
<civodul>ACTION -> zZz
<civodul>good night/day
<mark_weaver>oooh, that's great news!
<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
<mark_weaver>lfam: what are you trying to do?
<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.
<mark_weaver>lfam: what are you going to change the shebang to?
<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
<NiAsterisk>*some up-to-date documentation
<paroneayea>I'm glad that graft stuff has made progress
<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.
<NiAsterisk>maybe I have something
<NiAsterisk>this is recent enough, jan 2016
<mark_weaver>lfam: maybe needs to be patched as well
<lfam>Okay, I'll try that
<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 had the same shebang before.
<davexunit>Jookia: what debian package needs to be installed for graphics acceleration on novena?
<davexunit>I installed the xobs-beta repo
<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>thank you :)
<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: Apprently xobs-beta only updates explicitly installed packages
<NiAsterisk>oh great. gpg2.1 is not compatible with 2.0 in some ways...
<NiAsterisk>i hate gnupg.
<Jookia>it's not great
<NiAsterisk>it's awful, user-fiendly and needs to die as soon as we have something better.
<davexunit>gpg is really nice :/
<NiAsterisk>good software does not require "crypto parties" for people to "eventually" get it. it just works.
<davexunit>Jookia: I have all that installed it seems
<davexunit>but mpv won't use GL to render
<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
<davexunit>I get errors about it
<Jookia>davexunit: from what i've heard you want " -vo=opengl:backend=x11egl:es=yes "
<davexunit>and I can't use webgl
<Jookia>davexunit: Not sure what the story is about WebGL but it might not support GL ES with the Debian build
<davexunit>what flags are those used for?
<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.
<NiAsterisk>I am actively working on solutions.
<davexunit>Jookia: hmm, that set of flags didn't work for me
<davexunit>error while parsing opengl parameter (x11egl
<mark_weaver>NiAsterisk: anything public yet? pointers?
<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
<mark_weaver>so is gnupg-1.4 for that matter
<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
<NiAsterisk>it, and I don't want no discussion. thanks.
<_`_>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
<davexunit>Jookia: maybe mpv is too old
<davexunit>latest upstream is 0.16.0
<paroneayea>I thought I was told "don't install texlive-texmf, just install texlive"
<paroneayea>but when I try to install texlive
<paroneayea>it installs texlive-texmf!
<davexunit>paroneayea: you mean it propagates texlive-texmf?
<mark_weaver>it doesn't propagate it
<mark_weaver>it's just a runtime dependency
<mark_weaver>paroneayea: the Andreas was trying to make is that texlive-texmf should not be in your profile directly
<mark_weaver>*the point
<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 :)
<mark_weaver>ACTION is mostly ignorant of texlive
<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.
<mark_weaver>let me dig it pu
<davexunit>something like:
<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
<davexunit>paroneayea: I need to join in :)
<davexunit>sorry I've been procrastinating
<paroneayea>I like the look of the reveal.js presentations, but building it is another dive into node.js things
<mark_weaver>paroneayea: ^^
<paroneayea>mark_weaver: thanks, will try!
<davexunit>I enjoy a nice static pdf
<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>paroneayea: ah okay!
<rain1>I don't understand
<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>davexunit: I am!
<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>rain1: are you on GuixSD?
<mark_weaver>rain1: does /run/setuid-programs/sudo exist?
<mark_weaver>that should have been put before the other things in your PATH
<rain1>yeah it does
<paroneayea>oh I see what this hack is doing
<davexunit>paroneayea: clever, eh?
<paroneayea>set up the environment with substitutes for building it, then build without substitutes :)
<davexunit>I smiled when I saw it.
<paroneayea>davexunit: yeah :)
<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.
<mark_weaver>rain1: /etc/profile arranges for it
<rain1>this is my bash profile, am I doing something wrong here?
<davexunit>rain1: yes.
<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>ah!! thanks alot!
<rain1>It works now
<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
<rain1>my bad
<davexunit>I run another shepherd as my normal user for non-system related services
<davexunit>like my emacs daemon, mail fetching, etc.
<Jookia>You can run a user shepherd?
<davexunit>yup. it's just a program.
<davexunit>I love it.
<rain1>yeah I'm interested in shepherd
<davexunit>here's my messy config
<rain1>oh that's a shame
<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
<davexunit>wonder what's going on there
<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.
<davexunit>a missing package is a common thing.
<mark_weaver>rain1, davexunit: fwiw, davexunit's site works for me in IceCat on GuixSD
<mark_weaver>although wget doesn't accept it. I filed this bug:
<mark_weaver>some interesting notes there
<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 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.
<davexunit>darn these imperative distros
<Jookia>it's GuixSD's imperative to make all systems functionally the same
<mark_weaver>davexunit: one of the things mentioned in is that reported some problems with your SSL configuration.
<mark_weaver>maybe worth a look
<mark_weaver>(comment #8)
<davexunit>mark_weaver: ah, yes.
<davexunit>thanks for the reminder.
<davexunit>these certificates will expire soon, too.
<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
<davexunit>using the "webroot" method
<davexunit>so that there's 0 server downtime
<paroneayea>hm, is worrying :\\
<paroneayea> too.
<Jookia>paroneayea: Yikes
<davexunit>paroneayea: wow
<davexunit>that composer article
<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>Sandboxed PHP builds? Nope
<Jookia>Who even thought up bundling package managers
<Jookia>Oh the github is worse
<Jookia>davexunit: "When libraries set up their .gitattributes with export-ignore, the tests/examples/docs are excluded from the dist archives.."
<davexunit>Jookia: this drives me crazy.
<davexunit>everyone seems to do this now
<davexunit>releases don't include tests and stuff
<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>see MediaGoblin
<paroneayea>I wrote the development documentation
<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>and guess what
<paroneayea>guess how long that terrible deployment documentation has stuck around
<paroneayea>and tbh
<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>because it's all I knew
<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>yes, very unified.
<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>Jookia: yes, guix import is great
<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
<Jookia>The JS?
<paroneayea>okay two exceptions :)
<paroneayea>you have to create an empty virtualenv that you run "python develop --no-deps" in
<paroneayea>because pytest needs to be able to "find" mediagoblin's paths and stuff...
<paroneayea>I've thought of doing something truly evil
<Jookia>Evil you say?
<paroneayea>and having a package put in the environment profile with the present working directory!
<paroneayea>on the PYTHONPATH and stuff!
<paroneayea>pretty evil-ish
<Jookia>I have no idea what that means but you could write some fancy container code
<Jookia>Jeez, that's evil
<Jookia>I know eric s raymond puts "." in his $PATH
<paroneayea>it would just be for the environment
<paroneayea>it wouldn't be .
<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>to put it another way:
<paroneayea>many python packages rely on this stuff
<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
<paroneayea>davexunit: a satisfying trowback to a 2009 voice of sanity
<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.
<davexunit>and during it he ranted about chromium
<davexunit>maybe a year or so after this blog post.
<paroneayea>Jookia: it will, quite soon I hope.
***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>So a friend of mine just ran 'guix pull' with a fresh Guix install and it wants to download tarballs to build things and fails:
<Jookia>Oops my bad, keys weren't imported
<Jookia>paroneayea: Btw with latest Novena drivers, Crawl is more than playable :)
<civodul>Hello Guix!
<Jookia>civodul: o/ I'm testing my GRUB patches and I think I have them mostly tested for review
<civodul>Jookia: awesome!
<civodul>i'll add it to my list of things to review...
<Jookia>Heh, it replaces the vm-refactor patch I did
<civodul>ah ok
<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>Jookia: ah ha, good question :-)
<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
<civodul>we can vote ;-)
<Jookia>I think something (anything) should be done to stop people from building a Guix incompatible with the 'official' Guix by default
<alezost>or even /gnu/var as was suggested
<Jookia>I think localstatedir is a standard Autotools thing that shouldn't be changed?
<civodul>Jookia: see
<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>ok will do :-)
<civodul>as an experiment, can people try --substitute-urls= ?
<civodul>it's a cache of (same signatures, etc.)
<Jookia>Ooh, a Hydra mirror?
<civodul>right, but it's a cache, so it has to be "warmed up" before it's (hopefully) faster
<civodul>i'd like to see whether it helps
<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
<civodul>"wget -O /dev/null" gives me 10MB/s
<civodul>for i get 2MB/s
<civodul>very unscientific
<efraim>I wish I had good internet speeds like that
<efraim>I cap out at 1.5MB/s down
<civodul>well, that's from my workplace connection...
<Sleep_Walker>food for thought - in case you haven't heard about IPFS: - it could be interesting alternative for distributing binaries...
<efraim>using wget, 1.33 MB/s for, 308KB/s from
<Jookia>Sadly ipfs isn't anonymous
<Sleep_Walker>yeah, it is not intended to be
<Jookia>I honestly feel unsafe using the Internet without Tor these days
<Sleep_Walker>I would feel less safe even with Tor :(
<Jookia>Why's that?
<Sleep_Walker>because I'd miss anonymity of crowd
<Jookia>Interesting, though you can tell everyone apart here
<Sleep_Walker>sorry, I don't understand
<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
<Jookia>We all have things 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?
<Jookia>Nope, why?
<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
<Jookia>Or authenticated
<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 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 is much faster than, 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 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.
<Jookia>i see
<Jookia>Well, new to Guix? :)
<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
<Jookia>Let me guess, shebangs? :P
<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>Ooh emacs
<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, 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, 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.)
<rekado>what happens on a cache miss?
<mark_weaver>on a cache miss you need to wait for hydra to build and compress the nar on-demand, which is quite slow
<rekado>ah, I see.
<civodul>a good test is "sudo rm -rf /var/guix/substitute/cache && guix build libreoffice -n"
<civodul>(to force a redownload of the narinfos)
<mark_weaver>already I see some commits in the openssl repo that might be the ones we're looking for:
<civodul>oh, we're getting there :-)
<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>but maybe I'm missing something
<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
<mark_weaver>although I'm not sure that's even needed
<mark_weaver>the hash should be enough
<civodul>mark_weaver: good points
<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>tryingt to install a package, I get "substitute: updating list of substitutes from ''... 100.0%" repeatedly line after line
<NiAsterisk>stopped after 30 times
<NiAsterisk>now it works
<civodul>uh, weird
<NiAsterisk>not 30, but more than 5 times:
<civodul>BTW, please try --substitute-urls=
<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
<NiAsterisk>ah, okay
<civodul>and for the cache to be useful, it's best if there are several people using it :-)
<civodul>the more, the merrier!
<NiAsterisk>so this is time limited to get the cache going, or is it recommended now to use --substitute-urls= with every hydra interaction?
<piyo>hello is there an announcment about
<civodul>not yet, because it's experimental
<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.
<rekado>R itself does not.
<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
<mark_weaver>civodul: do you think your recursive grafts code is ready to be used for this openssl update?
<piyo>civodul: using with my raspi2/arm, debian jessie foreign guix, upgrading to guix-0.9.0.f888c0b
<civodul>mark_weaver: i think so, or at least it's a good opportunity to test it :-) see
<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.
<davexunit>store item needs to be the same length?
<mark_weaver>if you have time to handle this update, maybe that would be best?
<civodul>ok, i can do it
<mark_weaver>I have to go afk for a while. good luck!
<civodul> ouch!
<civodul>ACTION .oO( when will C & ambient authority cease to be the norm )
<piyo>DROWN ..?
<civodul>"Builds that are not configured with "enable-weak-ssl-ciphers" will not provide any "EXPORT" or "LOW" strength ciphers."
<civodul>EXPORT... at last
<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
<civodul>please see
<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
<civodul>ACTION goes afk for a bit
<davexunit>I'll try it out
<rain1>yeah GHC is a monster
<NiAsterisk>it even comes with cookies
<NiAsterisk>a cookiemonster
<wingo>you are a wizard civodul
<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.
<NiAsterisk>but thanks :)
<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
<rekado>it's an environment variable.
<rain1>shall I just add XDG_CACHE_HOME=/tmp/.xdgcache/ to my bash profile
<rain1>and make that folder
<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
<rain1>but it's already caching
<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?
<myglc2>lfam: I'll look at it, thanks.
<davexunit>hydra is horribly slow right now.
<rain1>yeah i think it would be cool to try alternative like torrent or ipfs?
<lfam>davexunit: Did you read about in the log?
<paroneayea>grafts are in git master now? whaaa? :)
<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.
<lfam>99 MB seems very large!
<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 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
<paroneayea>davexunit: use --substitute-urls=
<paroneayea>going much more quickly that way
<lfam>The more the merrier
<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
<paroneayea>assuming guix recursive grafting works
<paroneayea>that merits a blogpost or news item or whatever
<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>grafting seems to work just fine
<davexunit>I updated my profile and am in the process of updating my system.
<davexunit>no issues thus far.
<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
<paroneayea>since it not always has been
<davexunit>paroneayea: it's just a convenience.
<davexunit>so I can send people links to the presentation from the git repo viewer
<paroneayea>ACTION nods
<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
<rain1>(oh its --ad-hoc)
<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>gtk+-2.24.28-doc got grafted
<efraim>gotta keep the documentation safe from DROWN :D
<davexunit>I was able to update my user profile and system without issues
<davexunit>therefore I think grafts were a success!
<efraim>gtk2 just got grafted twice
<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>NiAsterisk: Sounds okay
<lfam>efraim: The outputs had different hashes in their names? Or they failed '--check'?
<efraim>different hashes
<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
<civodul>oh right
<civodul>indeed i have both w3kx and mh111
<civodul>but w3kx has no referrers
<efraim>guix gc --references is identical, except where they reference themselves
<civodul>dunno where it comes from
<civodul>interesting, isn't it?
<lfam>OpenSSL builds reproducibly for me, FYI
<efraim>mh111 -> pinentry
<efraim>that one is pretty strange
<lfam>What do you mean? It points to pinentry?
<efraim>that there's the second one
<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/ 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>how stable is guixsd considered?
<bavier>ecraven: beta
<NiAsterisk>ecraven: define your definition of stable
<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>lfam: that's what I plan to do
<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
<ecraven>why is guile 2.0.1 shown twice on
<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>lfam: ok, I'll do that, thank you!
<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/..?
<ecraven>ah, bootstrap :)
<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>is that a problem?
<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
<NiAsterisk>yes, at least irssi was moved to irc.scm
<lfam>ecraven: I'm referring to installing Guix the package manager with your current OS, not the full GuixSD installation
<lfam>weechat was also moved
<ecraven>lfam: yes, but I'd prefer to try it in a vm, not on my current system :)
<lfam>Okay :)
<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>yes, it was just missing the pngs
<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 about this :)
<ecraven>lfam: I'll see whether I can fix it tomorrow, then I can send a patch :)
<lfam>Okay, thanks!
<ecraven>thanks for your help!
<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>occasionally when I boot into guix
<paron_remote>and I try to log in
<paron_remote>I get the mysterious message "system error" and no ability to log in
<paron_remote>then I reboot and it's fine.
<ecraven>just a short followup, an epub generated along this random google search result ( 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
<mark_weaver>paron_remote: hmm, strange, I haven't seen that
<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
<davexunit>wingo: oh cool
<davexunit>the mroe I know
<wingo>that seems to indicate that elogind should indeed create a cgroup hierarchy directly
<paron_remote>today I am enjoying
<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
<paron_remote>mark_weaver: quite the fix :)
<paron_remote>I guess it means https is not available at about 30% of sites based on
<wingo>paron_remote: scrolling give a v retro moiré effect :)
<paron_remote>wingo: :D
<paron_remote>so good
<wingo>xeyes 4 eva
<mark_weaver>that's a drag about offlineimap being broken though :-(
<mark_weaver>I'm a user of that program, so I sympathize
<mark_weaver>well, it gives me confidence that the graft worked, anyway :)
<wingo>offlineimap broken!
<paron_remote>guess I'm glad I had switched to fdm...
<paron_remote>(feast your (x)eyes!)
<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
<paron_remote>delightful, regardless
<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
<wingo>mark_weaver: exciting :)
<mark_weaver>ImportError: /gnu/store/f0jzhl04iyaqv56yj92cd9bk57p3inqx-python-2.7.10/lib/python2.7/lib-dynload/ 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>A big one
<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!
<mark_weaver>I'm dubious that we should reenable SSLv2 though
<paron_remote>if we re-enable SSLv2, won't we be drowning again? :)
<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>that's a bummer!
<wingo>i wonder what would wedge it into that state
<wingo>i have never seen it but that doesn't say much :P
<civodul>it's inherent to pam_elogind AFAICS
<civodul>(that elogind must be running)
<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
<civodul>right, i wonder too
<paron_remote>civodul: wingo: I don't really know but that seems likely
<paron_remote>since other services start up
<paron_remote>I just can't log in
<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
<paron_remote>well it doesn't suddenly work later though...
<wingo>looking in my logs i see elogind getting respawned a couple of times
<wingo>before it sticks
<wingo>i guess we are hitting shepherd's respawn limit in some cases/
<wingo>see your dmd.log
<wingo>of course we should never need to respawn
<civodul>yes, that's weird
<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
<civodul>so, later!
<wingo>could be a mising dep on udev or something
<wingo>ACTION sleep too
<wingo>hashtag france sleep
<wingo>night :)
<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>Is <> different from <>?
<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?
<lfam>ACTION leaving