IRC channel logs

2018-08-28.log

back to list of logs

<rain1>i'm not sure how to build mrustc without also building a lot of other things like boost for example
<rain1>i tried guix environment mrustc and then building with --no-substitutes
<rain1>is there a way to install all the dependencies and build dependencies with substitutes, then build the package itself without?
<OriansJ>vagrantc: thank you. We have been making lots of good progress this year.
<ecbrown>rain1: i have noticed that sometimes the tar.gz suffix is on the thing that needs to be built, though often the dependencies seem to be binary. i.e. i think it does that automagically
<ecbrown>but i could be wrong. just something i noticed
<ecbrown>i wonder why gfortran got left out of gcc 8.20
<vagrantc>if there's a bug that i have a patch for, should i ... mail to the bug with the patch and cc guix-patches? just mail guix-patches? just mail the bug?
<lfam>vagrantc: Send it to the bug
<vagrantc>lfam: thanks
<rain1>is there maybe a different way than guix environment?
<ecbrown>according to the manual: guix build --quiet --keep-going `guix package -A | cut -f1,2 --output-delimiter=@` should build all packages and keep going if failure. however it just stopped on wxmaxima
<ecbrown>i wonder if it has something to do with offload. i will try local execution
<ecbrown>Does Guix have an info page that appears in emacs? I seem to remember browsing it there before, now i don't see it.
<ecbrown>I did install emacs-guix and it shows up there
<ecbrown>oh, i have to guix package -i guix
<ecbrown>^----- this is weird
<emacsomancer>how do I get guix to use/enable the 4.18 kernel? [I tried doing (kernel linux-libre-4.18) in the (operating-system) section of config.scm, but that didn't work]
<ecbrown>emacsomancer: i don't see 4.18 defined in the source code, except for some patches
<ecbrown>guix offload test: guix offload: testing 0 build machines defined in '/usr/local/etc/guix/machines.scm'
<ecbrown>not sure why this is looking in /usr/local/etc rather than /etc for machines.scm
<ecbrown>in fact /usr/local does not exist!
<emacsomancer>ecbrown: it's in the repos though, which confuse(d|s) me
<lfam>emacsomancer: Linux-libre 4.18 is available in Guix since August 13. You need to update your available packages with `guix pull`
<roptat>ecbrown: if you're using a git checkout, add --sysconfdir=/etc to your ./configure arguments
<civodul>Hello Guix!
<ng0>Hi all. Anyone interested to get Audacious into Guix? I have it all packaged, but I need someone with enough time to implement a guix-compatible plugins location (and/or convince upstream to do this).
<ng0>at most it'll require a snippet of C code wrt the "plugin_dir"
<ng0>I'll have more time to look at alternative solutions next month, but if anyone is interested, send me an email
<snape>hi guix
<civodul>hey snape & ng0
<ng0>hi
<civodul>ng0: let's do it incrementally: you can first submit the plugin-less version, that'd be already useful
<ng0>not really
<ng0>unless someone can run audacious without the core plugins.
<civodul>oh but i would think it can at least find its own plugins, no?
<ng0>There's another thing. Guix seems to be very active at weeding out gtk2, right? I've build the upstream supported gtk2 version, not the gui-less version. I plan to do that as well (gui-less), and to package the Qt version. Experimental gtk3 support continues to exists in other OS, but it is experimental. upstream stopped supporting gtk3.
<ng0>now on plugins:
<ng0>the core application and the plugins are 2 different distributions. the core application sets a plugin_dir (which is the $out/lib/audacious of the $out of audacious) and does not easily read other locations. So far I've spent maybe 30 minutes packaging+ package debugging on this, as I need to write a couple of pages for university the next days.
<rekado>stopped supporting gtk *3*?
<ng0>because supporting 3 GUIs is hard, their own words.
<rekado>okay, just wanted to make sure it wasn’t a typo.
<ng0> https://audacious-media-player.org/news/43-audacious-3-10-released
<ng0>"GTK+ 3.x support is also gone for real in this release. A -gtk3 branch still exists in GitHub, but it's not regularly updated. We barely have the resources to maintain support for two different toolkits, let alone three. Use Qt 5 if GTK+ 2.x is too "outdated" (i.e. reliable) for your liking."
<ng0>If you'd prefer qt5, then I'll send qt5 once I have this packaged in my repo..
<ng0>OT: I wonder who translated the free-sw.html article on gnu.org "Die Freiheit, das Programm zu redistribuieren und damit Mitmenschen zu helfen (Freiheit 2)." redistribuieren is so uncommonly used that it almost reads wrong.
<Gamayun>ng0: Yeah... What would you put, just out of interest?
<ng0>"Die Freiheit, das Programm [umzuverteilen / weiter zu verbreiten] und damit Mitmenschen zu helfen (Freiheit 2)." grammar mistakes not included.
<rekado>“weiterzugeben”
<alezost>civodul: hello, do you know any Nix mailing list where I can send announcement for emacs-build-farm ? I am not able to find it :-)
<ng0>I'm reading this page because I'm writing about license models.
<ng0>license models and their implications and effects on users, comparing 3ds studio, Cinema 4D and Blender.
<Gamayun>ng0: Good, my German intuition still sorta works. :)
<ng0>alezost: they switched to an discourse forum recently
<ng0>rekado: weiterzugeben sounds better.
<alezost>ng0: ah, ok, thanks
<ng0> https://discourse.nixos.org/
<ng0>It was recently announced on the nix-dev mailinglist
<alezost>ng0: indeed, thanks; I even see "Mailing list: nix-devel ! deprecated - getting moved to discourse" on https://nixos.wiki/ :-)
<civodul>alezost: yeah it seems that they no longer use email
<alezost>civodul: ok, so I need to send a message only to guix-devel :-)
<civodul>heh :-)
<civodul>i'd like to know how much of a "barrier to entry" email is for younger people
<ng0>well discourse supports email, at least with nixos and elixir
<kmicu>Alas, email is The Great Barrier for young folks.
<civodul>that's my impression, though i don't really understand how it can be
<civodul>ng0: oh nice
<ng0>still I like to have an offline storage of questions and answers, which online forums will not give me.
<civodul>so maybe alezost can email Discourse somehow?
<kmicu>Try using LKMS in Gmail and it’s obvious why ;)
<civodul>you mean reading the LKML?
<kmicu>Reading, tracking bugs, applying patches.
<jonsger>civodul: I would say not using some "modern" tools like Github/Gitlab is more an barrier for younger people (also like me)
<snape>kmicu: what is LKMS?
<civodul>jonsger: that i understand, but for general discussion, i don't get the web UI thing
<Gamayun>I tend to suspect the walls around their walled gardens are the real barrier...
<kmicu>snape: a typo. It should be LKML.
<snape>oh, ok
<civodul>Gamayun: that's for sure, yet, the glimmering of fancy web UIs seems to outweigh that
<kmicu>Glimmering fancy UIs is what youngsters do from the beginning. That’s natural for them.
<jonsger>civodul: ah you talk about discussion plattform. The main problem here is this mailman archive stuff, which let you only ordering after months and not threads
<civodul>jonsger: true, but the "intended use" was that you'd use your favorite email client rather than the web pages
<kmicu>There is also lack of trivial muting functionality for threads.
<civodul>yeah
<jonsger>civodul: yes, but then you only have the mails since you joined the mailing list
<kmicu>Fancy web UI has a button. Now setup the same in your fav MUA.
<civodul>Mailman 4 appears to have a shiny interface, maybe we should use that
<snape>one issue with emails is that there is no good email clients
<civodul>sure they all have shortcomings, but they're not that bad
<civodul>an issue is that many people use the same client: GMail
<snape>I find offlineimap and isync pretty bad
<Gamayun>The good ones do tend to take a lot of configuration.
<snape>I don't understand why they are so buggy and albeit so simple
<kmicu>Not being able to mute a 100-lines long flamwear on emacs-devel is very bad ;)
<civodul>heh
<rekado>I filter by mailing list, so emacs-devel is not right in my inbox.
<rekado>y’all speaking about glimmering and shiny web interfaces… now I feel bad about the bland look of mumi.
<rekado>:)
*rekado fights with CSS
<jonsger>problem for me with mails, is that my provider doesn't have proper filtering, at least in the free version (web.de)
<kmicu>I can use adaptive scoring in Gnus to hide some non-intresting threads on guix-* MLs, but what about other MUAs… recommeding a mail scoring system for newcomers to discuss guix comfortably is no-go.
<jonsger>civodul: is there a preview of this interface?
<Gamayun>I do love gnus. It would be nice though to be able to recommend an easy-shiny client that did the same thing...
<amz3>rekado: you know CSS files are not the modern way to do styles in html, people recommend inline styles instead.
<amz3>rekado: this leads to less fighting.
<amz3>rekado: and more scheme code.
<amz3>in the case where the html in dynamically generated that is, if you do static html then css is I guess still the way to go, but cascading is not a good thing anymore
<rekado>I’m not cascading; just fighting with … centering things.
<civodul>Gamayun: Pierre Neidhardt has been working on improvements to mu4e to make present threads as on those chat apps for mobile phones (maybe it still doesn't qualify as "easy" though)
<amz3>rekado: try 'height: 1vh' for one full vertical height and 'margin: something auto' or just 'margin: auto' for horizontal centering
<amz3>also flexbox is helpful sometime to center stuff without the above hack
<amz3>yeah the first link for flexbox leads me to my favorite page about the subject: https://css-tricks.com/snippets/css/a-guide-to-flexbox/
<civodul>jonsger: here's an instance of Mailman 3 (not 4, sorry): https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/2018/8/
<ng0>some of the problems wiht email also happen outside of email clients, as a social problem. cross-posting while more than one of the targeted lists are on the same server with the same subscribed address for example.
<rekado>amz3: thanks, I’ll give flexbox a try
<snape>ng0: I don't understand. Why is it a problem than more than one of the targeted lists are on the same server?
<ng0>you can not trivially filter with software like procmail.
<ng0>crossposting is bad in the first place, but having to spend time thinking about it is more annoying.
<ng0>not all mailinglists set the X-List or something similar to indicate they originated there
<amz3>sometime it's necessary to cross post
<ng0>you can always write the same message twice.
<rekado>mailman does set the list headers, though, doesn’t it?
<ng0>not by default I think. I had to set it up over at the list I have. other list servers depend on configuration per list as well.
<ng0>procmail simply recommends to work around this by dropping duplicate messages (more or less, man page).. I don't know if this can lead to lose/open threads.
<rekado>I filter all lists by matching on the List-Id header.
<kmicu>Indeed civodul https://hyperkitty.readthedocs.io/en/latest/ is slick.
<ng0>maybe my problem is that I use * ^TO_ instead of the list id where possible.
<ng0>TO and FROM mainly.
<kmicu>[Joking and making slippery slope fallacy] Though it’s Fedora’s project https://lists.fedoraproject.org/archives/ so what next? Systemd‽ 😹
<ng0>hm, there's ^FROM_DAEMON ... I'll try that soon
<roptat>rekado: do you have a preview of mumi somewhere?
<rekado>roptat: not yet
<rekado>I could put it on berlin today
<rekado>but I’m not really happy with it.
<rekado>Debbugs has some serious limitations.
<rekado>it does not let me search by bug status, for example.
<rekado>also searching by submitter does not work
<rekado>(searching by message author does work, though)
<roptat>ok, too bad
<snape>rekado: '/' to search by submitter
<rekado>?
<snape>within emacs
<rekado>snape: I mean the Debbugs SOAP service
<rekado>Emacs does this by fetching all results and then filtering them locally
<rekado>for the web interface that’s not great, because fetching the bug status is expensive.
<snape>I see
<snape>rekado: btw, I updated the Cuirass package. If you want you can update Berlin, you'll have the new database system, and evaluations displayed earlier.
<rekado>snape: thanks, will do today
<civodul>rekado: lemme know if you'd like me to reconfigure berlin or anything, while you get Mumi ready :-)
<ecbrown>meh is gmane submission to guix.user down just for me?
<rain1>i was wondering how to build mrustc, but not build its deps?
<rain1>on guixs, i tried git clone guix and ./pre-inst-env the guix environment mrustc and then various guix build attempts
<rain1>but i can either install a substitute binary of mrustc, or end up building loads of its dependencies like boost (which i don't want to do)
<ecbrown>well it sounds like you want your cake and eat it too
<ecbrown>do you want mrustc or not?
<ecbrown>(just saying ;-)
<civodul>rain1: one thing you could do is "guix build mrustc" (which downloads a substitute) followed by "guix build mrustc --no-grafts --check -K"
<ecbrown>i am curious whether order of PATH matters: ~/.guix-profile/bin:~/.config/guix/current/bin:
<ecbrown>or should current come first?
<apteryx>do I still have to bother returning #t in phases?
<civodul>ecbrown: current should be first, but that shouldn't make much of a difference
<ecbrown>ok, thank you!!!
<civodul>(unless you have 'guix' in your profile, which is not a great idea)
<ecbrown>i do in fact
<civodul>apteryx: yeah
<ecbrown>as in guix package -i guix
<apteryx>civodul: ok, thanks
<civodul>apteryx: "soon it will be all over", as the song says ;-)
<ecbrown>that because i want guix info pages in emacs, this was the way i found to do it
<apteryx>eh eh
<civodul>"well i hope soon"
<civodul>:-)
<rain1>thanks civodul, that helped a lot!
<rain1>this seems to be building mrustc now
<ecbrown>i have a guixsd machine, referencing a strange file: guix offload: testing 0 build machines defined in '/usr/local/etc/guix/machines.scm'.
<ecbrown>guix offload test
<ecbrown>of course /etc/guix/machines.scm is the one referenced in the manual, and it is present
<ecbrown>but as root it goes to /etc/machines.scm and succeeds
<civodul>are you running a manually-built guix or something?
<ecbrown>i'm really not sure at this point, i have ./pre-inst-env'd before, but since i've just been doing guix pull for root and user.
<ecbrown>that's sort of why i was curious about my path order.
<apteryx>ecbrown: I had that problem.
<ecbrown>any solution to it? i'm running guix pull without hooks for good measure
<apteryx>I think I posted the solution in a bug report, wait
<apteryx>mine was slightly different but maybe related: bugs.gnu.org/31825
<apteryx>it was the authentication which was giving me gripes, spicing things up with misleading error messages ;)
<ecbrown>ok, so cp the stuff from /usr/local into /etc/guix.
<ecbrown>i guess i have to redistrib my .pub file
<rekado>cannot reconfigure berlin: builder for `/gnu/store/msxjp2pbd6vnr9q86xg1d5znf7hwifib-linux-modules' failed
<apteryx>my guix was adding my authorization key to /usr/local/etc/guix/acl for some reason.
<civodul>ecbrown: i think that if you run a 'guix pull'-provided 'guix' command, and if you're on GuixSD or using the binary tarball, that's gonna be fine
<ecbrown>apteryx: i don't have a /usr/local
<civodul>rekado: looks like a .ko file name issue
<ecbrown>civodul: let me try
<rekado>apteryx: this happens when you use a Guix from a git checkout that has been configured without --sysconfdir
<apteryx>rekado: does it self cure after doing a 'guix pull'?
<apteryx>I haven't seem to have the issue since
<ecbrown>civodul: i did guix pull --no-build-hook && guix package --no-build-hook -u
<rekado>civodul: looks like the “shpchp” module is required but not found
<ecbrown>then tried with that guix offload test, and it's the same
<rekado>civodul: I’ll remove it.
*ecbrown reported a problem with missing, but required shpchp missing in 4.18
<rekado>I’ll switch to the LTS kernel for now
<ecbrown>civodul: and you seem to be right that ~/.guix-profile/bin/guix offload test works
<rekado>snape: reconfigured berlin. The latest version of Cuirass is now available.
<ecbrown>it is version: guix (GNU Guix) 0.15.0-2.8bbb79c
<ecbrown>guix offload test that is problematic is guix (GNU Guix) 6772ed1e07d6b8ce557199d91aaa1442c77186c7
<civodul>rekado: woohoo thanks!
*apteryx updated its emacs-elpy package, now with info manual and manpage, #32538
<ecbrown>nice
<ecbrown>i'm close to declaring emacs in guix THE emacs distro
<ecbrown>(unofficially, of course)
<civodul>:-)
*rekado updated guix.info
<civodul>mbakke: you around?
<rekado>roptat: http://issues.guix.info
<rekado>roptat: it’s still pretty primitive. Does not deal well with multipart messages.
<civodul>rekado: you rock!
<civodul> http://issues.guix.info/issue/18689 looks nice
<rekado>ultimately, I want to have a comment field through which people can send email to debbugs.
<civodul>that'd be nice, but even without it it's already a great improvement
<rekado>the search supports a bit of extra syntax like “author:rekado is:open”, which shows all open issues where “rekado” is involved (“author” means message author)
<civodul>i think we need colored boxes for the status at http://issues.guix.info/search?query=guile
<civodul>neat!
<rekado>yes, will add that
<rekado>it caches debbugs requests for a couple of minutes
<ecbrown>this is fantastic
<rekado>fresh queries are quite slow, unfortunately.
<rekado>so I think in the future this should be done asynchronously
<jonsger>rekado: amazing. It's already a big improvement against the stock gui of debbugs
<civodul>rekado: looks like multipart messages are not decoded: http://issues.guix.info/issue/32456
<apteryx>rekado: slick!
<rekado>civodul: yes, multipart is not done yet :-l/
<rekado>this is the first version that actually uses guile-debbugs instead of mu.
<civodul>not a showstopper anyway!
<rekado>with mu I didn’t have to deal with multipart messages at all.
<civodul>rekado: you said there's some caching, does it emit "Cache-Control" headers accordingly?
<ecbrown>works in emacs-w3m (TM)
<rekado>I’ll upload the code to my server tonight.
<rekado>civodul: no. It only caches soap-invoke calls in memory.
<civodul>ok
<rekado>there’s a simple wrapper soap-invoke* that looks up the arguments in a hash table and checks if the value is still fresh.
<civodul>for issues/NNN corresponding to archived bugs, i guess it could unconditionally add Cache-Control with a max-age of 12 hours, say
<rekado>good idea
<rekado>some things like pretty horrible: http://issues.guix.info/issue/24550
<civodul>well that's because it's multipart
<rekado>right
<civodul>multipart messages are not so common apparently in the archive
<rekado>I’ve started to move message handling to mailutils, but message headers and body are still processed “manually” in guile-debbugs.
<civodul>maybe http://issues.guix.info/ could list the last 5 entries
<civodul>below the search box
<rekado>had the same idea, but I ran into a bug at that point.
<rekado>I used the “newest_bugs” operation, which timed out.
<rekado>since that operation cannot be restricted to the “guix” or “guix-patches” packages I’ll just use a date-limited search instead.
<civodul>oh, that's because the Debbugs server is too slow?
<rekado>maybe
<rekado>newest_bugs just returns bug numbers; I have to fetch more info with the bug numbers as arguments.
<rekado>that second operation just never returned.
<rekado>don’t know why.
<civodul>with a bit of guile-git hackery, we can then add links like "commit X referenced this issue"
<civodul>as seen on newfangled hosting platforms :-)
<rekado>that would be neat
<civodul>i think this has the potential to allow us to recruit a bit more beyond the typical "old-style" hacker groups
<rekado>I hope so. I’m a little worried about Debbugs limitations, but we’ll see how that goes.
<civodul>yeah
<civodul>after that we can always rewrite the server side ;-)
<rekado>heh :)
<civodul>then you found GitBugs, Inc., absorb GitLab users when there's a scandal, follow the same walled-garden approach, and become a millionaire
<rekado>you really shouldn’t have disclosed my ultimate plan here ;)
<civodul>oops :-)
<jonsger>I would call it GitBucks :P
<mbakke>Agh, I keep getting silently "unregistered" from my IRC bridge.
<mbakke>civodul: What's up?
<civodul>mbakke: you remember the story with having guix.gnu.org point to two different machines?
<civodul>would you know how to deal with x509 certs in this context?
<mbakke>civodul: Both machines can request the certificate (and renewal) from Lets Encrypt. There's a 50% chance it will succeed, every time :P
<mbakke>I think the Lets Encrypt DNS challenge could be more deterministic.
<rain1> https://bpaste.net/show/7609a6debd84 i have followed https://www.gnu.org/software/guix/manual/en/guix.html#Building-from-Git and sucessfully built mrust inside pre-inst-env .. but i made a small change to the package definition and now it fails to build. i don't understand the error though what should i do?
<rain1>guix build: error: build failed: some outputs of `/gnu/store/...-mrustc-0.8.0.drv' are not valid, so checking is not possible
<rekado>rain1: try again without “–check”
<rekado>you can only check when you’ve already built something at least once.
<rekado>if you want to build more than once you can also use “--rounds=2”
<civodul>mbakke: right, that's the problem :-)
<civodul>i mean, can it be made to work?
<rain1>thank you!
<rekado>civodul, mbakke: is this only a problem during renewal? Not during regular operation?
<mbakke>rekado: It's also a problem for getting the initial certificates. But with enough tries it should succeed...
<mbakke>The renewal triggers a few weeks (three?) before expiry, so you'd need to lose 21 coin flips in a row.
<mbakke>Another possibility is mirroring the certs from one machine, but it's somewhat more complicated (especially for GuixSD).
<rekado>wasn’t the DNS challenge exactly made for DNS round-robin setups?
<mbakke>rekado: Probably. It does require a DNS provider with an API, or running your own NS (which we intend to do as well).
<civodul>mbakke: so how can we address that concretely? :-)
*civodul is a bit clueless
<civodul>i mean we *could* lose 21 coin flips in a row
<civodul>in other news: http://issues.guix.info/issue/22629 (scroll to the bottom!)
<rekado>woo!
<apteryx>civodul: exciting!
<rekado> http://issues.guix.info/issue/22629#119
<rekado>(no need to scroll then)
<rekado>supporting commits in manifests would be great
<rekado>really exciting
<civodul>yep
<civodul>oh i hadn't noticed the anchors, cool!
<mbakke>Woow. Channels, a nice debbugs interface, and soon shepherd can reload services. Is it Christmas already? :-)
<jonsger>mbakke: just 158 until next FOSDEM :P
<jonsger>+days
<jabranham>I missed the channels announcement. Is there an email or blog post somewhere about that?
<rekado>jabranham: there’s a patch: http://issues.guix.info/issue/22629#119
<jabranham>rekado: oh, nice!
<bavier`>hello guix
<rain1>hi
<snape>rekado: re Berlin upgrade: cool, thanks!
<emacsomancer>lfam: how do i get guix too actually *use* 4.18 though? When i reboot it's still using 4.17
<ecbrown>i'm having a certificate issue with guix-provided R. when I try to install.package, I get "URL 'https://cran.r-project.org/CRAN_mirrors.csv': status was 'Peer certificate cannot be authenticated with given CA certificates'"
<ecbrown>i've tried to guix package -i nss-certs openssl gnutls
<ecbrown>(and set the environment variables that were suggested)
<ecbrown>i am suspecting that some other certificates need to be loaded to do ssl, such as w3m also needing openssl
<mbakke>emacsomancer: 4.18 is the default kernel, you should not have to do anything.
<mbakke>If you ran `guix pull` in the last few weeks.
<emacsomancer>I have done `guix pull` and `guix package -u` but when I boot I still get the 4.17 kernel
<vagrantc>emacsomancer: you need to update your system, guix package -u only updates the user's profile
<emacsomancer>I have done with `sudo` as well
<vagrantc>emacsomancer: guix system reconfigure /path/to/config.scm
<emacsomancer>ok I'll try that
<vagrantc>sudo -E guix system reconfigure /path/to/config.scm
<ecbrown>(which of course recompiles your kernel, which is the issue...)
<vagrantc> https://savannah.gnu.org/project/memberlist-gpgkeys.php?group=guix&download=1 doesn't appear to include all the keys used to sign the guix repository
<vagrantc>(and requires refreshing many of the keys due to expirations and such)
<ng0>sneek: later tell civodul: I'm reallly liking 22629.
<sneek>Got it.
<apteryx>Hello, how do I install Python2 with guix? There doesn't seem to be a python2-wrapper
<samplet>rekado: FYI, now that we have GHC 8.4.3, I’ve started working on the whole LTS Haskell 12.7 update.
<apteryx>ok, got it: python2
<apteryx>the python-wrapper package is only so that "python" can be used in place of "python3"
<ecbrown>(answer to my previous question about R and SSL error: guix package -i curl and place CURL_CA_BUNDLE=<whatever> in ~/.Renviron hopefully this message will be found by search)
<apteryx>how does propagated-inputs work in python?
<apteryx>I installed python-jedi (fixed with this patch to pull the runtime dependency python-parso): https://debbugs.gnu.org/cgi/bugreport.cgi?bug=32538, but I don't see python-parso appear in my profile (guix package -I)
<apteryx>Ah, it's just a presentation thing.
<apteryx>The library actually exists in the .guix-profile/lib/python3.6/site-packages directory which is made known by the PYTHONPATH environment variable.
<efraim>vagrantc: I have a WIP package for a guix keyring https://gitlab.com/Efraim/guix-keyring
<vagrantc>efraim: oh, cool
<efraim>No integration with guix yet though
<vagrantc>efraim: i was going to comment on #22883 documenting my hackish shell script that i've just started using
<vagrantc>basically just checks all the versions from the currently running guix to master and picks the most recent commit that verifies
<vagrantc>FSVO verify
<vagrantc>although "git verify-commit" doesn't appear to have a way to pass arguments such as --no-default-keyring --keyring ... so you have to set GNUPGHOME= and point it at a directory with the keys imported
<lfam>`git verify-commit` also doesn't distinguish between bad signatures and good signatures made with expired keys :/
<lfam>It's sort of a half-done as far as "code signing" goes
<vagrantc>sure
<vagrantc>i basically assume a curated keyring, and if it's in the keyring, and it's a valid signature, it's a valid commit ...
<vagrantc>and since i'm only really checking against recent commits, i treat expired signatures as invalid ... and worst case it falls back to the next valid commit
<vagrantc>it's by no means perfect, just provides a slight bit more confidence than blindly trusting "git pull" :)
<vagrantc>fwiw, my little guix pull wrapper that verifies the commits: https://paste.debian.net/1039709/
<vagrantc>it's pretty basic and doesn't handle a lot of corner cases, but does the job
<apteryx>any example of a project providing a guix manifest for the dependencies?
<bavier`>apteryx: I believe haunt does
<lfam>apteryx: https://git.dthompson.us/guile-sdl2.git/blob/HEAD:/guix.scm
<apteryx>OK, I see. Instead of defining a profile they define a package; makes sense.
<apteryx>Can I have a no source and no build system for my package? I'm looking at this https://git.dthompson.us/guile-sdl2.git/blob_plain/HEAD:/guix.scm for the sole purpose of providing an environment (for now) in a project that doesn't even have a proper mean to be built (it's just sources)
<efraim>I think you can have (source #f)
<efraim>And trivial-build-system really does nothing
<CcxWrk>I'm getting sha256 mismatch on first guix pull, download of /gnu/store/bjpalrv9f49d2k40p7ga0y6dwdys9w5j-bzip2-1.0.6.tar.gz
<CcxWrk>Is that a known problem?
<mbakke>CcxWrk: The bzip.org domain was recently allowed to expire. If you enable substitutes you can download a prebuilt bzip2 (and the source if you need it) from Hydra instead.
<mbakke>On current Guix the URL has been updated to a working one, but it doesn't help those coming from 0.15 :/
<novaskell>Would it be possible to send a patch for Idris 1.0 -> 1.3.0 and GHC 8.0.2 -> 8.4.2 or is it currently better to wait and keep them as local changes?
<apteryx>efraim: right, thanks
<novaskell>I'm asking as the previous attempt at updating to Idris 1.2.0 ended with following constraints placed by haskell.scm (specifically what woule be binary-0.8.3.0 where Idris requires binary-0.8.4.1 which forces a GHC update or ignoring the GHC bundled version)
<rekado>novaskell: I have an update for GHC 8.4.3 in the works.
<novaskell>glad to hear
<novaskell>rekado: How does it look currently / is there anything I could to to help with it
<rekado>novaskell: I think it’s almost done. Still building :)
<rekado>I hope that I can push it tomorrow.
<novaskell>I'll see if I can follow with Idris 1.3.0 shortly after you do
<rekado>to prevent disrupting all haskell users I wanted to first wait for the new GHC to be built by the build farm, and only then update the default GHC.
<kmicu>That sounds great. Thank you rekado.
<dustyweb>whoa
<dustyweb>issues.guix.info ???
<dustyweb>where did this come from
<dustyweb> http://issues.guix.info/issue/22629#119 this is a gorgeous view
<taylan>wow, that looks neat
<dustyweb>heck of a lot nicer than the default debbugs view :0
<dustyweb>:)
<dustyweb>rekado: is this your doing? :)
<rekado>it is.
<rekado>glad you like it
<dustyweb>stellar work
<rekado>there are a couple of bugs that I’ll fix in the coming days.
<rekado>this was really just supposed to be a quick demo.
<rekado>You can get the code to mumi here: https://git.elephly.net/software/mumi.git
<dustyweb>cool
<dustyweb>rekado: started with mu then moved to guile-debbugs, eh? :)
<dustyweb>are you still caching it somewhere?
<rekado>I’m caching SOAP requests, but in a very primitive manner.
<rekado>I suppose I could have a worker that refreshes bugs in the background.
<rekado>currently, it’s really just a web interface to the SOAP service. That’s why it’s much slower than the version that used mu.
<rekado>guile-debbugs provides soap-invoke and soap-invoke*, which stores arguments and results in a hash table.
<rekado>mumi uses soap-invoke* for all requests, so repeated requests (within four minutes or so) are read from the hash table.
<vagrantc>rekado: very cool!
*vagrantc mentioned it in a debian channel