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 <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 <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 <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 <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 <civodul>ng0: let's do it incrementally: you can first submit the plugin-less version, that'd be already useful <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>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. <ng0>because supporting 3 GUIs is hard, their own words. <rekado>okay, just wanted to make sure it wasn’t a typo. <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. <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. <ng0>It was recently announced on the nix-dev mailinglist <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>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 <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 ;) <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) <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. <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. <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 ;) <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. <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 <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. <ng0>maybe my problem is that I use * ^TO_ instead of the list id where possible. <ng0>hm, there's ^FROM_DAEMON ... I'll try that soon <roptat>rekado: do you have a preview of mumi somewhere? <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) <snape>rekado: '/' to search by submitter <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>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. <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 <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: <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 <civodul>(unless you have 'guix' in your profile, which is not a great idea) <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 <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>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. <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 <civodul>rekado: looks like a .ko file name issue <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 *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 *apteryx updated its emacs-elpy package, now with info manual and manpage, #32538 <ecbrown>i'm close to declaring emacs in guix THE emacs distro *rekado updated guix.info <rekado>roptat: it’s still pretty primitive. Does not deal well with multipart messages. <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) <rekado>it caches debbugs requests for a couple of minutes <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 <rekado>civodul: yes, multipart is not done yet :-l/ <rekado>this is the first version that actually uses guile-debbugs instead of mu. <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? <rekado>I’ll upload the code to my server tonight. <rekado>civodul: no. It only caches soap-invoke calls in memory. <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 <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. <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>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. <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 :-) <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>after that we can always rewrite the server side ;-) <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 ;) <mbakke>Agh, I keep getting silently "unregistered" from my IRC bridge. <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>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 :-) <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 <rekado>supporting commits in manifests would be great <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 <jabranham>I missed the channels announcement. Is there an email or blog post somewhere about that? <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'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 <vagrantc>emacsomancer: guix system reconfigure /path/to/config.scm <vagrantc>sudo -E guix system reconfigure /path/to/config.scm <ecbrown>(which of course recompiles your kernel, which is the issue...) <vagrantc>(and requires refreshing many of the keys due to expirations and such) <ng0>sneek: later tell civodul: I'm reallly liking 22629. <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>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>The library actually exists in the .guix-profile/lib/python3.6/site-packages directory which is made known by the PYTHONPATH environment variable. <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>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>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>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? <apteryx>OK, I see. Instead of defining a profile they define a package; makes sense. <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 <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? <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>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>heck of a lot nicer than the default debbugs view :0 <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. <dustyweb>rekado: started with mu then moved to guile-debbugs, eh? :) <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 mentioned it in a debian channel