IRC channel logs


back to list of logs

*davexunit pushed pypi importer patch
<davexunit>ooh, I really like commit 9ffc1c0
<davexunit>I like seeing good uses of lazy evaluation.
<civodul>Hello Guix!
<Svetlana>civodul: hi!
<Svetlana>i understand the guix package manager does have the ability to install a couple things at once right? without saying 'blabla something is locked'
<civodul>Svetlana: yes
<Svetlana>oh awesome :)
<Svetlana>i got stuck as i dont fancy buying things like the thingpenguin wifi adapter online and i couldnt find it in local stores (i plan to either install guix on a vps or get ethernet, i dont know what would happen earlier)
<civodul>i ended up ordering one of these together with someone else, from the Internet
<civodul>h-node does list a few other dongles that one is more likely to find in regular stores
<civodul>however these are "big" dongles
<davexunit>a lot of threads on HN today mention the proliferation of package managers for every programming language or exstensible program.
<davexunit>here's to hoping nix/guix gain more traction. unfortunately, some people completely dismiss them because they don't run on windows, but whatever.
<_`_>why should windows be a target? idgi
<_`_>maybe windows with cygwin, msys, or SUA, but I still don't get it.
<davexunit>_`_: if the language has a windows runtime, they want their dev env to work there too.
<davexunit>in which case, keep using the language-specific package managers.
<DusXMT>Does anyone know how to change the directory where openssl-based programs should look for certificates?
<davexunit>does the openssl package definition give any hints/
<davexunit>any search paths?
<DusXMT>The easiest solution would just be to let it know where to look for the openssl forler on startup, but looking at the web and documentation, it seems to be hardcoded in.
<mark_weaver>DusXMT: if your system has /etc/ssl/certs/ca-certificates.crt (as on Debian derivatives), then you can set SSL_CERT_FILE to that. that's only for openssl though.
<mark_weaver>DusXMT: programs that use gnutls each have their own way of configuring this.
<civodul>we should create /etc/ssl/certs in the OS
<mark_weaver>I have a patch to make gnutls look in /etc/ssl/certs for the system-wide CA trust store, but Andreas didn't like it so I never ended up pushing it. I run it locally on my own system though.
<DusXMT>mark_weaver: Excelent, thank you, at least this is something
<mark_weaver>also, for git, you need to set GIT_SSL_CAINFO=/etc/ssl/certs/ca-certificates.crt
<mark_weaver>I also have SSL_CERT_DIR=/etc/ssl/certs which assumes a Debian layout, but it might be unnecessary as long as SSL_CERT_FILE is set.
<civodul>mark_weaver: please re-ping for the GnuTLS patch
<mark_weaver>okay, I'll try to remember. I'm a bit overloaded at the moment.
<DusXMT>I'm curious, is there a licensing problem of some sort that we don't include ca-certs in Guix, is it difficult to package, or is there some other reason?
<mark_weaver>well, there's no single official upstream ca-certs package to add, and we have to decide which CAs to include.
<mark_weaver>so, we'd essentially have to choose some other organization to follow (mozilla, debian, icecat), or compile/maintain our own set of CA certs to include.
<jxself>Hmmm. That last option sounds good. :)
<mark_weaver>compile/maintain our own?
<mark_weaver>are you volunteering for the job? :)
<jxself>I'm just throwing out ideas. Isn't that what people do at the start? And see what sticks?
<mark_weaver>yes, of course, I'm not say it's a bad idea, just that someone would have to do it :)
<jxself>For example, it'd be nice if CA cert were included. Mozilla's not done this. So if the decision were to follow Mozilla hopefully an additional one could be added. :)
<mark_weaver>for the time being, I would suggest following Debian, and we still make the CAcert decision independently.
<mark_weaver>*can still make
<mark_weaver>I would suggest following IceCat, but the last release is from almost a year ago with no security updates :-(
<jxself>There is a version 31 on the Trisquel devel site.
<mark_weaver>but if IceCat can become more actively maintained, it would be the natural choice.
<jxself>I'm sure stuff will make its way over to the GNU FTP site at some point but I'm not sure of quidam's plans.
<jxself>Much time has been spent debating RMS on issues...
<mark_weaver>I saw that there are new versions of IceCat in the form of Trisquel packages, but it would be good if there was an upstream tarball for the rest of us.
<jxself>But automatically using TOR when you enter private browsing mode is kinda nice.
<mark_weaver>don't get me wrong, I'm grateful for all that quidam does, but he's only one person, with too much to do.
<jxself>There's a tarball :)
<mark_weaver>well, it doesn't have the NSS security flaw fixed.
<mark_weaver>I guess maybe that doesn't matter for trisquel if they use Ubuntu's separate NSS package, we as I recall IceCat has NSS bundled internally and that's the one we use.
<mark_weaver>*but as I recall
<mark_weaver>(ugh, too many typos)
<jxself>Well, he'll have even more to do soon.
<mark_weaver>what's that?
<jxself>If they take him.
<mark_weaver>ah, interesting.
<jxself>Ah, I found the helper.
<mark_weaver>well, for now, maybe we should take the icecat_31.0+gnu3 tarball from trisquel, and apply the NSS CVE fix ourselves.
<jxself>I think his plan might be to follow the ESR version?
<jxself>Given what's in there.
<mark_weaver>on the gnuzilla ML I saw him mention that he hopes to release an icecat 32 and generally to release them fairly soon after mozilla does.
<jxself>Ah? OK.
<mark_weaver>jxself: would you like you update our icecat package to icecat_31.0 from trisquel plus any security fixes that aren't yet in it? (NSS is the one I know of off-hand)
<mark_weaver>right now, our icecat doesn't even build on i686, and it probably shouldn't be used in its current state anyway.
<jxself>I'm not sure I'm qualified. Plus, none of my machines have 8GB of RAM.
<jxself>I once read Mozilla's instructions and they said you might run into memory-related errors with less.
<mark_weaver>hmm, well, if it really needs that much our build farm will have to be adjusted to only build icecat on machines with that much. (do we have any?)
<jxself>Yes. wildebeest has 16.
<mark_weaver>our browser situation in Guix is dire right now.
<mark_weaver>jxself: isn't wildebeest your machine? you said none of your machines had 8.
<jxself>Well, yeah. I don't really consider it "mine" though. Mentally for me it belongs to the Guix project.
<mark_weaver>upgrading icecat is important work for the Guix project. I think it would be a _very_ good use for that machine.
<civodul>we should use Trisquel's icecat tarball + known security patches
<civodul>we can take security patches directly from Mozilla i suppose
<jxself>Given that it's on the Trisquel development machine making a copy is probably best as it may disappear any any time as quidam works on things.
<mark_weaver>in fact, I would go so far as to say that upgrading icecat is more important work for wildebeest than being a build slave.
<jxself>er; at any
<civodul>mark_weaver: isn't it the same activity?
<mark_weaver>well, yes :) but if jxself felt that wildebeest should be removed from machines.scm while he works on building/debugging icecat-31, it would be well worth it IMO. (but I'm not sure it's necessary)
<jxself>I imagine TOR needs packaging as a dependency?
<mark_weaver>we already have tor.
<mark_weaver>we even have a tor service for dmd
<jxself>Hmm. I didn't see it. OK.
<jxself>Oh duh. There it is...
<mark_weaver>we've had that for many months.
<mark_weaver>jxself: I would be most grateful if you would be willing to do this. My biggest machine has only 2GB of RAM, and besides I'm swamped with Guile work. and I have no graphical browser on my Guix system currently :-(
<jxself>I'm not sure of my ability to complete it though...
<jxself>It's nice that you seem to have more faith in that though.
<mark_weaver>I don't think any of us is particular familiar with the Mozilla code. I would just read the build instructions and hunt on for security fixes for version 31.
<mark_weaver>and then fail to build it because I don't have enough RAM.
<mark_weaver>whatever you come up with would be far better than what we have now.
<jxself>Well, swap counts as RAM right? :)
<jxself>Except for being much slower.
<mark_weaver>if you don't want to do it, you can just say so :-P
<mark_weaver>anyway, it's not good that we're in the position of having to do this work ourselves. it's a problem that needs to be fixed in IceCat itself.
<mark_weaver>and again, I'm not blaming anyone, just saying that the IceCat clearly needs more help.
<mark_weaver>*IceCat project
***jlicht is now known as jlicht|away
***jlicht|away is now known as jlicht
<jxself>mark_weaver: In talking to quidam I found his plans have changed a little.
<jxself>Specifically, locking Icecat to Firefox v31 Extended Support Release. In that way all the patches the torbrowser people are porting to v31 get included.
<jxself>And the NSS issue appears to have been fixed in Firefox ESR 31.1.1:
<mark_weaver>sounds good to me!
<mark_weaver>thanks for looking into it.
<jxself>Says he's almost done modifying his scripts to ff31 ESR
<jxself>So hopefully soon. :)
<mark_weaver>FYI, is the relevant ticket on our end
<mark_weaver>I was about to post an appeal to guix-devel, but maybe I'll hold off a bit on that.
<jxself>I'm still not sure what his plans are for putting the modified source tarballs on though.
<jxself>er gnu
*mark_weaver goes afk for a bit
<jxself>Hmm. seems very different.
<mark_weaver>fyi, I asked what they do on #parabola. their icecat is apparently still old and security-flawed, but here are their recipes for making iceweasel comply with the FSDG:
<mark_weaver>so we might consider adding that too
*mark_weaver goes afk again
<jxself>quidam's icecat stuff lives in git on Savannah if that helps:
<jxself>Still being worked on as I understand it though.
<jxself>But at least it's for the newer version.
<mark_weaver>civodul: I had an idea about the memory corruption. maybe it's caused by ?
<mark_weaver>(now fixed, but not in 2.0.11)
<mark_weaver>serialization.scm uses get-bytevector-n in quite a few places
<civodul>ooh, it could be, indeed
<civodul>but actually, i'm not sure serialization.scm would trigger that bug
<civodul>because there'd need to be a call to scm_c_shrink_bytevector
<civodul>and here there's probably no shrinking
<mark_weaver>civodul: what about from the (get-bytevector-n p (- 8 m)) at the end of 'read-string' and 'read-latin1-string'? might the padding be missing if the string is at the end of the stream or file?
<civodul>no, the padding is always there
<mark_weaver>it still might be worth trying to failing test with a breakpoint on 'scm_c_shrink_bytevector', just in case some other module that you're not familiar with is using it (e.g. gnutls bindings)
<mark_weaver>Guile's web client uses get-bytevector-n
<civodul>actually we could just globally rebind get-bytevector-n