<jmi2k>ng0: statically-linked strace would do the job for you? <ng0>I'll try to adress mirror.hydra.gnu.org first.. I mean until yesterday all worked well with bayfornt in there etc <Gamayun>ng0: What did the tor trademark people have to say? <ng0>more or less what I said <ng0>depends on the modifications done, I should get in touch with tor-dev@tp.o <ng0>jmi2k: ha! I did a guix pull on my other test machine in the network, and this time I got a strace <ng0>last message: no binding 'bytevector->string' to hide in module (rnrs io ports) <ng0>I can try to paste the whole output <ng0>I might see an issue at the first machine... restarting the time service <ng0>how does not displayed grafting look like in strace? <ng0>there is some directory open when it hangs <ng0>no, it's a .drv file, the one of guile-2.0.13 <ng0>I get the same error like in the paste I uploaded, on a different computer <ng0>this is stupid. really... I'll just completely switch over to git everything. <mekeor>wouldn't it be nice if %modify-phases had supported something like “#:patch (modify-phases %standard-phases (only 'patch-source-shebangs 'build))“ ? – or is there an already existing, nice alternative to specify just two specific phases out of e.g. the gnu-build-system's %standard-phases? <mekeor>(“only” would be a new so called MOD-SPEC for modify-phases) <mekeor>or is there some scheme foo so that i can delete all phases except two specific ones using the “delete” MOD-SPEC <mekeor>can i create a package-name.scm for a package for my own, custom project? i'm asking because (source (local-file "." #:recursive? #t)) doesn't work. the “"."” part doesn't work specifically. <rekado>commit 7447aa36e16fb77f75df4d3369db9c942615632e broke compilation for me <rekado>ERROR: no binding `bytevector->string' to hide in module (rnrs io ports) <rekado>(attempting “autoreconf, ./configure, make clean-go, make” now) <rekado>sneek: later tell civodul commit 7447aa36e16fb77f75df4d3369db9c942615632e breaks compilation: “no binding `bytevector->string' to hide in module (rnrs io ports)” <efraim>Subversion takes forever to run the test suite on aarch64 <lfam>efraim: It takes forever on every architecture. It's really annoying! <sneek>Welcome back lfam, you have 1 message. <sneek>lfam, ng0 says: how long did the texlive bug/grafting thing take on your end? my 'guix pull' did not finish within 12 hours, gave it 3 tries after the first 12 hours <lfam>ng0: It took maybe 10 minutes for me. I wonder what's happening that takes 12 hours? <efraim>i haven't tried texlive yet on the aarch64 board, i need to hook up an external harddrive first <lfam>I think I broke the syslogd service; testing now <sneek>Welcome back civodul, you have 1 message. <sneek>civodul, rekado says: commit 7447aa36e16fb77f75df4d3369db9c942615632e breaks compilation: “no binding `bytevector->string' to hide in module (rnrs io ports)” <jmd>We should bring in a rule: He who breaks the build buys the rest of the team a pint! <jmd>s/He/The person/ - to be politically correct .... <efraim>I'll defer to your Brittishness on who/whom <rekado>s/politically correct/inclusive/ <jmd>Whom would be used in the dative case, which my sentance was not. <jmd>"Who did that?" vs. "To whom does this belong?". <efraim>sneek: later tell ng0 is there documentation somewhere about using guix-packaged plugins in vimrc? I'd consider switching <efraim>almost 10 years since I stopped living full time in the US, words and grammar get harder every year <jmd>Well the who/whom thing most native speakers get wrong. But this is an area where knowing German helps. <efraim>I think I'm going to make a commit locally on core-updates to tag '0.12-4.1' or something similar so I can create a binary install tarball for aarch64 <slyfox>it's a result of 'guix build --target=alpha-unknown-linux-gnu qemu'. I didn't expect it to finish and wondered where it will break. but i fail to understand what exactly failed <roelj>What's the variable between "incpth='" and "/include"? <civodul>slyfox: i suspect Perl cannot be cross-built at this point <roelj>I think that variable is "libc". Did libc build succesfully? <roelj>And libc is: (assoc-ref %build-inputs "libc") <roelj>Is there a way I can see how much disk space is saved by using hard links? <thomasd>catonano: I finally got round to testing gspell. I also get test failures when running the tests as normal user, but for different reasons: it seems gspell cannot find en_US language. Do you know how to provide that? (I have installed aspell-dict-en) <catonano>thomasd: no I don't know how to provide that. Maybe it should be an input ? I donß t even know if locales are pacages or if they are something else <rekado>roelj: do you mean the same info that “guix gc” prints out? <thomasd>catonano: unfortunately gspell documentation hardly mentions the words “language” or “dictionary” :) <thomasd>Also, I'm not sure it's related to locale. (actually, my current locale is en_US.UTF-8) <catonano>thomasd: whhat about the X related error ? Is it gone ? <catonano>it's a spell checking service, after all <thomasd>I don't see any X related errors (probably because it's using my X session?). <thomasd>but which dictionary, and where to put it? :) <catonano>thomasd: I don't know. In the news file I read * Add Croatian translation <rekado>catonano: those are translations of the gspell application itself. <thomasd>looking at Ubuntu logs for their gspell-1.3.3 package, I see some mention of “aspell-autobuildhash” <thomasd>at least that tells me gspell can use aspell dictionaries <ng0>Hi. I want a new requirement for service changes: Please write an announcement of what needs to be applied to the previous version of the service configuration. Sometime I don't have the time to debug and translate what guile throws at me <sneek>ng0, efraim says: is there documentation somewhere about using guix-packaged plugins in vimrc? I'd consider switching <ng0>something with openssh changed <ng0>but I have no idea what <ng0>what used to work before is now "expecting an empty list" <ng0>openssh is a good requirement on servers, so just breaking some sys admins config without providing some small hint doesn't work out <ng0>efraim: yes, just set the rtp to the profile path <ng0>" plugins handled by Guix: <ng0>set rtp+=~/.guix-profile/share/vim/vimfiles/ <ng0>I asked about a better way to handle this in one of the emails in the thread, but never got a response. <ng0>this rtp setting is also how plugin managers for vim do it, but I would prefer to communicate this variable somehow <ng0>never mind about the openssh, I fixed it <ng0>wasn't related to the service <catonano>thomasd: yes, there are "aspell" and "aspell-en" among the packages tha will be installed together with gspell. Like GuixSD propagated inputs <ng0>but I think I will write something up for the documentation, as it would be really good to not just let people read the documentation but to provide help and info upfront <ng0>aspell... fdamn. reminds me of the info I wanted to pass on how Jookia progressed and what needs to be done for *spell stuff <civodul>ng0: re openssh-service, it could be a genuine mistake, perhaps you should report your error on the list? <ng0>no it was no mistake. It was just that I was missing an item in cons* of services <ng0>but I really think if a service changes in some way, an announcement email should be posted so that people understand what broke and how to fix it without having to read the documentation. okay, ideal case you read the documentation, but a public post helps to understand that it's not just some random mistake you made but some change which happened, so you can compile the documentation again and look at it <ng0>(because online documentation is always outdated) <ng0>I might disappear without notice, this laptop is bit buuggy <ng0>I'm a bit frustrated right now by the pull issue.. I thought I spent maybe one or two days setting up a server for testing server related stuff, and another one or two days to set up the gnunet- (and later other) services testing+debugging machine, and now I might have to start again if I can't fix it today, only because bayfront doesn't time out in pull. There's a reason why bayfront isn't in the default set <rekado>re R reproducibility: the easiest way to fix this is to *not* build the recommended packages as part of the “r” package, but to build them separately with “r-build-system” and then using a meta-package to install them along with R itself. <rekado>We don’t have problems with rdb and rdx files in other R packages, so I think we can circumvent this issue like that. <rekado>Debian also does not build the recommended packages, which explains why their package builds reproducibly. <rekado>ng0: I have no problems with “guix pull”. <ng0>but that's just on the one which uses bayfront i naddition to others <rekado>but bayfront is currently not reliable. <rekado>why are you trying to use bayfront? <ng0>I did not know until recently <ng0>what happens with pull is that it never times out <ng0>but with package and system it does <ng0>I'm on the server which does not use bayfront now. and I can now confirm that it only happens with bayfront. A timeout for guix pull is set either much too high or guix pull just picks one machine, but when this is not reachable, it does not try another one <ng0>the bayfront including machine does just add bayfront in addition to the default-subsitutes addrsses <ng0>guix package + guix system address all listed urls, guix pull just bayfront <thomasd>rekado: thanks for the push. I don't have strong feelings about the order of fields :) <ng0>I reconfigured the system to switch back to the default (mirror.hydra) only, and now the pull "issue" is gone. I'll open a bug for guix pull on this, it should definitely time out when a server is not reachable. <civodul>the Cuirass hack that Mathieu O. posted is really cool ***civodul changes topic to 'GNU Guix | https://gnu.org/s/guix/ | GSoC: https://gnu.org/software/guix/news/join-gnu-guix-for-gsoc-2017.html | videos: https://gnu.org/s/guix/help/#talks | bugs: https://debbugs.gnu.org/cgi/pkgreport.cgi?pkg=guix | patches: http://patchwork.sourceware.org/project/guix/list/ | paste: http://paste.lisp.org | log: https://gnunet.org/bot/log/guix'
<civodul>thomasd: now, you can always be a mentor, which is very nice too :-) <civodul>and you're welcome to add more ideas <efraim>Soon it'll be time to add aarch64 to the list at the bottom :) <thomasd>re: mentorship, don't feel up to that right now, maybe next year ;-) I'll think about ideas. <jmd>When do we anticipate core-updates to be merged? <rekado>I could mentor a student who is willing to work on the Bourne-shell compiler front-end. <ZombieChicken>Anyone here ever had problems with rsync crapping itself on the store? <rekado>ZombieChicken: could you describe what “crapping itself” means in this context? <ZombieChicken>just installed rsync from Guix and I'm going to try that, though at this point I'm wondering if the problem is with the hard drive or filesystem since borg also has problems <roelj>ZombieChicken: Is it not "just" computing which files to sync? (the store has many files) <ZombieChicken>roelj: I have a hard time believing that when it's taking several minutes to do that <ZombieChicken>I'll let it plod through for a bit longer and if this doesn't work, I guess I'll run it in strace and see what that brings up <roelj>ZombieChicken: I've experienced no output from rsync for about 15 minutes when rsyncing the store. <civodul>jmd: good question! i think we should go ahead and build it, i was just waiting for a formal reply from lfam <civodul>since lfam & Marius did most of the work there <gnu_guix>All packages should be updated to their latest versions. <ZombieChicken>gnu_guix: Maybe you could politely mention on the mailing list that Blender has been updated, or better yet submit an updated build for it. <ZombieChicken>There is a limited amount of free time the devs have, and it hard enough to keep track of every program and when it's updated <civodul>gnu_guix: i agree with ZombieChicken, and additionally, the tone you used is not acceptable on this channel <civodul>we want it to remain a friendly place for people to work together <roelj>ZombieChicken: Also, the store contains hard links, they caused problems for me when rsyncing to locations that did not support that. I usually did rsync --exclude=.links/ ... in such cases (note that at that point the store should become a read-only thing..) <jmd>ZombieChicken: It's for deduplication, so not terribly important. <jmd>... in the sense that we could have designed it to work without. <jmd>... but don't go deleting it!! <roelj>ZombieChicken: I've been running Guix programs without the .links directory, but I never installed new packages in that store without .links, so I don't know if that would work. <roelj>ZombieChicken: So, for running programs on that remote location, you should be fine.. But for all other tasks, I wouldn't trust on it to work. <civodul>jmd: actually if you delete it nothing bad should happen <civodul>it's just a database of file contents, after all <jmd>But if you delete it, then all the things that point to it will dangle, wont they? <roelj>If you run guix gc --optimize, would it create it? <roelj>jmd: No, the files would remain where they are, but just the second pointer on the filesystem would be gone. <jmd>Oh they ar hard links. <jmd>I thought they were symbolic links. <jmd>ZombieChicken: I did that once, I think it took about an hour on my system. <ZombieChicken>I should have teed the output so I could tail the output file to see what was going on <rekado>ZombieChicken: rsync is quite a bit slower than plain cp. If you just want to copy the thing once you could use “cp” for the first pass and “rsync” for the second. <rekado>ZombieChicken: if the plan is to regularly run rsync I suggest using lsyncd instead, which listens to inotify events. That way you can make use of the fact that the store is append-only. <roelj>rekado: Have you gotten lsyncd to work properly on the cluster? <ZombieChicken>rekado: never heard of lsyncd before. I'll make a note of that since that sounds like a grand idea <jmd>ZombieChicken: Are you Scottish? <jmd>I just recognised the accent. <ZombieChicken>...you can hear accents via IRC now? I don't think IRSSI supports that feature... <jmd>I've only ever heard Scots use the phrase "a grand idea". <jmd>Maybe I should knock up a bot to identify people by their dialects. <rekado>roelj: not on the cluster, but it worked well on my workstation. I sync’d /gnu to my cluster home directory until it filled up :) <civodul>jmd: i'm sure it wouldn't be able to recognized yours, too many different dialects mixed in ;-) <rekado>roelj: I’m not brave enough to deploy it on the cluster just yet. <rekado>roelj: my next step is to set up cuirass for CI (on a separate machine). <roelj>rekado: Looking forward to the results! <roelj>rekado: I'll be writing a better SGE backend for the workflow language and at the same time testing it on the cluster :) <rekado>I’d love to be able to promote your workflow language here once it matures. <roelj>rekado: That'be awesome. We have a "week of code" in the last week of March, wherein we are going to use it. <roelj>rekado: So I'll wait for that first. <ZombieChicken>rekado: Do you know if there is a way to have lsyncd hold a set of changes until a process has completed? For example, to have lsyncd not make changes to the destination until a tar archive has been created of said destination? <rekado>ZombieChicken: lsyncd has several configuration “layers”. I guess you could express something like that with the lowest layer and a custom syncer. But there’s nothing built-in that would help you AFAICT. <ZombieChicken>Yeah, I didn't see anything either in the docs, but I thought I'd ask just in case you knew of something <efraim>It can, depending on thr size of thr partition you can run out of inodes before you run out of space <efraim>Glib failing after Leo's last commit <efraim>When I'm not sshing from my phone I can try updating it <ZombieChicken>efraim: I'm familiar with that problem. Gentoo's portage tree has similar issues <jmd>efraim: Is that true on btrfs ? <jmd>I think it does, but they are dynamically allocated or something. <ng0>"man tor" says it's jist those two <roelj>Is there a way for guix-daemon to restore the permissions of /gnu/store? <roelj>Or is there an easy manual way? <efraim>running make, is the "." in doc/guix.texi:7597 a typo? I got a "you shouldn't do that" warning <efraim>I actually don't either taking a second look at it <Gamayun>ZombieChicken: I'm in Scotland.. ^.^ Not terribly Scottish though. ***exio4 is now known as E4xoi
<ng0>if someone doing rust is around: I have some zero dependency packages in my long graph. With the current state of rust-build-system, can I be sure that 0 dependencies equals no issues? <ng0>out of 82 packages I think =<15 have 0 dependencies <lfam>efraim: Glib is failing on core-updates now? <ng0>I would say it's fairly safe to apply 0 dependency crates. <ng0>they don't break anything if they are broken due to the build system <efraim>lfam: yeah, its giving me the 'too few tests run' error <lfam>I'm testing it now. You think it's the tzdata update? <lfam>You said "Glib failing after lfam's last commit". I'm wondering which commit you meant <efraim>Ah, I'd have to check again, might be tzdata <lfam>I'm building it now to find out <lfam>Updating glib doesn't help. The test error is in a set of tests called 'gdatetime' and it reads like this: <lfam>GLib:ERROR:gdatetime.c:652:test_GDateTime_new_full: assertion failed ("BRT" == g_date_time_get_timezone_abbreviation (dt)): ("BRT" == "-03") <lfam>It's *not* a test failure, but an error <lfam>Time... the final frontier <detrout_>Also don't envy the timezone maintainers <wingo>i feel like my life is better, not having to seriously care about leap seconds and such <lfam>I really respect the work they do. Time is such a thorny issue. <lfam>It's technical, social, and political! <lfam>And they can't ignore or evade the social and political ramifications of their work, unlike most people who work on computer software. <efraim>found out my local trasit authority was selling card readers for ~$2.5 and figured I had to try it out <lfam>Wow, that's really a good price! <efraim>it was about the same price for a replacement card, time to see if I can hack it into a gpg card or something ;) <lfam>copumpkin: We don't use the same build farm, but we do use the Hydra software in our build farm. <copumpkin>okay, so I'm confused what the hydra.nixos.org "gnu" project is for, since it's owned by a user called "ludo" who I assume is civodul <copumpkin>and seems to be building jobs on a machine I'd rather be using for something else :P <lfam>civodul used to be a Nix developer, before starting Guix <copumpkin>this might just be an old and forgotten project on hydra that's consuming resources unnecessarily <wingo>copumpkin: fwiw guile still appreciates the hydra builds <wingo>but do talk to civodul (ludo@gnu.org) if you want specifics, he runs those jobs <copumpkin>was mostly just surprised to see the (fairly scarce) Hydra macs building stuff under the gnu project :) and shaking my fist because I'm waiting for them to build my nixpkgs stuff <wingo>yeah i think regarding negotiating, ludo is the one to talk to :) <wingo>that said, guix's bots only really build on gnu -- so having hydra build gnu packages on mac is valuable <wingo>i understand the frustration tho! <lfam>efraim: I pushed a fix for glib <efraim>not unsuprising, my "smartcard" is unknown <jmd>There are so many levels of software in a smartcard, it is unreal. <efraim>i'm not sure how smart it is, its from the transit authority <efraim>the best part is my real card fails to load correctly <ng0>lfam: you were interested in the live-system thing, right? I'm working on more texts, explanations, motivations etc now, and also a website so that more people can get involved and can get a picture of our vision <lfam>ng0: Yeah, I'm curious about the vision, and how you use Guix to make it a reality <ng0>I'm not sure wether blends of projects are applicable for the Free system list, but once it's usable I'd like to try. that will involve some much more problem and keyboard punching before the project is getting there though. <lfam>Generally, I'm interesting in custom systems based on Guix. I think there is a lot of potential <ng0>the problem is currently too much multitasking… that's why more people need to get involved. more people for (working title pragmaOS) - more people upstreaming to Guix :) <lfam>I don't think that human multitasking is possible, really. The context switch is way too expensive <ng0>it hurts to have so many construction sites when you know that more people can achieve results more quickly by doing less. <efraim>lfam: glib built successfully here ***civodul changes topic to 'GNU Guix | https://gnu.org/s/guix/ | GSoC: https://gnu.org/software/guix/news/join-gnu-guix-for-gsoc-2017.html | videos: https://gnu.org/s/guix/help/#talks | bugs: https://debbugs.gnu.org/cgi/pkgreport.cgi?pkg=guix | patches: https://bugs.gnu.org/guix-patches | paste: http://paste.lisp.org | log: https://gnunet.org/bot/log/guix'
***civodul changes topic to 'GNU Guix | https://gnu.org/s/guix/ | GSoC: https://gnu.org/software/guix/news/join-gnu-guix-for-gsoc-2017.html | videos: https://gnu.org/s/guix/help/#talks | bugs: https://bugs.gnu.org/guix | patches: https://bugs.gnu.org/guix-patches | paste: http://paste.lisp.org | log: https://gnunet.org/bot/log/guix'
<civodul>buenouanq: arm support is here, is just GuixSD support for arm that's not quite there <civodul>although the grub folks told us at FOSDEM that uboot can chainload grub or something <civodul>so maybe there's not much to be done <Gamayun>Yes, that should be the case... I'm not expecting it to work that smoothly though.. :) <ng0>though eoma68 in first generation will not be that powerful. and not even suported by the kind of arm efraim is working on <ng0>the arm is v8, and eoma68 is something hf iirc <lfam>In our system, we call it armhf <ng0>too many arms, getting knots <lfam>Specifically, it's ARMv7-a architecture, and a Cortex-A7 CPU. It has great support in Linux but it's rather slow, unfortunately. <lfam>The specific implementation in the eoma68 has a lot of potential (gigabit ethernet, SATA), but eoma68 doesn't expose all the features. <lfam>But eoma68's explanation of why they left them out makes sense, I think: "I chose to add a second USB2 port and the option to go all the way up to USB 3.1 which I think covers way more than GbE and SATA. <lfam>So in the future (over the next ten years) we anticipate there being low-cost SoCs with USB 3.0 and USB 3.1 so you can connect multiple GbE and SATA ports, which would be awesome. " <ng0>there are some rough edges with system reconfigure. Sometimes I get kicked out of the X session. <lfam>Ah, yes :) Do the reconfigure from the console (maybe another tty) <ng0>I'm not sure if this was reconf. or build though <lfam>The reconfiguration may restart the graphical-desktop services, if I remember correctly <ng0>at least that's one bug I opened <civodul>alezost: the extra buttons in package-info buffers are awesome :-) <alezost>civodul: thanks, I like them too :-) <bavier`>is it possible for a service to start two shepherd services? <civodul>bavier`: a GuixSD service can produce zero or more Shepherd services <civodul>it "extends" shepherd-root-service-type with a list of Shepherd services <bavier`>I'm working on a clamav service, which has potentially two daemons that need to be run <luser`>How do you guys manage to install packages via package.el without installing dependencies you already have? I have avy installed through guix (I'm on a guixsd system), yet another version of avy gets installed in ~/.emacs.d/elpa when a package requires it. <civodul>i think you should use guix.el instead of package.el :-) <luser`>civodul: I don't believe guix.el is related to what I'm talking about. <alezost>packages installed with package.el also have dependencies and they will be installed anyway <alezost>but I don't see any problem with that: it's unlikely that packages from guix and from (m)elpa will be incompatible <alezost>though it's better to stick either to Guix or to elpa to avoid potential problems :-) <civodul>luser`: i means guix.el (aka emacs-guix) is better than package.el in several ways IMO <civodul>you wouldn't worry about this sort of things with guix.el <luser`>guix.el is for installing guix package, not elisp packages. <alezost>right, guix.el doesn't have anything to do with elisp packages <catonano>luser`: guix contains several elisp packages <OrangeShark>you are basically asking for another package manager to know about packages from another package manager. <catonano>luser`: you can install emacs packages with guuix <luser`>OrangeShark: I'm asking for emacs to be the middle man in this coordination :) <luser`>catonano: Yes, I do installing some emacs packages with guix. <alezost>luser`: I also install some packages with guix and many using package.el <luser`>I'm just thinking, what's the point of using guix for elisp packages if you're going to use package.el. <alezost>if you are going to use package.el, I think there is no point to use anything else; but I'm going to use guix for everything <luser`>It'd be interesting to do something with melpa but for guix. <luser`>Anyways, I'd rather use guix, so I'll avoid package.el. Unfortunately it means I'll have to go without some packages until I decide to not be lazy and learn how to package using guix. <luser`>Thank you, civodul, alezost, I'll look into those links. <catonano>luser`: I packaged a handful of emacs packages myself. It's relatively easy <lfam>civodul: Should we try to apply the strmov patch that was applied to GCC 5 to the other versions of GCC? <lfam>civodul: lsh doesn't build with GCC 5, so we should try adapting the patch for 4.9 <efraim>Was it only one or more packages that wanted bdb@5.3? <lfam>efraim: I don't know, was it discussed previously? <efraim>Maybe more, we needed the second version for something <civodul>lfam, efraim: shouldn't we start building all the packages? <lfam>Grep says that openldap is using bdb-5.3. <rekado>oof, I just learned that R actually is NOT reproducible even on Debian. <civodul>seems you've been testing things way beyond the core set <lfam>civodul: Yes, if the "impossible cross-build" bug is fixed, I'll start the evaluation <rekado>been trying all day to figure out why it works for Debian … but actually it doesn’t :) <lfam>efraim: bitcoin-core needs an update, too <efraim>Ive been playing on aarch64, core-updates or bust <civodul>there were also "false" build failures due to networking issues or similar <lfam>Right, those are "expected" <lfam>Maybe "typical" is a better word. <lfam>The connotation in English is very negative, so perhaps it's the right word :) <civodul>i thought we had less of these with the guile-ssh-based offload thing <lfam>I can't say if it's still typical. <lfam>Anyways, my "tests" so far are to try reconfiguring my headless GuixSD system. <efraim>I have on my aarch64 to-do list fixing go for aarch64 and mips <efraim>I try building out to gtk and gtk2 <lfam>I haven't thought about it much since I posted it. I find dealing with the Go team to be draining :( <lfam>civodul: To change the core-updates jobset so that it builds everything, do I remove the "subset" field from the list of inputs? <efraim>I need to figure out lumina not showing up in slim and then its ready to be sent to guix-patches <civodul>lfam: you can remove it or set it to "all" <civodul>lfam: BTW Ian Lance Taylor of Go is a long-time GNU hacker <civodul>author of the Go frontend in GCC too <civodul>note that it really solves your problem, but maybe it helps to know you're talking to a friendly person ;-) <lfam>That's cool. I don't keep track of exactly who I deal with when I am reporting bugs to them. But I've had some interactions that felt very unfriendly. I guess they get a huge number of bug reports and are probably feeling drained as well. <lfam>I know it's not fun to get bug reports from people who don't understand the nature of the problem (I'm not a Go programmer) <lfam>Ah, that magic phrase "supposed to" :) <lfam>Core-updates evaluation started! <slyfox>i can try to look at go stuff. don't guarantee much though :) <rekado>civodul: is it normal that I receive a lot of admin messages from guix-patches? Do I ever need to act on them? <lfam>slyfox: Please, feel free :) <civodul>rekado: it's normal but you don't normally need to act on them <civodul>i guess the signal-to-noise ratio in my inbox was already low before that ;-) <rekado>I’m probably going to unsubscribe from guix-patches and only use it through the Emacs debbugs interface. <lfam>I've been getting lots of messages from guix-patches without any quoted discussion and empty subjects. It's a bit of a regression in the quality of the communication, IMO. <lfam>But, I'm not sure why it's so different for guix-patches. <lfam>efraim: Did we try using the latest bdb in openldap? <efraim>It just failed for me, said it was incompatable <rekado>but quoting has always been a little unsatisfactory <lfam>As a general idea or as practiced in the Guix mailing lists? <rekado>some people quote too much (so I’m scrolling till the end even though nothing more follows); others quote too little. <lfam>Either way, it's really tedious to get messages with zero context except for a bug number. <civodul>i guess it's painful if one doesn't use debbugs.el <lfam>I don't have these problems with bug-guix@gnu.org, which is the same thing <lfam>Maybe it's a different set of people <lfam>Does debbugs.el somehow encourage you to empty the subject line? <civodul>no, but it makes it easy to find out which thread a message belongs to <lfam>I wonder how these no-subject messages are being created :) <lfam>efraim: I think it's not a bad idea to use sqlite instead <lfam>Well, the guix-patches thing isn't a big deal. Maybe if it grows into a hundred context-free messages per-day then I'll really investigate :) <lfam>I wouldn't have brought it up if guix-patches wasn't already being discussed <lfam>Once again, mark_weaver shipped icecat bug fixes to Guix users before other distros :) I just got the Debian advisory