IRC channel logs

2017-10-29.log

back to list of logs

<ng0>this portagefile tool on Gentoo had the ability that you could "ask" it (or rather the listing online) about a name of a binary or file, and it would give you results with package names and paths
<ng0>without the fully functional portage it would only return a small minority of results
<ng0>I have doubts about Kallithea (I still have it in a branch here). It's not a good sign when the public reference installation no longer works..
<ng0>does someone of you know more about them? I could open a bug on their bugtracker
<ng0>basically: https://kallithea-scm.org/repos/
<ng0>"Internal Server Error"
<ng0>they still have commits happening on master though
<ng0> https://bitbucket.org/conservancy/kallithea/commits/all
<rekado>What are we looking for in a friendly web interface to debbugs?
<rekado>Ideally I’d like to know what you’d like to see where https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix-patches fails in your opinion.
<rekado>I wrote a little thing called “mumi” (for “mediocre…, uh, mail interface”) that uses “mu” to search patches sent to guix-patches@gnu.org
<ng0>A better way to make debbugs "tags"/actions visible
<ng0>and the assigned "person" as far as debbugs concept of assignment goes
<ng0>that's what I can think of right now
<rekado>well, that’s called an “owner” in debbugs, and it’s shown at the very top, e.g. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25728
<rekado>would you like this to be displayed differently?
<ng0>I believe that having it in a fashion like current Mailman or other software, on the side, would be better
<rekado>(I’ll have to fork mu to also index certain debbugs headers, so that I can avoid linear traversal of all matching emails)
<rekado>ng0: similar to how it’s done on github?
<ng0>or gogs and similar applications
<ng0>the static sidebar would tell you the interactions, while the rest of the screen would give you the actual dialogue and content
<ng0>(whiteboard would be easier, but I hope you get what I'm hinting at)
<rekado>okay, thanks. That’s helpful.
<ng0>I discussed bugtrackers somewhere else with a contact of mine, and the general idea from their side was that all bugtrackers integrated into git-forge solution out there suck, and freestanding bugtrackers are rare and no one ever got it right. To get this right, or at least improve the interface to default debbugs would be great work. (I'm okay with it as it is)
<ng0>*somewhere else this week
<ng0>Although this would be an extension of debbugs itself: A system to "approve", or mark bugs as "LGTM" etc and indicate this would be good.
<ng0>In the longterm I'm thinking about http://www.liquid-democracy-journal.org/issue/4/The_Liquid_Democracy_Journal-Issue004-01-Democratic_Revision_Control_with_LiquidFeedback.html with some extensions, but this is beyond debbugs :)
<ng0>good night
<dfens>Hi, I'm running `guix system init /mnt/etc/config.scm /mnt --fallback` and get the following error:
<dfens>grub-install: error: /gnu/store/bdzxdpdw25k8v6lz54clz42bilx47srj-grub-2.02/lib/grub/x86_64-efi/modinfo.sh doesn't exist.
<dfens>Please specify --target or --directory.
<dfens>guix system: error: failed to install GRUB on device /dev/sda
<dfens>Under /gnu/store/...-grub-2.02/lib/grub/ there is only i386-pc.
<dfens>I am trying to install GuixSD
<fusion809>Hi folks I have another query, hopefully my last, how can one set SLiM to autologin? The Arch Wiki has an article on this but it's not exactly applicable as is to GuixSD as /etc is regenerated on boot and their method involves editing /etc/slim.conf.
<fusion809>Read here https://lists.gnu.org/archive/html/guix-devel/2015-09/msg00752.html that adding (slim-service #:auto-login? #t) to the system configuration might do this. Is this still applicable?
<fusion809>Adding it gave an error when I tried to run guix system reconfigure: "/etc/config.scm:51:2 error: invalid field specifier".
<fusion809>That was when it was listed under (operating system
<emyles`>\\quit
<fusion809>What are paths relative to in /etc/config.scm? I'd like to specify a sudoers file but placing it in /etc/guix/sudoers and specifying that exact path in config.scm causes the build to fail as it can't find that file.
<fusion809>Specifying guix/sudoers in it too also fails
<Apteryx_>You need to wrap the file path into a file-like object as can be obtained by using local-file or plain-file (see 6.2.2 in the info manual).
<Apteryx_>In your case you'd want local-file since you have the file on disk
<dfens_>I'm hitting this error installing guixsd:
<dfens_>grub-install: error: /gnu/store/bdzxdpdw25k8v6lz54clz42bilx47srj-grub-2.02/lib/grub/x86_64-efi/modinfo.sh doesn't exist.
<dfens_>Under /gnu/store/...-grub-2.02/lib/grub/ there is only i386-pc.
<dfens_>Any ideas?
<fusion809>Apteryx_: so (sudoers-file (local-file ("guix/sudoers" ""))) should do it? Undo (operating-system that is
<fusion809>Nvm I figured it out, needed to get rid of ( from round "guix/sudoers"
<Apteryx_>I'd pass the full path to be sure (local-file "/etc/guix/sudoers")
<Apteryx_>I'd just leave it choose the default basename instead of an empty name "". It'll help you to know what that is under your /gnu/store/hash-basename.
<dfens>Apteryx_: sorry, I got disconnected and might have missed some of your messages I think>
<Apteryx_>dfens: I didn't have an idea about your problem, sorry. But maybe you could post your config, that'd help.
<Apteryx_>(on some paste site such as paste.lisp.org)
<dfens>Ok sure, I can do that.
<dfens>Apteryx_: http://paste.lisp.org/display/359729
<dfens>I'm just using the default minimal desktop install but with ratpoison removed.
<dfens>I am using the guixsd-usb-install-0.13.0.x86_64-linux image too
<fusion809>Hey folks Guix is meant to be cross-distribution right? On Arch Linux running guix package -i icecat returns: `guix package: error: build failed: failed to get list of supplementary groups for ‘fusion809’`. Any ideas why?
<fusion809>I am in the guixbuild group
<bavier1>fusion809: it's not recommended to be in the guixbuild group
<fusion809>OK, so I'll remove myself from guixbuild, is that all I need to do to fix this error?
<bavier1>maybe
<bavier1>did you setup build users as outlined in the manual?
<fusion809>Didn't realize there were instructions for people using it on other distros
<bavier1>fusion809: https://www.gnu.org/software/guix/manual/html_node/Setting-Up-the-Daemon.html#Setting-Up-the-Daemon
<fusion809>Aha it works. Sorry should have read the manual, thanks for your patience. There is one thing, however, that I know the manual can't help me with as I have looked for this in it. How do I set slim to autologin on boot on GuixSD? The manual mentions it briefly but it gives no examples so I am rather stymied as to what to do
<fusion809>It's mentioned here under slim-service https://www.gnu.org/software/guix/manual/html_node/X-Window.html
<fusion809>I've tried adding (slim-service #:auto-login? #f) to my config.scm under (operating-system
<fusion809>but it gives error when I try to reconfigure with guix system reconfigure
<bavier1>fusion809: hmm, I'm surprised. The slim-configuration type isn't mentioned in the manual
<bavier1>fusion809: basically, you'd use modify-services like usual to replace the configuration for the slim service
<bavier1>fusion809: like (modify-services %desktop-services (slim-service-type config => (slim-configuration (inherit config) (auto-login? #t))))
<bavier1>but obviously adapted to your config.scm
<fusion809>Thanks. I've got a modify-services part of it, do I create a new modify-services line or do I just incorporate that (slim-service-type... under it?
<bavier1>fusion809: you can use a single modify-services to change multiple configurations
<bavier1>the "System Services" section in the manual has an example of changing multiple configs
<fusion809> https://imgur.com/tX0zw5r.png shows my config and what error I'm getting when I run it. Gives an unbound variable error for slim-service-type. I think I copied what you said.
<bavier1>fusion809: do you have the "xorg" service module loaded?
<bavier1>e.g. in use-service-modules
<fusion809>I don't I have desktop though
<fusion809>With xorg it ran fine. Thanks
<bavier1>cool
<fusion809>That's odd when I rebooted slim didn't autologin
<bavier1>oh, now I just read the manual
<bavier1>you'll need to specify a value for 'default-user'
<bavier1>which makes sense
<fusion809>where do I do that? Under (operating-system?
<bavier1>in the slim-configuration
<fusion809>What like this https://i.imgur.com/3SDemUH.png?
<fusion809>reconfiguring with that fails.
<fusion809>maybe a ' before fusion809?
<bavier1>make it a string
<bavier1>i.e. "fusion809
<bavier1>"
<fusion809>Ah, thanks
<bavier1>(no newline, fat fingered)
<fusion809>Some weird minimalist UI has been started on reboot. Guessing I'll also need to specify the desktop environment somehow?
<fusion809>Window maker it is
<bavier1>you can use ~/.xsession for that
<fusion809>I've never used one before except for i3 where I used a feh command. So I tried to model it after what the Arch Wiki says xinitrc should look like for GNOME but it's failing to launch. What should be in it for GNOME?
<fusion809>Nvm I found something online
<fusion809>Adding gnome-session to it. I added exec and that's why it's failing or I think
<fusion809>Well gnome-session didn't work either
<fusion809>Any ideas of what to do? I'm stuck. DuckDuckGo search doesn't reveal anything helpful that I haven't tried
<bavier1>I've not used ~/.xsession before
<bavier1>though I'm curious what our gnome DE is like (haven't tried it yet), so I'm spinning up a vm
<fusion809>Looks not bad. I like the SliM theme too
<fusion809>GuixSD is truly a GNU system with it as GNOME is developed as part of the GNU Project
<fusion809>Uses GNOME 3.24.3 at the moment, with 3.26.1 being the latest. But still not too bad, version-wise.
<bavier1>cool
<bavier1>seemed to work for me
<bavier1>'chmod +x ~/.xsession' was the only stumbling block
<bavier1>`printf "#!/bin/sh\\nexec gnome-session\\n" >~/.xsession`
<bavier1>fusion809: ^
<fusion809>Ah thanks. Odd I had exec gnome-session in there one time but it didn't work.
<brendyn>is it possible to get ./configure; make to work on GuixSD?
<xelxebar>The docs say that lvm isn't supported yet, but the mailing list makes it look like some people got it working.
<xelxebar>Anyone know much about its current status?
<benny>I tried again and I'm still unable to get UEFI to work on GuixSD, is there an example config somewhere?
<xelxebar>benny: Are you using grub-efi-bootloader?
<benny>xelxebar: I'm trying to by using (bootloader (grub-configuration (grub grub-efi) (device "/dev/sda")))
<benny>I found a thread from April '17
<benny> https://lists.gnu.org/archive/html/help-guix/2017-04/msg00120.html
<benny>maybe the usb image still isn't uefi compatible which is why it still fails now
<efraim>the 0.13 image doesn't support (grub-configuration ...), but needs the older style
<efraim>nvm, I had it backward
<efraim>for my 0.13 install though, I had (device "/dev/sda1"), where /dev/sda1 was mounted at /boot/efi
<benny>that's what I'm using efraim, but grub install always fails
<efraim>With /dev/sda or /dev/sda1?
<benny>I tried both, I also have /dev/sda1 under filesystems and mounted to /boot/efi explicitly
<benny>but if I know it works in general I can at least continue trying, for now I have to leave
<fusion809_>Ye may wish to know that http://mirror.ibcp.fr/pub/CPAN/authors/id/L/LE/LEEJO/CGI-4.35.tar.gz and ftp://ftp.ciril.fr/pub/cpan/authors/id/L/LE/LEEJO/CGI-4.35.tar.gz seem to be down or moved as Guix is failing to download from these sites.
<fusion809_>May be the mirror.ibcp.fr and ftp.ciril.fr servers that are down as Test-Deep is failing to download from there too
***Piece_Maker is now known as Acou_Bass
<ng0>anyone feeling reviewing frei0r and the addition of it to ffmepg? I've only just sent it, but I made a couple of corrections
<efraim>Newsboat us an active fork of newsbeuter, part of me wants to write a clobbering substitute* on the whole thing to rename all the parts so I don't have to change my configs at all
<htgoebel1>Hi guix
<htgoebel1>When booting the install-image, /gnu/store is a unionfs - even before activating cow-store.
<htgoebel1>Where is this set up? I tried hard, but did not find the code.
<ng0>in the file that is used to create the image
<ng0>gnu/system/install.scm iirc
<civodul>Hola Guix!
<civodul>htgoebel1: this happens in (gnu system install)
<civodul>all the installation image is defined there
<htgoebel1>ngo, civodul: I did not find it there. This sets up a unionfs for /gnu/store only when starting cow-service – which according to the code has to be done manually.
<htgoebel1>Also %immutable-store is not unionfs but just a bind-mount.
<htgoebel1>And in linux-boot.scm unionfs is used to setup the volatile root only, not for the store.
<htgoebel1>I' confused?!
<htgoebel1>Anyway: Actually I wanted to verify if my changes from unionfs to overlayfs are working properly.
<htgoebel1>So is you can point me to some test-case, my question is obsolete :-)
<civodul>htgoebel1: note that 'guix system vm' creates a unionfs for the root file system
<civodul>this takes place in (gnu system vm)
<civodul>search for "volatile"
<civodul>then the actual mounting and stuff goes to (gnu system linux-initrd)
<civodul>i hope that sheds some light :-)
<civodul>what terminal emulator with scalable fonts and a small closure would people recommend? (apart from M-x shell)
<ng0>st, if you like to apply patches
<ng0>oh, scalable fonts as in you can resize?
<ng0>which is tiny (91MB) compared to mate-terminal (~600MB)
<civodul>ng0: yeah looks like st doesn't fit the bill
<Apteryx_>civodul: In the continuous integration world (such as hydra is providing), is there a strong case against reusing previous build artefacts to speed things up? I know it introduces complexity at handling determinism, but it's doesn't seem unmanagable to me.
<Apteryx_>Seems wasteful to start from scratch every time when we have the means to only rebuild files affected by the latest diff.
<civodul>Apteryx_: in the purely functional model, we don't want to reuse a handle of prebuilt files to speed things up
<civodul>or, put it differently, the granularity is that of derivations
<htgoebel1>civodul: I checked all this without success.
<htgoebel1>unionfs is only used twice in the whole code:
<htgoebel1>1) In gnu/build/linux-boot.scm (mount-root-files-ystem) to make a unionfs root
<htgoebel1>2) in gnu/system/install.scm (make-cow-store)
<htgoebel1>So I thought it may be a file-system defined in install.scm, but there is only %immutable-store, which does a ro-bind-mount, not a unionfs.
<htgoebel1>And in the disk-image's initrd's init-script I could not even find this.
<civodul>Apteryx_: so if you make derivations smaller, you can reuse more
<civodul>that's what the "guix pull" patch does
<civodul>htgoebel1: if you search for "volatile" or "unionfs", you'll definitely find the relevant code :-)
<civodul>htgoebel1: so what's the question exactly?
<htgoebel1>civodul: I did :-\\
<htgoebel1>civodul: The actual question is: Which test (-case) to run after replacing unionfs with overlayfs
<civodul>if you can run "make check-system TESTS=basic", then you'll probably good
<htgoebel1>(The otehr stuff is just curious (un-explainabel) things I found when trying to test manually)
<htgoebel1>civodul: "make check-system TESTS=basic" on my development machine? Or in some VM?
<Apteryx_>civodul: I see. Yeah, it would introduce the requirement to track a state, such as the closure that built the previous build. A change of that closure (say we updated Guile) would trigger a fresh build. Not ideal. But it'd reduce the build time phenomenally and save electricity ;)
<htgoebel1>I want to cover the cow-store service in the installation image due to http://bugs.gnu.org/23056
<civodul>htgoebel1: on your machine
<htgoebel1>civodul: Will do. Thanks
<civodul>it spawns VMs: https://www.gnu.org/software/guix/manual/html_node/Running-the-Test-Suite.html
<civodul>htgoebel1: oh if you're targetting cow-store alone (a good idea), then you want to run one of the installation tests, which are much more expensive
<civodul>like "make check-system TESTS=installed-os"
<civodul>see (gnu tests install)
<Apteryx_>civodul: I'll test your guix pull branch from now
<civodul>cool!
<Apteryx_>By the way, where is that wip-pull-derivation branch? I've 'git fetch --all', and 'git branch -a' doesn't reveal it.
<civodul>Apteryx_: it doesn't exist, you have to create it :-)
<civodul>well it exists on my laptop
<Apteryx_>I see! thanks
<Apteryx_>By the way, I've gleaned from the Debbugs UG info manual that there is some function already there to apply patches easily; whether they come as attachments or in the message body: '(debbugs-ug)Applying Patches'
<civodul>oh!
<Apteryx_>I haven't tried it until now. Let's see how well this works!
<civodul>it's very much biased towards the Emacs source tree, from what the manual says
<civodul>but we could adjust it
<Apteryx_>It's just a matter of adjusting 'debbugs-gnu-trunk-directory to point to ~/src/guix, say.
<Apteryx_>(IIUC) :)
<Apteryx_>Or manually choosing from the minibuffer by using a prefix: C-u M-m
<Apteryx_>civodul: you're right, there's some emacs specifics in the debbugs-gnu-apply-patch function.
<civodul>so M-! git am -s is not that bad :-)
<Apteryx_>yeah, it's not!
<Apteryx_>Works especially well when the patches are sent using git-send-email
<Apteryx_>civodul: actually '|' is better than M-!
<efraim>From the web interface it isn't great
<civodul>Apteryx_: oh right, M-|
<civodul>efraim: it definitely sucks
<civodul>i thought one of us could write a SOAP client, and then we could provide a better interface
<civodul>SOAP doesn't seem difficult to handle
<civodul>and there are good web folks in our community, too :-)
<efraim>ng0's patches aren't bad because I can normally find their branch with the patches, then git-cherry-pick takes care of it
<Apteryx_>civodul: without meta on my side, just '|'; it's bound to 'gnus-summary-pipe-output'.
<efraim>I want something like mutt or newsbeuter to deal with the patches, written against stfl or guile-ncurses I guess
<ng0>what?
<ng0>ah
<ng0>I've recently felt I need a bugtracker for my work… and (once more) I've been reading the Debian work and crash on Gitlab (just for git interface though) https://anarc.at/blog/2017-06-26-alioth-moving-pagure/ and they have worked 5 years on Gitlab… hardcore. I'm just thinking of getting more RAM and use pagure.. they might not be good at bugs, but it's a compromise
<ng0>s/crash/heavy disagreement
<ng0>I have problems reviewing where the patches aren't simply appended… Maybe one day I write an extension to neomutt or stop using it
<ng0>I have to save the attachments and paste in the headers
<efraim>I think my gccgo patch series needs the gold linker to work
<ng0>efraim: speaking of git… temporarily my git is under maintenance.
<efraim>it happens
<Digit>i dont understand why this is "GNU GUIX" am i missing something? https://www.youtube.com/watch?v=vZtXPg9xU4o
<buenouanq>I have no idea, that's strange.
<ng0>trolling?
<ng0>people are strange
<ng0>reddit, *chan,… whoknows
<buenouanq>EOMA68 ships in just a few weeks - How's that ARM support coming along? (-‿‿ - )
<ng0>is there a Texinfo translation of http://pubs.opengroup.org/onlinepubs/9699919799/ you know of? I know IEEE has a pdf version for purchase/sign-in
<fusion809>It turns out that those Perl packages weren't downloading as the source files no longer exist on the server. Only newer versions of those packages exist on that server. So, for example, for Test-Deep 126 and 127 versions exist on the server. Guessing filing a bug at https://bugs.gnu.org/guix is the appropriate way for me to inform Guix developers of this problem?
<efraim>tig seems to have moved the release tarballs to github
<efraim>fusion809: yes, that would be a good way
<efraim>we try to keep the cpan mirror list up-to-date with the mirrors that host the older tarballs also
<fusion809>Um how do I file a bug? I don't see any option to file a bug there.
<ymak>hi there
<ymak>i need instruction for installation guix near debain
<efraim>fusion809: you can send an email to bug-guix@gnu.org
<fusion809>Ah thanks.
<buenouanq>ymak: $ sudo apt-get install guix
<ng0>buenouanq: no? unless Debian changed recently
<buenouanq>is it really not in the debian repos?
<ng0>no
<buenouanq>weird
<buenouanq>sorry
<ng0>see the previous discussion of Whonix devs and Debian on the Debian bugtracker
<ng0>somewhere around here https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00158.html
<ng0>or wherever it was
<buenouanq>what's incomplete about this then? https://www.gnu.org/software/guix/manual/html_node/Binary-Installation.html
<buenouanq>I'm also a bit confused about the use of the word `near'. Do you mean instead that you'd like to dual boot Debian and GuixSD?
<ymak>ok, sorry. i would have both debian and guix
<ymak>already i have debian on host
<ng0>so Guix on Debian
<buenouanq>just the package manager?
<ng0>There's Guix and there's GuixSD
<ymak>i have usb bootable disk
<ymak>no
<buenouanq>so.. dual boot?
<ymak>i want try whole distribution
<ymak>yea
<ymak>yes
<ymak>dual boot
<buenouanq>if you just want to try it using the qeum vm image might be best/easiest
<ymak>thanks, but my plan is to replace my current distro
<buenouanq>to dual boot you may have to re partition your harddrive and do some magic with grub
<buenouanq>I've only ever dual booted using refind, so I won't be of any help in this, sorry.
<ymak>ok, thanks
<buenouanq>but there are others here who prolly can help, don't just leave ;~;
<fusion809>Well if anyone has anything to add to my bug report on CPAN packages it is here https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29060
<rekado>fusion809: thank you
<fusion809>YW. I'd love to see this bug fixed ASAP as until it's fixed I can't install IceCat with Guix. I developed a liking for it from using GuixSD.
<civodul>fusion809: did you disable substitutes?
<fusion809>Is it enabled by default? Do you mean alternative mirrors as two mirrors were tried and they both failed.
<civodul>this: https://www.gnu.org/software/guix/manual/html_node/Substitutes.html
<civodul>it's enabled by default on GuixSD, but not on other distros
<fusion809>Sounds great, but the only thing is there's no link to download the hydra.gnu.org.pub file.
<fusion809>Guessing I'm missing something
<Apteryx_>#24069 can be closed if someone dares merging it into core-updates ;)
<civodul>fusion809: see https://www.gnu.org/software/guix/manual/html_node/Binary-Installation.html :-)
<civodul>Apteryx_: so it's patch v4, right?
<civodul>did you test it on core-updates?
<fusion809>That's odd ~/.guix-profile for root doesn't exist for me. Is there something I need to do to set it up?
<civodul>how did you install Guix?
<rekado>fusion809: step 3 talks about it.
<fusion809>Rofl, sorry.
<fusion809>I'm running a distro with systemd and ~root/.guix-profile/lib/systemd/system/guix-daemon.service doesn't exist
<fusion809>Granted I installed Guix with my package manager instead of from the binary tarball.
<fusion809>Ah it's because /var/guix/profiles/per-user/root/guix-profile doesn't exist
<civodul>perhaps you should discuss this with the packagers of Guix on your distro
<rekado>I played around with this debbugs frontend I wrote and noticed that the emails that are sent to debbugs.gnu.org may not be sufficient to get all information about the patch database.
<Apteryx_>civodul: yes, v4!
<rekado>looks like it would not be enough to subscribe a bot to the mailing list
<fusion809>I think I'm going to uninstall Guix with my package manager, and install it from the binary. In case my package manager deletes /gnu/store I'm compressing it to back it up. Would decompressing it after I've installed it using the binary successfully restore my packages installed with Guix?
<rekado>maybe I’m just missing control messages that are the result of using the emacs interface to debbugs.
<rekado>fusion809: that wouldn’t help as Guix will ignore items in /gnu/store that are not registered in the database (which you would overwrite)
<civodul>rekado: yeah i think it's safer to have a SOAP client like debbugs.el does
<civodul>then, if the mu Guile bindings are good enough, we could use them to send control messages when someone clicks
<rekado>the mu bindings only give you read-only access to mails in the database
<civodul>oh, ok
<civodul>Mailutils does all things email, but its bindings are currently stuck to 2.0 i think
<civodul>but anyway, a SOAP client and a web UI would be a great start
<mb[m]1>There's also "patchwork", which is designed to be a web UI for email patch workflows and can hook into other things: http://jk.ozlabs.org/projects/patchwork/
<mb[m]1>FOSDEM 2017 talk: https://archive.fosdem.org/2017/schedule/event/patchwork_jenkins/
<rekado>mb[m]1: we tested patchwork before, but I wasn’t really happy with it.
<rekado>too much manual work was required to keep it in sync with the actual status of patches.
<rekado>here’s what mumi looks like now: http://berlin.guixsd.org/.well-known/mumi.png
<mb[m]1>Oh, okay. Mumi looks great!
<rekado>thanks
<rekado>guess I’ll have to write a SOAP library for Guile next to get at extra info that debbugs keeps to itself.
<rekado>maybe next week
<rekado>ACTION —> zzZ
<mb[m]1>gn