<civodul>so, should we build our Emacs with xwidget support, that is the question <civodul>having WebKit in my Emacs sounds both exciting and scary <alezost>civodul: I've never looked at that feature, so I don't have an opinion. <alezost>However I thought Guix's policy is to stick to the default configure options, no? Besides, the current Emacs version doesn't include rekado's improvements in this xwidget area :-) <rekado>civodul: I don’t think we should <rekado>I’m running with xwidget support and it consumes *a lot* more memory <rekado>also it’s not very usable at this point <rekado>I have a couple of patches (more than what’s on emacs-devel) that are still waiting for copyright assignment (I’ve already sent a signed form), but there’s much more work to be done beyond that before this can be used as an actual browser. <civodul>good to know that you've looked into that more closely than i have :-) <civodul>alezost: we stick to default option, but here it's a question of whether to add an optional dependency <rekado>guile-next fails to build on armhf and mips. Is there a fix? <alezost>civodul: is it? I thought that xwidget feature is disabled by default, and there should be some additional configure option to enable it <civodul>rekado: not sure, we should ask wingo & mark_weaver <civodul>it was advertised as *the* big feature <rekado>I was a little disappointed by the xwidget feature. It’s cool, but seems to have been merged a little prematurely. <snape>is guix'emacs built with the xwidget feature, btw? <snape>yeah because it doesn't work well I guess <rekado>I have a custom package variant that enables it. <snape>I really like the tls thing with emacs 25 <htgoebel1>civodul: Packages in python.scm are very inconsistent. <htgoebel1>civodul: While working on the new python-build-system, I stumbled about some issues and I need to know whichway to go. <htgoebel1>civodul: Who is the one to competently tell who packages should look like in the store (links, copies, .pth-file) and how we want to handle (not not handle) different version of the same package in one environment? ***[0xAA] is now known as Fishy
***Fishy is now known as Zer0Pings
<paroneayea>yay, I'm so happy to have an openssh service now in guixsd :) ***tschwing_ is now known as tschwinge
<jmd>We always had dropbear and lsh :) <paroneayea>jmd: I never tried playing with dropbear... I had trouble with lsh, as a client, but I guess I never really tested it as a server :) <jmd>My experience is that it works better as a server than as a client. <jmd>But perhaps it would not stand up to large loads - I don't know. <janneke>ACTION has been quite happy with openssh client and lsh-service ***[0xAA] is now known as Zer0Pings
<civodul>htgoebel1: good point, i'll reply to your message, but it seems you got the rules right :-) <civodul>i've used lshd for a long time, but i'm now concerned that it's not really maintained anymore <janneke>civodul: thanks for pushing rottlog-service and doing all the remaining work, typos, better explanation etc.!!! <civodul>i have another tweak locally to avoid restarting syslogd once for each file <civodul>eventually we'll prolly want to replace rottlog's period files with Scheme records <rekado>I’m trying to cross-build gcj for armhf, but the bootstrap toolchain for armhf on x86_64 is no longer available. <rekado>tried to build it all from source but the build of make fails <rekado>in the unpack phase with this error: “In execvp of tar: No such file or directory” <rekado>I tried this command: “./pre-inst-env guix build --fallback --max-silent-time=300 --target=armhf-linux-gnu gcj” <rekado>that’s the derivation for make-boot0 failing <rekado>can I make the guix daemon use qemu instead of cross-compiling things? <bavier>it'd be need to have a qemu build-hook for the daemon <bavier>rekado: thanks for haskell.scm patch to unpropagate inputs :) <snape>rekado: first HN comment, nice :) ***[0xAA] is now known as Zer0Pings
<lfam>Hm, it seems that GuixSD has a regression in the shut-down sequence. I can't actually get my system to halt <lfam>I must have been mistaken about that failure-to-halt. It seems to be working fine now <lfam>Hi civodul! I'm going to push the libarchive changes to master and then core-updates in a little while, if that's all right <civodul>i'm happy we're making progress on core-updates :-) <xieyuheng>I saw a translation of 'Ainsi, pour la région intérieure à une sphère' as 'Thus, for the region inside a sphere' <civodul>it's a surprising question you're asking here, no? :-) <paroneayea>lfam: I'm glad to hear we're not suffering from the halting problem ;) <lfam>We have indeed solved it :) <lfam>civodul: We should also ungraft openssl on core-updates, right? I can do that now <civodul>lfam: wait a second, i have lifted the restrictions on graft name/version strings <lfam>I will discard the commit I made :) <civodul>gnu/packages/tls.scm:372:2: openssl-1.0.2j: probably vulnerable to CVE-2016-2177, CVE-2016-2178, CVE-2016-2179, CVE-2016-2180, CVE-2016-2181, CVE-2016-2182, CVE-2016-6302, CVE-2016-6303, CVE-2016-6304, CVE-2016-6306 <lfam>1.0.2j is the latest one. It looks like that code is still referring to the ungrafted name (1.0.2h) <Drakonis>hm, i have a pretty bad question, can i use guix to convert a existing install into guixsd? <lfam>I will spot check some commit / tag pairs, but hopefully I haven't been *that* wrong about patching openssl bugs <civodul>lfam: i think lint is really looking at 1.0.2j <civodul>if something's to blame, that's most likely one of the tools rather than your work :-) <Drakonis>civodul, don't blame the tools man, blame the man :V <lfam>civodul: Does the new code take into account that there is a 1.0.2i release between the grafted version and ungrafted version? <ng0>i sent an email out on this, but just to mention again here: lfam, civodul: you are using the wrong thread and a cached file in the perl-net-psyc thread. <lfam>ng0: I saw that, thanks for persevering :) <lfam>I know the psyc stuff is your priority so I am trying to keep it on top of my to-do list :) <civodul>lfam: 'guix lint' simply looks at the version number of the replacement package <civodul>then looks it up in the CVE database <ng0>I'll be busy writing and testing gnunet and psyced service this month, so they will be usable in november. <civodul>lfam: previously, since the version number was inaccurate, it was reporting useless info <ng0>can you also push the gnunet patch? I can resend the gnunet one without gnunet-gtk change as i am not sure about the gnunet-gtk one <ng0>there's also a guix.scm in gnunet now. <rekado>every day I’m running out of memory and my system thrashes about for 40 mins. <lfam>I notice that MITRE says some bugs are present "through" and other bugs are present "before" a particular version <rekado>shouldn’t run so many Guix builds on this machine… <lfam>rekado: Thrashing... spinning disk? <rekado>lfam: well, actually this is an SSD. So it’s just swapping, but really badly. <ng0>i have a question. can we use openssh daemon now for guix offload? or is it still lsh? <lfam>rekado: I found that building is resource intensive no matter what. Even if the disk if fast, compilation can use enough memory that the page cache is not very big <civodul>ng0: the daemon can be anything; the client still has to be lsh <rekado>I only have 4GB but Emacs with xwidgets really eats a lot. <lfam>Ah, 4GB is not really so much for a builder :) <ng0>so there needs to be lsh on the build server and client, but the sshd can be anythin? <rekado>(lots of webkit processes spawned by Emacs even when not actively using webkit) <Drakonis>bleh, i feel stupid now, so i can do the guixsd installation only with guix <lfam>BTW, I don't recommend putting it on btrfs, at least with however Debian configures it. If I am building and my automated backups kick in, btrfs may start doing things internally, and then I've seen load go to 40 on a 4-core machine <rekado>if my SSD survives this abuse it’s not so bad. I finally get some time to read a few more pages of “Essential Cell Biology” <lfam>That's with spinning disk btw <ng0>I'll try to setup offload on the next machine, so I'll get a practical answer <ng0>before I restore an 17 years old machine: can i686 be build on x86_64 for guix or do we need dedicated hardware for that? <ng0>that 17 years old is the last i686 i have :) <ng0>lfam: yes, minus the gnunet-gtk <lfam>ng0: This one? "[PATCH 1/2] gnu: gnunet: Add inputs." <ng0>it's comparable to what's inside gnunet now, though the gnunet one includes builds for all databases at the same time :) <rekado>to build for i686 on x86_64 do “guix build -s i686-linux the-package” <ng0>hm.. and building an i686 system image would be the same and documented iirc <ng0>feedback on our mailinglist from someone who's looking to get started: for the casual reader it's impossible to follow the guix-devel list or find info in a reasonable time .. or what it was they said <ng0>I do some conversation / pr0oblem solving outside of irc and email <rekado>guix-devel certainly is not for the casual reader. <lfam>ng0: What sort of info is your colleague looking for? Would help-guix be better for them? <ng0>i'm not sure.. among other things a weird bug I can only investigate on site. other than that, i had too much talk today and can't remember what else there was <ng0>*talked too much today <lfam>guix-devel will not help if you talked too much today. The volume is immense <ng0>i know that :) that was an unrelated comment to express that I can't recall what the information is they want <ng0>i took some time off today and went to the political hacker space I wanted to get in touch with.. friendly people :) <lfam>That sounds like a good day :) <lfam>ng0: I pushed that patch to Savannah <lfam>I will read the psyc thread again later today <ng0>I really don't know what happened with the server move and files hash.. <lfam>Well, the source does come over HTTP, so it could be anything by the time it gets to my computer :) <ng0>well there's an onion.. but we can't use that in guix. <ng0>I've checked and calculated this more than one time. <ng0>oh and the shasum is also in the download dir. but not signed.. lynX should sign files.. one of the oldest keys I've ever seen :D <lfam>One step at a time... something about living in glass houses <lfam>What kind of key is that? <lfam>I didn't know that PGP existed before 1991 <ng0>i've forgotten.. it's on the keyservers <lfam>What's the fingerprint? I want to take a look at it :) <ng0>asearch for lynX and the bottm result / oldest. <ng0>btw, new gnunet moved to python3 now, so one more package which can drop python2 with the next versio nrelease :)