***Digitteknohippie is now known as Digit
<lfam>ACTION staying up until the sourceforge URLs are fixed <lfam>Phew! Time for a break. Up to "lib" <rekado>bah, I’m stuck on this tiny partition. Two of the packages I’m currently working on require a custom build of LLVM, which is just too big to fit on this partition :-/ <rekado>really need to move my system to the other partition (encrypted LVM) <ng0>why does our lynx have no tls/ssl support? <efraim>i think mainly no one's gotten it working yet <ng0>efraim: thanks for the link <efraim>after asking most people switch to links since it already has tls/ssl enabled <ng0>is there an open bug? <ng0>on our side i mean, which can be tracked <efraim>i don't think we have an open bug for it, but its not easy for me to search since I haven't gotten the hang of emacs for the debbugs interface <ng0>i'd like to see an updated patchworks… I'll set one up on my server, maybe it's less terrible than what we have now <rekado>ng0: updated in what way? Is there a later version with more features? <ng0>features idk, but what we have is definitely not based on bootstrap from the visual looks <rekado>(I haven't looked at the code yet) <rekado>what I miss most is email commands. <ng0>i could not figure out the actual version we have, but it looks old <rekado>I'd like it to behave just like debbugs, actually. <rekado>but with a nicer web interface for the github/gitlab people. <ng0>then there is also the possibility of... what was that name <ng0>i did not setup and test that yet <rekado>the slides contain screenies that all look like the thing we use. <rekado>but ... I don't think appearance is the biggest problem with patchwork right now. <rekado>what's so great about an email-based workflow is that people don't need to sign up somewhere <ng0>I'll file that one bug I have and one feature request of something i did not find, both things which are awful in my opinion <rekado>I'd like to retain this feature. <rekado>sending commands via signed email. <rekado>the server would only have to validate the signature and check permissions, <ng0>well for now email is okay, but once we have something better i'd like to address this step by step <rekado>I'm talking about control via email. <rekado>there should also be some representation of the state, of course. Both HTML and some API. <rekado>I wonder if maybe we could hack something with "mu" <ng0>i'm talking about email going away. I imagine a secure and social coding experience on top of SecuShare. <ng0>thus the 'once we have something better' <ng0>I'm thinking about possibilities and replacements. <rekado>we currently have mailing lists and we lack a way to organise incoming mail. <rekado>patches are getting lost because there's just too much <ng0>for example git is pretty horrible too for other reasons - thought out by people who will never recognize why people might change their names. <efraim>enlightenment and freebsd i know both use phabricator, i haven't looked at it too much yet <ng0>yep that's the current issue at hand :) <ng0>seems like freebsd uses bugzilla in addition for bugs <efraim>there's also redmine, and there's an android client <civodul>which supports patch series, revisions, etc. <ng0>do // instead of http:// or https:// break @url{} in our documentation? <efraim>I don't think it should, but I'm guessing <ng0>i' looking for something else, but i just spotted that mostly http:// is used <efraim>Requires.private in a .pc file is an input or a propagated-input? <efraim>or build it and see how it works <civodul>efraim: 'inputs' unless we care about static linking for that package <mckinley>I'd use --fallback, but gnutls fails to build on my machine <Sleep_Walker>does ./configure work for you correctly on master? (after ./bootstrap) <mckinley>it looks like hydra isn't fully operational and the build for gnutls is failing. Bit of a pickle <Sleep_Walker>hm, when I called `autoreconf -ifv -I /usr/share/aclocal' it passed, probably distro issue <lfam>mckinley: GnuTLS's test suite uses a certificate that has expired. It's currently impossible to build. But, we should have substitutes available for it; I verified this yesterday. <davexunit>that's a source of nondeterminism that should be addressed <lfam>It should be addressed upstream, in my opinion. And they have <lfam>It's impossible for us to audit all the packages for expiring code <davexunit>hopefully upstream didn't just add a certificate that expires *later* <lfam>I think they guard against this problem in general, but this particular test case was missed. <lfam>They use the 'datefudge' program, or skip the test if the program is not available. They forgot to skip this test <lfam>mckinley: What is the result of `guix package --show=gnutls`? And, how does the substitute download from hydra fail? <lfam>Hm, that hash is different from mine: /gnu/store/yawyvnsy54hzjv8rw5p6428v790w1458-gnutls-3.4.7-debug <lfam>mckinley: Any idea how old your Guix is? When's the last time you updated? <mckinley>lfam: I've mostly been installing packages from my git build, but am having a problem I can't seem to get by when using ./pre-inst-env, so thought I'd bootstrap/configure <lfam>I'm wondering when our gnutls package would have changed... I checked that we had gnutls substitutes for the 0.10.0 release tag and the current Git HEAD of a couple days ago <civodul>mckinley: until yesterday, the --version would always print the same version number even in the presence of 'guix pull' :-) <mckinley>efraim: /run/current-system/profile/bin/guix -> /gnu/store/aaw84gcad2szil7z8nfiqxmz8gmapn4x-guix-0.10.0-0.e901/bin/guix <civodul>depends on what ~/.config/guix/latest contains, though <lfam>Between this expiring code, the SourceForge URL change, and the Hydra crash, this was a trying week for Guix! <civodul>i think we've scare away a number of people lately... <mckinley>with guix environment guix, I still can't seem to bootstrap <mckinley>*sigh* I'll have to come back to this later. Need to be somewhat productive today <lfam>I used `guix challenge` to check that Hydra had substitutes for gnutls. That should work, right? <civodul>mckinley: BTW, do you need the "debug" output of GnuTLS? <civodul>it may be that the "debug" output has no substitutes, but the main output has a substitute <civodul>although with a 'guix pull' from yesterday, all of GnuTLS has substitutes on x86_64 <efraim>almost have onionshare working, I think my leftover problems now are from combining guix's onionshare and debian's tor <bavier>efraim: how did the pythong prefix thing work out? <efraim>i got everything installed in the right folders, now i'm going through with substitutes to point to the right spot with the resources <efraim>the package definition is getting a bit long, but I don't know an easier way <efraim>ok, some path I fixed made it work, just served a copy of the gpl-3 to myself over tor <ng0>rekado: eventually I plan to just maintain a finished GNUnet (it's 99% done in my testing overlay, not merged), guix, and their dependencies for Gentoo so that people using Gentoo can use guix in Gentoo… If others participatingin the overlay take over what I maintained I will not care about anymore once I finished moving all the overlay packages to either guix master or our new guix overlay. <ng0>that's the main reason for not dropping it <sneek>Welcome back alezost, you have 1 message. <alezost>rekado: I've tried your package, thanks! The problem is this: look in </gnu/store/…-emacs-25.0.95/share/emacs/> dir. Along with '25.0.95' subdir, there is also '24.5' – oops :-) <alezost>The package definition of emacs has 'install-site-start' phase which calls (version-major+minor version) to get the dir where to put "site-lisp.el". Obviously, the emacs-25 package inherits this directory from emacs-24 <alezost>rekado: I think we can just use the plain "/share/emacs/site-lisp" instead of "/share/emacs/<version>/site-lisp" in the original recipe to avoid this thing. I'll check it and send a patch if it will work <rekado>when I get “waiting for locks or build slots” is it enough to just add new build users to the group? <rekado>(that’s on the shared installation at the institute) <rekado>or is there something else that needs tweaking? <anthk_>and guix pull as an user still doesn't work <mckinley>What is meant when someone says the guix ABI changed? <baconicsynergy>hello! im looking for some assistance in replacing ntp with openntp withon %desktop-services <bavier>baconicsynergy: see the documentation for 'modify-services' <baconicsynergy>im having a difficult time learning guile and the manual isnt much help :/ <bavier>might require a patch from the ML, so that the service and configuration types are exported from their modules <rekado>I have a strange problem involving Emacs, suspend-to-RAM on the last usable kernel for libreboot, and the kill ring. <efraim>that patch to export the services was just pushed <rekado>often after waking up from suspend copying/cutting/pasting in Emacs is extremely slow. <rekado>I had hoped that using packages from Guix would make this disappear, but this problem still exists, sadly <rekado>I’m not sure if this is an Emacs problem, or if it’s caused by the clipboard in XFCE, or if it’s related to any of the packages I use with Emacs. <rekado>oddly, restarting Emacs doesn’t always fix this. <bavier>rekado: I've seen that on my machine too <davexunit>rekado: I think I've had this happen, but not caused by the same thing <bavier>I usually need to reboot for it to go away <davexunit>sometimes at my workstation I run into this problem <rekado>bavier: a reboot is usually the best way for me to get rid of this. <rekado>restarting emacs alone doesn’t seem to be sufficient in all cases. <rekado>it also seems to get worse as time passes. <rekado>(that’s what made me try emacs 25, but that didn’t load my packages.) <Sleep_Walker>reboot sounds like last resort, restarting Xorg is not sufficient? <rekado>Sleep_Walker: well, so far it always just so happened that I ran out of battery power or the laptop fell down … <rekado>bleh, cmake makes it very hard to reorder phases. <rekado>I’m back to building extempore and it wants to compile its standard library, but this requires that everything has been installed already. <rekado>on FHS systems this is not a problem for some reason <ng0>hi .. has the sourceforge situation changed somehow? I had no chance to test for Gentoo, would be weird if my packages in Gentoo would not be affected.