IRC channel logs

2018-09-03.log

back to list of logs

<civodul>Hello Guix!
<efraim>hi!
<roptat>hi guix!
***rekado_ is now known as rekado
<rekado>Hello!
<nly>Hello!
*rekado gets a gateway timeout on berlin.guixsd.org
*rekado restarts cuirass
<efraim>long shot, anyone have an image of a ppc64 system? debian stable isn't bootstrapping cleanly and testing and sid give instruction errors in qemu
<nly>DIY'ed my desk, using the keyboard is comfortable now :)
<roptat>iiuc, a channel other than guix must have its package modules at the top level, correct?
<roptat>so (java) instead of (more packages java) in my case, right?
<roptat>if that's the case, where should I put patches my packages need?
<efraim>i assume it'd be like GUIX_PACKAGE_PATH
<efraim> https://gitlab.com/Efraim/my-guix i have mine in the top level
<roptat>with GUIX_PACKAGE_PATH, I put patches at the top level, and one of my module is (more packages java) for instance
<efraim>I assume it would depend on 'search-patches'
<roptat>but I remember ludo said package modules should be at top level in the case of channels
<roptat>so I was wondering about patches
<civodul>roptat: if you have a (more packages java) module, then it must exist as more/packages/java.scm, not a/b/c/more/packages/java.scm
<roptat>civodul: oh, then that's fine :)
<roptat>thta's just how GUIX_PACKAGE_PATH works
<roptat>how do you think we should work on a channel? I don't really want to run "guix pull" to test every change I make in my channel
<rekado>(test the changes with GUIX_PACKAGE_PATH maybe?)
<roptat>ok, that's reasonnable :)
<rekado>python-scipy fails its tests since a while.
<rekado>I don’t see which of the tests has failed, though.
<rekado>it looks like “scipy/sparse/linalg/dsolve/tests/test_linsolve.py::TestSplu::test_threads_parallel” just aborts violently.
<rekado>will try to skip that test
<rekado>there have been new releases to scipy and co; guess we should upgrade them together.
<civodul>roptat: yeah you can use GUIX_PACKAGE_PATH when testing
<dustyweb>hello friends
<civodul>hello dustyweb!
<dustyweb>heya civodul :)
<rekado>hi dustyweb!
<dustyweb>hey rekado :)
<dustyweb>civodul: I am writing up a little libchop/tahoe inspired demo
<pkill9>hey
<dustyweb>suggestion is to add an encryption key field to magenet: uri scheme, and then a pattern for when dereferencing that reading it as a manifest file and fetching its contents as chunks
<dustyweb>er, magnet:
<dustyweb>so magnet:?xt=urn:sha256:<hash>&key=<decryption-key-here> etc
<civodul>dustyweb: i guess that would work
<civodul>you may also want to specify the encryption algorithm
<civodul>and perhaps its parameters, if any
<civodul>(libchop does that though it may be overengineered)
<dustyweb>oh right
<dustyweb>that's something I had written down in my original mockup, but did not write it down in my code :)
<dustyweb>thanks for catching
<civodul>:-)
<civodul>do you have content-addressed storage/convergent encryption as part of this demo?
<dustyweb>civodul: yes, it's optional but suggested
<dustyweb>hash first and use that as the key
<dustyweb>but not necessarily required
<civodul>awesome
<dustyweb>you could use a different key
<civodul>you're doing this in Guile?
<dustyweb>civodul: so the goal here is to start a conversation about bringing "object permanence to the web", securely
<dustyweb>civodul: heh, this demo is in racket but I might write a guile version too
<dustyweb>civodul: it may be useful for guix?
<civodul>that's neat anyway!
<civodul>it could be useful for Guix, yes
<civodul>for substitutes
<dustyweb>yes
<dustyweb>civodul: cool, I'm going to finish the version I'm working on and the writeup, toss it to you to see what you think, and if you think it's a good general idea I'll write a guile implementation... what do you think of that?
<civodul>i think it's great, "object permancence" sounds like a very useful endeavor!
<dustyweb>:)
<civodul>the Software Heritage folks worked on "intrinsic" identifiers (roughly content hashes) etc., but it's specific to source code
<pkill9>what is object permanency?
<pkill9>permanence*
<dustyweb>pkill9: it's partly a joke, "object permanence" being the skill that infants learn that objects do continue to exist
<dustyweb>but on the web
<dustyweb>data disappears and rots all the time
<civodul>the way i understand it is having a way to refer to objects that's more reliable and unambiguous than URLs
<pkill9>oh ok lol
<dustyweb>yes that
<dustyweb>well
<pkill9>ah ok
<civodul>dustyweb: oh i hadn't thought of that reference :-)
<dustyweb>more reliable than http(s) urls :)
<dustyweb>civodul: I borrowed that joke from my friend bigbluehat :)
<civodul>heh
<civodul>roptat: speaking of which, you had been working on a BitTorrent implementation or something like that, no?
<dustyweb>I was just about to say "civodul: btw I've considered also that it may be worth writing a very minimal bittorrent-inspired p2p protocol (I guess we could even use bittorrent) to ship these around"
<dustyweb>if we're considering having substitutes that can be shared
<civodul>definitely
<dustyweb>civodul: then we could also start relying on that for sources
<civodul>yes
<dustyweb>since the biggest problem with Guix's stability in a sense is that it relies on the world's biggest mutable database
<dustyweb>the web ;)
<civodul>exactly :-)
<dustyweb>civodul: cool. Okay I'm going to shower and then get back to hacking!
<dustyweb>I'm excited that we may have a real world use for this in Guix :)
<civodul>the person would brings bittorrent-style transfer to guix will be considered a hero! :-)
<dustyweb>:)
<Formbi>or maybe IPFS?
<civodul>Formbi: that too would work!
<civodul>we looked at GNUnet's file sharing subsystem in a past GSoC
<roptat>civodul: yes, I implemented enough functions to download blocks from peers
<roptat>I didn't work on it for some time though
<roptat>i'd like to use fibers, but it's not easy to understand how to use it
<roptat>also, there's really no documentation on how to implement the dht, so I rely on trackers for now
<civodul>roptat: sounds like a good start!
<roptat>so... I could use some help: I have a list of trackers and a function that returns peers from a tracker
<roptat>I'd like to have a thread per tracker that would periodically ask for more peers
<roptat>and I already don't know how to do that
<civodul>using Fibers you mean?
<roptat>yes, or any other multithreading library for guile
<civodul>your core is 100% Scheme?
<civodul>*code
<roptat>yes
<civodul>in that case using Fibers should be quite easy
<civodul>that is, at the top-level to do: run-fibers
<civodul>and from there on, you can use spawn-fiber to create a new "fiber", i.e., a concurrent activity
<civodul>calls that block in a fibers will lead that fiber to be unscheduled
<civodul>and that's it
<civodul>there are a couple of gotchas that i'm omitting for brievity ;-), but the guts of it is as i wrote
<roptat>how do I "communicate" between fibers?
<roptat>or with the main thread actually
<civodul>with "channels"
<civodul>you create a channel with 'make-channel'
<civodul>and then you can send/receive messages to/from that channel
<civodul>so it's also a synchronization primitive
<roptat>ok
<roptat>then I also need the main thread to not stop before download is finished, even if there is currently no running fiber. Is that possible?
<roptat>or should I create a fiber for scheduling requests to trackers?
<civodul>sure thing!
<dustyweb>roptat: yes, you could have the fiber wait on a message to know thta the download has finished
<roptat>also, in general the library could continue upload data even when the download is finished, so I guess I need some kind of user interaction or finish policy...
<civodul>roptat: all that said, you could also send a link to what you have on guix-devel or guile-user and try to recruit :-)
<roptat>I'd like to do that by myself
<roptat>but if it's really too complicated, I'll ask :)
<civodul>understood :-)
<roptat>one more question: how do I wait in a way that can be interupted?
<roptat>let's say I want to wait 15 minutes or the end of download
<roptat>if the download ended, I want to exit immediately, but after 15 minutes of waiting, I want to ask more peers to a tracker
<efraim>Or continue peering without taking up a guixbuilder slot or blocking actually building the package
<efraim>Thinking outloud, I wonder how apt-bittorent handles all the packages
<roptat>well at some point it has to stop :)
<roptat>and I don't want to wait 15 minutes after the download
<roptat>by the way, if multiple fibres read from the same channel, do they all receive the message or only one of them do?
<civodul>roptat: you can combine "operations", which is the low-level concept for "something that may block"
<civodul>so you could combine a "sleep" operation with something else
<roptat>so for instance a sleep operation and a receive operation on a channel
<roptat>I think that's all I need to know
<roptat>it's much clearer now, thank you :)
<civodul>yw!
<civodul>dustyweb: BTW, did you see the article about Dat on LWN?
<dustyweb>civodul: I didn't!
<civodul>while reading it, i stumbled upon https://blog.datproject.org/2017/10/12/uc-merced-1/ which might be of interest to rekado
<civodul>dustyweb: https://lwn.net/SubscriberLink/763492/97b518db9309e0f5/
<civodul>too bad it's written in Node :-/
<dustyweb>yeah...
<dustyweb>civodul: btw I found out Secure Scuttlebutt, which is similarly interesting, does the worst form of canonicalization ever on its data
<dustyweb>it just uses the current nodejs default printing of javascript
<dustyweb>er
<dustyweb>of json
<rekado> https://issues.guix.info now supports date filters like mu, and there’s a help page documenting the supported query syntax.
<civodul>dustyweb: ok; it has do to with your work on ActivityStreams, right?
<civodul>rekado: awesome!
<dustyweb>civodul: hm? ActivityStreams doesn't use secure scuttlebutt :)
<dustyweb>though I did consider whether ActivityPub could run over secure scuttlebutt, maybe that's what you mean
<civodul>dustyweb: yes, that's what i meant
<civodul>i knew i had read about Scuttlebutt in the context of ActivityPub discussions or something like that :-)
<rain1> https://gist.github.com/rain-1/a253e47b939fc0769524d8716541c96e i wrote this
<dustyweb>civodul: aha, yeah I looked into it, and found that part troubling :)
<civodul>heheh
<civodul>rain1: what's the intended use?
<rain1>it's to transmit structured data between programs
<civodul>ok
<rain1>without escaping (like json)
<civodul>though you could write those programs in some kind of Scheme and transmit "regular" sexps ;-)
<rain1>that works too! the only thing is strings and binary blobs need to be escaped and unescaped in transmission
<efraim>i'm upgrading python-efl, the tests failed and the check phase succeeded
<ecbrown>i'm trying to get recent change to info docs (e.g. in civodul's recent channels commit) into my emacs info page
<ecbrown>i do guix package -i guix, and then the Guix page appears in my ~/.guix-profile/share/info
<ecbrown>but no new section on Channels in M-x info, and i do zcat guix*gz | grep -iI Channels and nothing appears
<ecbrown>i can, of course, visit the new info file with C-u C-h i
<roptat>ecbrown: probably because the packaged version of guix is older than the channel changes
<roptat>but it should be present in ~/.config/guix/current
<ecbrown>ps i am using the new channels, pinned to a particular git commit
<roptat>it's not recommended to install guix in user profiles btw
<ecbrown>roptat: not sure what that means. i'm just running as "user" on my laptop
<ecbrown>not as root
<ecbrown>i mean it might be something as simple as having to makeinfo
***GrapeNinja is now known as Guest64486
<ecbrown>`guix version' -> 391097782311c82c04b171db7373a0bbfc1d8653
<ecbrown>`guix environment --ad-hoc guix -- guix --version` -> 0.15.0-2.8bbb79c
<rekado>the guix in guix is necessarily older than
<ecbrown>so i guess there is another guix somewhere that
<rekado>older than the installed version of guix
<roptat>ecbrown: when you run guix pull, it installs guix alread in ~/.config/guix/current along with the info pages
*ecbrown has to spend more time learning the Guix model than tinkering with getting hardware going
<ecbrown>i guess i wonder what invocation of guix to use in order to see an emacs with an info page that contains more recent changes than the old guix provides
<ecbrown>(without having to visit it explicitly)
<roptat>export INFOPATH=~/.config/guix/current/share/info
<roptat>orsimilar
<ecbrown>roptat: woop there's channels
<ecbrown>easy enough to take it on in my INFOPATH.
<ecbrown>thank you very much
<ecbrown>i've used emacs for years, and have gotten very frustrated with INFOPATH, I just pray my current distro has it set right to point to the big stack of installed info pages
<j3kyl_>that is why I am fond of distro server versions: "please just dont fck it up"
<ecbrown>yeah, people take it to the extreme though, cf. centos which is so damned old that i can't install packages in R because of it
<ecbrown>*some packages
*ecbrown prepares to dive into the world of geiser/guix
<mbakke>rekado: Have you been able to test core-updates on RHEL6?
*ecbrown adds some things to init.e and visits a hello.scm file populated from example in manual... and M-x run-geiser... my code and a REPL. things are looking up!
<mbakke>I wonder why the scipy tests suddenly started failing.
<rekado>mbakke: thanks for the reminder. I’ll test core-updates today.
<mbakke>rekado: Excellent.
*rekado runs guixr pull --branch=core-updates
<janneke>how do i transform a package for another architecture, iow how do i get --system=i686-linux on guix graph?
<janneke>not like this: ./pre-inst-env guix graph --type=bag -e '(begin (use-modules (guix packages)) (parameterize ((%current-system "i686-linux")) (@@ (gnu packages commencement) gnu-make-boot0)))'
<ecbrown>n00b question -- i'm trying to recreate hello.scm package in geiser, and i have it to the point where i can (package-name hello) and print "hello"
<ecbrown>how do i actually build the package?
<ecbrown>omg C-c . b is building hello!
<civodul>janneke: good question, we could add --system for 'guix graph'
<civodul>in the meantime you can do: guix graph -e '(begin (%current-system "i686-linux") (@@ ...))'
<janneke>civodul: ah, nice!
<dustyweb>yessss
<dustyweb>the magnet + symmetric encryption thing works
<dustyweb>now to document it
<roptat>mh... I can't put a sleep-operation and a get-operation inside a choice-operation because the sleep-operation has no return value
<roptat>(related to fibers)
<roptat>I can put them together as long as I don't try to read the return value, but I need to know which ended the operation
<apteryx>is non-copyleft still a valid license choice?
<apteryx>because the linter complains about it.
<dvn>would love to see the nicest video editor for linux available through guix - https://github.com/jliljebl/flowblade - it's python-based, and looks like the only missing dependency is python-mlt (python bindings for MLT)
<dvn>just dropping that info here in case someone feels interested
<dvn>better link: https://jliljebl.github.io/flowblade/
<pkill9>interesting, i haven't heard of that one
<dvn>i haven't used it in about a year, but it was great -- it's very fast and nice to use. i love that it just uses ffmpeg for most operations, which means it can support all the codecs, etc
<apteryx>adding a "doc" output cause my package to fail because of the added but unsupported configure option: "--docdir"; any idea?
<apteryx>maybe I could modify the configure phase definition on the fly, using the 'code is data' property of Lisp? ^^
<apteryx>sounds hackish but fun
<pkill9>why did that cause it to fail?
<apteryx>pkill9: because the configure phases add a --docdir option when it detects a "doc" output, but this options is not supported by opensp's configure script.
<apteryx>configure: error: unrecognized option: --docdir=/gnu/store/vj7hxddhbb7akk27jjxv81cbwfnlcxhz-opensp-1.5.2-doc/share/doc/opensp
<apteryx>and indeed, ./configure --help in opensp doesn't show such option.
<pkill9>ah ok
<pkill9>is this it?
<pkill9> https://launchpad.net/opensp
<apteryx> https://sourceforge.net/projects/openjade/
***ng01 is now known as ng0
<pkill9>hmm yeah i see
<roptat>ok, I think I got it mostly working :D
<roptat>except that I still can't figure out which operation ended the choice-operation
<rekado>apteryx: non-copyleft is a procedure.
<apteryx>oh, I see. I need to specify at least the URI of the license file in the package's tree.
<apteryx>thanks.
***mattl is now known as Guest25039
***ocharles is now known as Guest39584
<pkill9>can you add a local directory as a guix channel?
<pkill9>hmm, I had to set the branch for the additional channel as 'origin/master'
<janneke>civodul: the guix graph recipe works...but gives slightly other results on x86_64 than on x86...
<janneke>on x86_64 also gcc-bootstrap and glibc-bootstrap are listed... (can't easily see if these are x86_64 or x86)
<civodul>janneke: there must be another binding-time issue such as the one we discussed a few days ago
*civodul posted a neat channel hook: https://issues.guix.info/issue/22629#240
<civodul>s/hook/trick/ even
<civodul>rekado: it'd be oh-so-nice to plug in guile-syntax-highlight in mumi :-)
<janneke>ah...another goof by me, that makes sense, however
<ng0>hm. shouldn't we have 'libffmpeg.so' somewhere? it's not in the out/lib/ of ffmpeg
<janneke>civodul: i just reset wip-bootstrap -- i think we're "done"
<civodul>you found the issue?
<janneke>yes, x86 now bootstraps from mes -- glibc-2.16.0 now builds
<janneke>i made a number of cleanups and expect many more comments/feedback...
<janneke>eh, not the guix graph thing...i'll have a look :-)
<civodul>heh ok :-)
<pkill9>civodul: that is exactly what i want
<janneke>just released mes-0.17.1, how shall i/we proceed?
<civodul>janneke: but so you're saying we're pretty much done?
<janneke>yes!
<civodul>woot!
<janneke>indeed
<civodul>you sent a message, right?
<civodul>i think i'm lagging behind a bit
<janneke>i will
<civodul>ok
<janneke>i didn't send a message just now
<civodul>woow
<ng0>I just saw a slackbuild of Guix. cool
<ng0> https://harrier.slackbuilds.org/pub/slackbuilds.org/14.2/system/
<pkill9>ah, using slack, memories
<pkill9>i went from slack to guix
<pkill9>guixsd
<janneke>ow crap, i make-boot0 doesn't build after last cleanup -- should be minor thing; will fix before sending mail
<ng0>pfl says (for gentoo): media-video/ffmpeg /usr/lib/chromium/libffmpeg.so
<ng0>weird
<mbakke>janneke: Amazing news!
<janneke>mbakke: yeah! thanks -- just fixing up the install phase of glibc-2.16.0 after latest "cleanup"
<janneke>pretty excited
<ng0>found out what caused my error wrt libffmeg.so .. if you want to laugh about proprietary software, search for the problems browsers depending/building from chromium base have/had because of this :D
<vagrantc>janneke: exciting!
<rekado>civodul: good idea about guile-syntax-highlight!
<rekado>I’m almost done with implementing attachment downloads.
<rekado>it’s pretty gnarly because Debbugs SOAP doesn’t give me access to know messages; I need to keep track of the path to the message part containing the attachment…
<rekado>will finish that tomorrow.
*janneke made 3 fixup patches after a whole day of package cleanups...oh well
<civodul>oops
*civodul pushed a patch by mistake