IRC channel logs


back to list of logs

<civodul>Hello Guix!
<rekado>Hi civodul!
<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
<civodul>alezost: what's your take on it?
<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>rekado: ooh, ok
<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>alezost: ooh, maybe, dunno
<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?
<rekado>snape: no.
<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: Good Morning. I still need advice about when to use which type of input for Python. See
<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?
<rekado>the failure of gcj on arm and mips is sad. I’d like to try this patch:
<rekado>maybe this fixes the arm build.
<paroneayea>moin moin
***[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.
<paroneayea>ACTION doesn't know either!
<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
<htgoebel1>civodul: Thanks.
<janneke>civodul: thanks for pushing rottlog-service and doing all the remaining work, typos, better explanation etc.!!!
<janneke>, commit msg
<civodul>janneke: yw!
<civodul>i'm a happy user now :-)
<janneke>:-) yay!
<janneke>sorry for all the typo's!
<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
<civodul>would be more convenient
<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>rekado: not at the moment
<bavier>it'd be need to have a qemu build-hook for the daemon
<bavier>rekado: thanks for haskell.scm patch to unpropagate inputs :)
<civodul>rekado: gcj is no more :-/
<snape>rekado: first HN comment, nice :)
<civodul>oh indeed :-)
<civodul>i'm always late
<civodul>hmm WordNet is broken
***[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>hi lfam!
<civodul>fine with me!
<civodul>i'm happy we're making progress on core-updates :-)
<xieyuheng>civodul: hi
<xieyuheng>I saw a translation of 'Ainsi, pour la région intérieure à une sphère' as 'Thus, for the region inside a sphere'
<xieyuheng>is it right ?
<civodul>xieyuheng: right
<civodul>it's a surprising question you're asking here, no? :-)
<xieyuheng>you are the only french I know
<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
<civodul>and openssl is my use case :-)
<lfam>Okay :)
<lfam>I will discard the commit I made :)
<lfam>Locally, that is
<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
<civodul>is that correct?
<civodul>i thought 1.0.2j was the latest one
<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?
<Drakonis>instead of booting from a usb?
<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 :)
<ng0>i have no choice :)
<civodul>lfam: just pushed!
<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
<lfam>ACTION nods
<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>bah, I need more memory.
<lfam>So I wonder about the CVE database. Taking CVE-2016-2177 as an example, MITRE says it is present "through" 1.0.2h. I wonder if their database needs to be updated.
<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
<Drakonis>and then set everything up
<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
<civodul>lfam: found the 'guix lint' bug
<lfam>Ah, that was fast :)
<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
<lfam>This recent blog post on the topic was illuminating for a newbie like me:
<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?
<lfam>ng0: This is the patch you asked about a couple minutes ago?
<ng0>that 17 years old is the last i686 i have :)
<bavier>ng0: i686 are built on x86_64
<ng0>lfam: yes, minus the gnunet-gtk
<ng0>oh.. thanks bavier
<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
<civodul>ACTION -> zZz
<rekado>guix-devel certainly is not for the casual reader.
<civodul>good night/day!
<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>thanks :)
<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
<ng0>created: 1989-03-01
<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.
<lfam>Thanks, found it
<ng0>btw, new gnunet moved to python3 now, so one more package which can drop python2 with the next versio nrelease :)