*davexunit pushed pypi importer patch <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' <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 <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/ <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. :) <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>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. <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. <jxself>Well, he'll have even more to do soon. <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? <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. <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?) <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. <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>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 mozilla.org 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? :) <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. ***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>Says he's almost done modifying his scripts to ff31 ESR <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 ftp.fnu.org though. *mark_weaver goes afk for a bit <jxself>Hmm. fnu.org seems very different. *mark_weaver goes afk again <jxself>Still being worked on as I understand it though. <jxself>But at least it's for the newer version. <mark_weaver>serialization.scm uses get-bytevector-n in quite a few places <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? <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) <civodul>actually we could just globally rebind get-bytevector-n