***Apteryx_ is now known as Apteryx
<Apteryx>It looks like the bayfront DNS is still having some problems. <civodul>Apteryx: it's not the DNS, it's been down for unknown reasons for a day or so <Apteryx>Could anyone recommend an easy to verify if a particular substitute is available on a substitute-url? <baconicsynergy>Now that GuixSD is effectively kernel agnostic, it got me thinking... <baconicsynergy>What if we were able to port the genode operating system framework to guixsd? What if allcomponenets including microkernel and essential userland components such as network stack, netbsd rump kernel, vfs, noux, etc were described as guile modules? <baconicsynergy>It's a joy to build genode systems but it's all manually constructed with the help of some build scripts at the moment. What if we were able to declare custom system configurations in a static high level abstraction like guixsd already does? <atw>baconicsynergy: pretty cool! Possible difficulties: non-free components, and that's a _lot_ of porting, right? <atw>btw, I think the channel is more trafficed during European daytime <baconicsynergy>atw: Yes it would be a lot of porting! It would definitely be a lot of work, but the benefits of a capability-based framework like Genode and it's microkernel-agnostic architechture are extremely important for software freedom. The good news: Almost all of the genode framework is licensed under the GPLv2! During the porting process, it would be our responsibility to curate what extraneous licensed <baconicsynergy>I also feel that the free software should really start taking the seL4 microkernel (gplv2) extremely seriously. <atw>cool! I haven't gotten to see Manolis' talk from this year's FOSDEM yet, but I think that among the difficulties of porting/packaging hurd was glibc adjustments. Is GuixSD really kernel agnostic yet? Ideally, it should be, but I don't think we're there yet. Anyway, looking forward to Manolis' talk as I'd really like to use GuixSD to try out hurd. <baconicsynergy>sneek: later tell atw I've been waiting for so long to run the hurd on guixsd, I'm super excited! <efraim>hmm, make-boot0 on aarch64 can't find falloc.h, which should be in glibc or linux-kernel-headers ***jonsger1 is now known as jonsger
<jmd>How can I get "make check" to be more verbose? (so that I can diagnose failing tests)? and how can I get it to run a single test rather than the entire suite? <mthl>jmd: you guix test suite or a specific package you are building? <jmd>I mean when building guix <jmd>Or rather when testing it. <mthl>you can 'make check V=1' for more detailed output of the test suite <mthl>you can 'make check TESTS="tests/foo.scm tests/bar.scm"' <mthl>for running specific tests <jmd>V=1 doesn't make it any more verbose. <jmd>Ahh it says See ./test-suite.log <mthl>jmd: your are right, I was confuse. <ng0>the issue with the locale I have is weird. <clacke[m]>I always get locale issues with guix. I think I have GUIXLOCPATH, LANG and LC* set appropriately for both the guix-daemon process and the guix process calling it, but I still get that warning message every time ... so obviously I think wrong. :-) <ng0>i don't have a locale issue like that <ng0>I just can't build from configs which used to work <adfeno>... can you by chance tell us the output of `env` command? <ng0>what I mean is bug #25691 <clacke[m]>the guix build container should clear things like that, right? <adfeno>.... Or, clacke[m] Better yet: did you put the variables in ".profile" file, or was it in some other file? <clacke[m]>I have an s6 script setting the vars and running guix-daemon <clacke[m]>A process supervisor, similar to runit or djb daemontools. <adfeno>Have you made sure that the directory is "~/.guix-profile"? (Not "~/.guix_profile" or "~/.guixprofile" or some other variation) <clacke[m]>anyway, I'm not asking anyone to assist me in troubleshooting it, it's difficult to do over IRC and I'll get around to it. :-) <ng0>so I even tried to leave out the (locale) (ie: delete it), still no change <clacke[m]>yeah, it's probably some spelling issue somewhere that I've overlooked <clacke[m]>ng0's problem seems more serious, don't let me interrupt <ng0>no, it's just annoying <ng0>if I can't get to fix it, I will send one of my configs <adfeno>I have found out that the user has to set these variables in ".profile", not in ".${shell_name_here}"{rc,_profile} <ng0>mithlond has by comparison the most untouched config. I only would need to change the harddrives part. <jmd>These errors are wierd. It used to work. I shall have to try "git bisect". <adfeno>Let's see if I can give my newbie input. <ng0>exchange "en_US" with any ISO language available.. i tried some now, none of them succeeded <ng0>all give "no such file or directory" <ng0>I doubt that my git checkout is damaged or has some accidental merge from a local branch, master is kept in sync with master upstream <adfeno>I wonder if the source files for the locales have indeed en_US available. <ng0>but last week they stopped working for me <adfeno>Perhaps it has en_US.utf8, en.UTF-8, en.utf8 <ng0>like I wrote in the last message, it is "en_US.UTF-8" which is also the default <adfeno>Which language package is being installed? <ng0>it fails before it starts <ng0>every package before that succeeds <ng0>found the verbosity switch. maybe that gives more info <adfeno>I wonder which definition or procedure provides "locale-2.22.drv". <ng0>it is locale-2.23.drv though <adfeno>OK, either `gnu system` or `gnu system locale` modules seem to be defining the locale source files (at least). <ng0>and no matter which verbosity I select, it doesn't help <adfeno>Now I wonder if they also are responsible for building the derivations. <adfeno>The default for operating-system-locale is "en_US.utf8". <ng0>no, en_US.UTF-8 .. or is the documentation wrong now? <ng0>I only read an old commit <ng0>but leaving it out, not providing it, therefore getting the default, gives the same werror <adfeno>I'll check my glibc-locales package to see if it has "en_US.UTF-8". <ng0>with en_US.uft8 it's the same mistake, because the locale builder guesesses and the extension is .UTF-8 <ng0>I'll be away for some minutes and then I will send the system config to the bug ticket <adfeno>"Whooooooooot?!", my version of the "glibc-locales" package (2.24) provides "en_US" and "en_US.UTF-8", but not "en_US.utf8".... <ng0>mkay. when I remove the glibc line, it works I think at least it pauses for a longer time now <ng0>so (locale-libcs (list (glibc-2.23 (canonical-package glibc))) was the issue <adfeno>So, you removed it from what exactly? <ng0>i commented it in the system config <ng0>now the system builds again <adfeno>Oh OK, it's your own system config then. <adfeno>Well, glad I could provide some sparkle of enlightment. :D <janneke>i keep getting encoding errors like: ice-9/boot-9.scm:109:20: Throw to key `encoding-error' with args `("scm_to_stringn" "cannot convert narrow string to output locale" 1073741930 #f #f)'. <janneke> 827: 10 [patch-/usr/bin/file "./gettext-runtime/configure" #:file-command ...] <janneke>i have seen these before...what is the right way to handle this again <janneke>ACTION has patched perl's `Configure' to remove one utf-8 quote...but hmm <civodul>janneke: some of these files are not utf-8-encoded, so you need (with-fluids ((%default-port-encoding ...)) ...) ***jonsger1 is now known as jonsger
<janneke>the last message i see is patch-file/... <janneke>and i was thinking/guessing from the stacktrace this was happening in substitute* <janneke>which already does that...i probably didn't look exactly right <paroneayea>civodul: have you tried M-x gnu-patches with the new guix patches debbugs instance? <paroneayea>it won't let me enter the space for what I think is the name...? <paroneayea>(add-to-list 'debbugs-gnu-all-packages "guix-patches") <civodul>paroneayea: right, i just did that too :-) <paroneayea>I'll send an email about that to guix-devel in case others would find it useful ***jonsger1 is now known as jonsger
<efraim>Anyone know of an ncurses interface to debbugs? <efraim>Actually now it might be time again to see if some substitute* magic can make reportbug and reportbug-ng work for us ***Piece_Maker is now known as Acou_Bass
<paroneayea>civodul: so, do you think we should have some tags / control things for "needs review" or "reviewed" or "ready for commit"? <paroneayea>civodul: it's prety early, but I'm hoping the new debbugs list will help with triaging. ***jonsger1 is now known as jonsger
<civodul>paroneayea: good question, i don't know <civodul>i never understood how custom tags are supposed to work <civodul>they seem to be attached to a single user (email address) <civodul>Alex Vong talked about it some time ago ***Piece_Maker is now known as Acou_Bass
***Piece_Maker is now known as Acou_Bass
<rekado_>civodul: you can add me as a list admin. It’s just about weeding out spam, isn’t it? <rekado_>does anyone know how I can use mu4e with the Emacs debbugs interface? <rekado_>when replying to a message in the debbugs overview it uses gnus by default, which is almost (but not quite) what I need. <rekado_>(I just composed a review to paroneayea’s patch, then copied that to a new mu4e buffer and sent it from there, which is a bit awkward.) <adfeno>mu4e is the reader of the message? <adfeno>(It's the first time I'm hearing about mu4e) <rekado_>it uses message-mode like gnus does. <rekado_>maybe I can write a simple adapter command <adfeno>So you want to reply to the message using what exactly? This is not a harsh-language question. <rekado_>when you use M-x debbugs-gnu-patches (or similar) and you enter a bug report what you see is a gnus list of messages. <rekado_>when you hit “r” or “R” on any of these messages you can reply to them. <rekado_>this opens a buffer in message-mode which is tied to gnus. <rekado_>instead I’d like to use mu4e-compose-reply <rekado_>which also uses message-mode, but gives me the usual mu4e bindings <bavier``>ergh, I'm trying to enable tests for our netsurf package, but some of the tests suffer from the Y2038 problem <bavier``>I wonder if I should just disable those test cases for now ***jonsger1 is now known as jonsger
<civodul>rekado_: i've added you and sent you the admin password <civodul>it's really just about tweaking parameters etc. <Apteryx>Looks like Bayfront is up and running again :) <Apteryx>Thanks to whoever fixed it. Is it running on GuixSD? <adfeno>rekado_: It seems that the usage of message-mode is hardcoded in gnus. <adfeno>Apparently, one just needs to change the mail-user-agent variable <adfeno>rekado_: (setq mail-user-agent 'mu4e-user-agent) ***jonsger1 is now known as jonsger
<Apteryx>jmd: Bayfront? Not sure, but it was down for a day or two. ***slyfox_ is now known as slyfox
<rekado_>adfeno: maybe I’m doing something wrong, but setting the mail-user-agent doesn’t help <rekado_>debbugs-gnu.el has a variable “debbugs-gnu-mail-backend”, but it’s only for switching between rmail and gnus. <rekado_>maybe the addition of debbugs-read-emacs-bug-with-mu4e would be welcome upstream. <adfeno>rekado_: Or in your case: reply/send to debbugs with mu4e. <adfeno>I'm not that experienced with Elisp, nor programming. In fact, my attempt to aid you was merely my parallel attempt to find possible fixes. <adfeno>It's not something I know how to fix from proper experience. <adfeno>Perhaps you can do smething like this: <adfeno>Get the gnus manual that says which procedure is called when pressing r or R or whichever reply-or-compose-like-key. <adfeno>These should be somewhat customizable by you some how in your .emacs file. <adfeno>Perhaps you could also force then to be so, like: define a *general* default message writter (I didn't say for debbugs usage only), then redefine the message compositing commands so that they can ask you which writter to use. <adfeno>Although one must note that this is just an idea, as I don't know if all the writters accept the same arguments and options in the same order and such. <rekado_>adfeno: no need to look up anything in the manual. “C-h k r” shows me the command that’s executed. But that’s not helping. <rekado_>to reply with mu4e I need to get a couple of bits of information from the currently selected bug and pre-fill a few fields in the reply for mu4e. <rekado_>it’s not hard, I just wanted to know if anyone else does that <root_guix>Can I install software from source code into Guix? <atw>root_guix: I've not done it, but you should be able to write a package definition and then do a guix package --install-from-file <sneek>atw, baconicsynergy says: I've been waiting for so long to run the hurd on guixsd, I'm super excited! <atw>baconicsynergy: me too! <root_guix>Can I install Hurd on any GNU/Linux distribution? <janneke>root_guix: there is debian/hurd and arch/hurd <cantstanya>why would you think that's feasible? look at the output of `file /path/to/any/binary`. You can't just have a different kernel and expect to magically work with userspace binaries built for another kernel. <civodul>i wonder if we should work around the problem in Guile rather than libc <janneke>civodul: yes, that's what i asked phant0mas <janneke>ACTION has been trying all weekend to build `hello' on hurd and provide full recipe <efraim>My aarch64 bootstrap ATM cant find falloc.h at make-boot0 <efraim>Apparently its in the kernel headers <civodul>never seen this file name before :-) <janneke>as a start, i've cross-built the bootstrap binaries for hurd <adfeno>↑ root_guix this might be helpful. <methalo>guile-2.0.13 FAILED again after apply new patch