Re: virtual network interfaces in container
Hello Chris, Christopher Baines writes: [...] > So, a while back, I did send a patch to at least allow sharing the hosts > network, just like the --network flag to guix environment. this would be a nice feature! we still couldn't have isolated network interfaces per container but it's a very useful feature having declaratively managed "guix system container"s [1] is great but they are not so useful without networking, or am I missing some important use case here? > The patch is here [1], unfortunately, it's been a while since I looked > at it. I should really try and neaten it up and get it merged in, but > it's there if that's useful to you. > > 1: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=28128 I've looked at it but AFAIU your patch https://debbugs.gnu.org/cgi/bugreport.cgi?bug=28128#8 is still to be reworked https://debbugs.gnu.org/cgi/bugreport.cgi?bug=28128#14 sorry but I'm still not able to test and adapt it to Guix, I cannot help here [...] Thanks! Giovanni [1] although I still miss the possibility to nest a container/VM declaration in the host configuration.scm... but we can work it out -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: Public key missing for Guix installation script?
Hello Evan, please consider that help-g...@gnu.org is more appropriate for this kind of questions :-) evan.stra...@gmail.com writes: [...] > this command: > gpg --keyserver pool.sks-keyservers.net --recv-keys > 3CE464558A84FDC69DB40CFB090B11993D9AEBB5 > > However, upon running that gpg command, I receive the following error > message: > "gpg: keyserver receive failed: No data" once it happened to me too: I tried a second time and I was able to import the key unfortunately it seems that the keyserver network is someway abused; see https://dev.gnupg.org/T4163 for details AFAIU there is nothing Guix devels can do about this, just be patient about this keyserver issue ;-) HTH! Giovanni [...] -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: Public key missing for Guix installation script?
On Wed, Feb 13, 2019 at 09:02:46PM -0800, evan.stra...@gmail.com wrote: > Hello, > Tried to post this once before but it got rejected from the mailing > list for some reason. > I'm trying to install GNU Guix using the installation script > (https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh) > . > > Early on, there is a GPG verification step that fails due to a missing > PGP key. The script tells me: > [1550113585.102]: Starting installation (Wed Feb 13 19:06:25 PST 2019) > [1550113585.106]: [ PASS ] verification of required commands completed > [1550113585.113]: [ FAIL ] Missing OpenPGP public key. Fetch it with > this command: > gpg --keyserver pool.sks-keyservers.net --recv-keys > 3CE464558A84FDC69DB40CFB090B11993D9AEBB5 > > However, upon running that gpg command, I receive the following error > message: > "gpg: keyserver receive failed: No data" > > It appears this key is missing from the key server. Additionally, I've > been searching all around other key servers for this key and I can't > find anything. > Not sure what to do about this. Is there a place I can find this key, > or is it safe to just comment out the verification step in the > installation script for now? > > Thanks, > - Evan > I come across this occasionally, so in my scripts I've changed it to: until gpg --recv-keys 3CE464558A84FDC69DB40CFB090B11993D9AEBB5; do echo "trying again..."; done The key is also available at http://www.fdn.fr/~lcourtes/ludovic.asc -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: It's time to build "guix deploy"
On Thu, Feb 14, 2019 at 08:14:15AM +0100, swedebugia wrote: >I understand most parts of it ;) >It is a real beauty and a testiment to the power of Guix and Guile. > >actually mainenance.git is full of treasures :-) > > Berlin consists of a head node and many almost identical servers. > >AFAIU remote servers could be completely different each other for your >script to do its job, or am I missing something? So, essentially, the tools login via ssh and control guix remotely and copy files which will also work on an underlying Debian. This looks a lot like the Python automation system I used in the past with cloudbiolinux: https://github.com/pjotrp/cloudbiolinux Later I created a simple Ruby system that takes YAML files as input and runs *locally* . A remote invocation called that local system. The advantage is that is does not lean on ssh too heavily (one login required and you could move to a different client-server protocol easily - even over http). I am still using that setup today, to configure web, mail servers and home directory. The tool is here https://github.com/pjotrp/deploy An example of use for emacs is emacs.yaml: --- - copy-file: emacs: dest: .emacs mode: "400" - dir: .emacs.d: source: emacs.d recursive: true and the emacs files sit in a git directory in the same tree and get copied across running 'deploy emacs.yaml'. It is not fancy, but it works well. Of course we should not use YAML with guile ;). WISP would work fine. Note that I have used Cfengine extensively (even wrote my own clone), Also used Chef and Puppet. After all that I ended up with writing a *simple* system that does not keep track of state but simply copies files. Guix would do this better by providing transactions and isolation. I think my preferred way to do this is to copy files into the store and use guix deploy so symlink them from $HOME and /etc - i.e., a profile with another layer of symlinks. This means that when a profile goes out of scope the symlinks stop working too. They dangle, that is all, but should be easy to harvest since you know what directory you are linking in. Guix deploy runs locally on a machine and can be invoked remotely. One advantage of running locally is that it is fast and much easier to test. That would work on Debian+Guix too. Pj. PS I like the logo :) https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/berlin.scm#n50 (though not used there).
Re: Public key (and mailing list issue)
Brett Gilio writes: > I am sending this email on behalf of a friend trying to install the Guix > binary using the shell script. It appears his email is being rejected as > "inappropriate by the moderator." for some unknown reason. I think it > might be a spam-filter mechanism against his @gmail.com mailing address, > but that is just a suspicion. No, there’s no filter against gmail addresses. Messages by new senders are always graylisted at first. They eventually do make their way to the mailing list. -- Ricardo
Re: Public key (and mailing list issue)
Hi Brett, hi devels Brett Gilio writes: [...] > Upon investigation of the key server it seems that Ludo's key is > missing. i searched for it four times in 5 minutes and it worked three times, failing twice with "No data"; anyway it seems to me that search is always very slow this issue has been reported to GnuPG https://dev.gnupg.org/T4163 but AFAIU thers is nothing they can do, nor Guix maintainers ...but: I've switched to hkps://hkps.pool.sks-keyservers.net [1] as my default pool and now lookups are _very_ fast should we change the proposed command line to fetch the key in the installation script and in the "Binary installation" section of the manual? something like gpg --keyserver hkps://hkps.pool.sks-keyservers.net --search-keys 3CE464558A84FDC69DB40CFB090B11993D9AEBB5 AFAIU for this to work out of the box users need a 2.1.11 and above gnupg version, otherwise they should follow the instructions found here: https://sks-keyservers.net/overview-of-pools.php#pool_hkps pointers to official GnuPG manual/howto on how to set hkps pools? WDYT? if there is enough consensus I can send a pathcset Ciao Giovanni [...] [1] "keyserver hkps://hkps.pool.sks-keyservers.net" in my .gnupg/gpg.conf -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: Packaging CDEmu and VHBA kernel module
Pierre Neidhardt writes: > - Where to store the kernel module? I'm not sure what the best way to build and use this will be. FWIW, I found these prior discussions. Maybe they'll be useful: https://lists.gnu.org/archive/html/guix-devel/2016-07/msg01457.html https://lists.gnu.org/archive/html/guix-devel/2018-02/msg00446.html https://lists.gnu.org/archive/html/guix-devel/2017-12/msg00221.html I think you might need to build a custom linux-libre kernel. You also might need to fiddle with base-initrd or raw-initrd procedures to load your module in the initrd. See "(guix) Initial RAM Disk" for details. Hopefully somebody else can give better guidance here. > - VHBA's documentation recommends setting up some Udev rule. Does it > mean that it's up to the user to configure those rules so that they > have access to VHBA and thus CDEmu? Basically, I think the answer is "yes, the user has to do it." That's not a great user experience, though. The best way right now to install udev rules is either to manually add custom udev rules (see: (guix) Base Services) in your operating system declaration, or manually add a service in your operating system declaration that extends the udev-service-type (such a service should add the right udev rules for you). If you're defining a new system service, you can extend the udev-service-type. That way, anybody who uses your service will automatically get the right rules. However, I'm not sure that what you are doing can be modeled as a system service. You're adding a kernel module, which is not accomplished by adding a system service. Maybe there's a better way that I don't know about. If so, I'd like to know! -- Chris signature.asc Description: PGP signature
Re: Guix-HPC activity report
Ludovic— On 12 Feb 14:51 Ludovic Courtès wrote: > We have just published an activity report of Guix-HPC for the past 18 > months: > > > https://guix-hpc.bordeaux.inria.fr/blog/2019/02/guix-hpc-activity-report-2018/ > > As you may know, some of us are involved at work with Guix in a > scientific context. Guix-HPC is about bringing reproducible software > deployment to high-performance computing (HPC) and scientific workflows. This is awesome! I read the report with great attention. Some typos (from the pdf I downloaded two days ago): + footnote 8: https://softwareheritage.org → https://www.softwareheritage.org + page 18: becomming → becoming + page 17 (bottom): worflows → workflows. —Marco
Re: It's time to build "guix deploy"
Hi swedebugia! swedebugia writes: [...] > I understand most parts of it ;) > It is a real beauty and a testiment to the power of Guix and Guile. [...] >> IMHO your remote host configuration technique deserves a dedicated >> blog >> article... but I've already asked too much :-) > > Good idea! given you understand most part of it, why don't you try to write an exegesis of that code yourself ;-) Thanks! Giovanni -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: Guix Emacs: use XRandr rather than Gdk?
Sounds like a good clue, please go ahead :) -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: New topic: packaging
Hello, > Then it would involve the whole things: > > * git clone ... > * go into guix directory > * Enter the environment: > guix environment guix > --> Explain what happens here and what's so cool about it. > * ./bootstrap > * ./configure --localstatedir=/var > * make > * Then the import begins: > * ./pre-inst-env guix import ... > * [hack file, using emacs, maybe ./pre-inst guix edit new-package] > * ./pre-iinst-env guix build new-package > * Check: > ./pre-inst-env guix lint new-package > * Finally: > Commit, take care of the correct commit messsages > * git format-patch and maybe git send-email Yes, I agree to this outline. One possibility if it turns out to be too much for a single video, is to spilt it up. Like: 1. building guix from source: > * git clone ... > * go into guix directory > * Enter the environment: > guix environment guix > --> Explain what happens here and what's so cool about it. > * ./bootstrap > * ./configure --localstatedir=/var > * make 2. creating your package: > * Then the import begins: > * ./pre-inst-env guix import ... > * [hack file, using emacs, maybe ./pre-inst guix edit new-package] > * ./pre-iinst-env guix build new-package 3. checks: guix lint guix size guix build --rounds=2 guix refresh -l (when updating instead of adding) 4. follow up activities: creating the patch sending the patch following it on the issue tracker incorporating feedback and resending... WDYT? In these series we could reference the other parts. I would perfer to keep as few parts as possible, but this is one way to split and organize it. Best regards, g_bor
Re: New topic: asking for help
Hello, > * First entry maybe is the homepage as such. > * Then show the documentation [or: are we here already assuming that > someone found that?]. > * Then mailing list (dev/help). > * IRC channel is also quite a help, I would mention that too. > * There is the debbugs bug tracker > (https://debbugs.gnu.org/cgi/pkgreport.cgi?pkg=guix) where you could > search for problems. It is maybe not the most obvious interface and > explaining it a bit would be nice. > This ordering looks fine to me. I would add some emphasis to finding the documentation and the contact page on the website, but that might be obvious. I would spilt up showing documentation, and first refer to the location with the other videos, then to the manual, the rationale being is that someone who is already watching a documentation video might be more interested in documentation videos in the first place. I guess I would skip the dev list here. I feel it would result in better distribution of messages. If the question seems to be dev related, the either we can redirect the thread to dev, and most devs will come across the list of mailing lists on the contact page, and post there in the first place, so I guess this would not cause any real concern. I also believe that the IRC channel is quite important. On thing to consider here is to mention the things related to nickname registration and logging in. It is unfortunate that we were forced to making registration required, but this is how things are right now. We might also propose the mumi as the primary issue tracking interface, and mention debbugs in case more advanced stuff is needed. No strong opinion here. Best regards, g_bor
Re: New topic: packaging
Hi! was planning to add my point of view a little later, after finishing my draft of everyday use, which I am also finding that only with concepts and showing the basic commands lasts three minutes up to now, and I still have a lot to show/mention. > Yes, I agree to this outline. One possibility if it turns out to be > too much for a single video, is to spilt it up. I agree, it is a LOT for a single video, but don't you think we are kind of turning the whole documentation into videos? I don't mind making as many videos as possible, but I am getting that sense. Specially if a 5 min video is too long. That is why I thought of packaging an R package, explaining maybe what "each line of the package" means, and then people can read the documentation to create their owns. But again, I don't mind. I create the videos that you find more useful. > 4. follow up activities: > creating the patch > sending the patch > following it on the issue tracker > incorporating feedback and resending... > WDYT? This could be included in the R package video.
Re: Guix-HPC activity report
Hello, Marco van Hulten skribis: > On 12 Feb 14:51 Ludovic Courtès wrote: >> We have just published an activity report of Guix-HPC for the past 18 >> months: >> >> >> https://guix-hpc.bordeaux.inria.fr/blog/2019/02/guix-hpc-activity-report-2018/ >> >> As you may know, some of us are involved at work with Guix in a >> scientific context. Guix-HPC is about bringing reproducible software >> deployment to high-performance computing (HPC) and scientific workflows. > > This is awesome! I read the report with great attention. Thank you. > Some typos (from the pdf I downloaded two days ago): Oops, fixed! Ludo’.
Re: Packaging FreeCAD
Hello Guix, I have some small updates and asking for help on freecad (I’m working from my channel github.com/jsoo1/guix-channel). I have been getting a little stuck building the pyside2 dependencies. It seems like freecad is moving from the pyside1 tools (Shiboken and pyside) to pyside2 for the 0.18 release (see https://wiki.qt.io/Qt_for_Python). These packages have a custom setup.py that I could use a hand porting to a guix package. As far as I understand, building upside would complete all the required third party packages listed on the freecad wiki: https://www.freecadweb.org/wiki/Third_Party_Libraries. - John > On Jan 14, 2019, at 4:42 AM, Paul Garlick > wrote: > > Hi John, > >> I did not know Debian changed their version of opencascade > > There are two versions of OpenCASCADE in Debian, named 'liboce' and > 'libocct'. 'occt' is the upstream variant, 'oce' is the community > maintained variant. Historically, Debian has switched between the two > as licence requirements dictated. > > Currently, both are packaged and FreeCAD version 0.17 depends on > liboce. However, libocct is being more actively maintained and I > believe the intention for Debian FreeCAD version 0.18 is for the > dependency to switch to libocct. > > Best regards, > > Paul. >
Re: Guix-HPC activity report
Hi, I have quickly given a look at some pointer. For example, some presentations at the EasyBuild meetup. There are slides with not so nice figures, e.g., p45 of [1] about FFTW. I remember similar number in other easybuild presentation. In the Guix FFTW package definition, there is a comment about AVX. Well, is it still accurate ? Is Guix binary still slower than other ? [1] https://users.ugent.be/~kehoste/eum18/eum18_easybuild_past_present_future_20180130.pdf Thank you in advance for any pointer. All the best, simon
Re: It's time to build "guix deploy"
Hello Pjotr, thanks for sharing your thougts! Pjotr Prins writes: [...] > I am still using that setup today, to configure web, mail > servers and home directory. The tool is here > > https://github.com/pjotrp/deploy quiting from the README: "`deploy’ is a deployment tool which operates in the same domain as Chef, Puppet, Cfengine" I'd call them "configuration management tools" instead of "deployment tools", even if someway (*badly*) they can also deploy software and apply the configuration why not using (or defining [1]) system services in a Guix operating-system declaration instead of *any* other configuration management software?... except for legacy reasons the very reason I'm here is I don't want to use *anymore* *any* of them, with all due _respect_ for the venerable projects, your included! I've used Puppet and some Ansible, studied CFengine and Salt Stack... then discovered Nix and rigth next Guix: what else? :-) [...] > and the emacs files sit in a git directory in the same tree and get > copied across running 'deploy emacs.yaml'. yes, we still miss "stateless user services config" (Pierre Neidhardt wrote an interesting summary here https://lists.gnu.org/archive/html/guix-devel/2019-02/msg00128.html) I'd like to be able to declaratively manage a *stateless* .config/ instead of managing configuration with dotfiles [2] anyway Guix is _perfect_ to declare and deploy system services, what we miss is a little more abstraction (from operating-system to infrastructure?) and remote control of "guix system reconfigure" am I missing something? Thanks Giovanni [1] https://www.gnu.org/software/guix/manual/en/html_node/Defining-Services.html#Defining-Services [2] I'm using myrepos with "stowable = true" for my dotfolders... but I'll _never_ use something like it's Drupal extension -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
manage /boot/grub/grub.cfg without installing grub binaries to disk
Hi Jack and Raghav, Could you try this? --8<---cut here---start->8--- (bootloader-configuration (bootloader (bootloader (inherit grub-bootloader) (installer #~(const #t) --8<---cut here---end--->8--- Clément
Re: Rust 1.19 fails to build on i686 on ‘staging’
Hi Chris, On Wed, 13 Feb 2019 20:35:51 -0800 Chris Marusich wrote: > My understanding is that "term-signal: 8" means the process (rustc) was > terminated by signal 8 (SIGFPE on my system according to "kill -l"). Is > that right? According to upstream [1], it might be SIGABRT, but I see your reasoning. > I looked in the failed build directory, but I couldn't find a core > dump. When I manually ran the command... > > /gnu/store/jxq[...]-mrustc-0.8.0/bin/mrustc src/tools/cargo/src/bin/cargo.rs > [...] > > ...it actually succeeded. Does that mean in an i686-linux guix environment? If so, that's very good to know and it could be a good workaround to keep going! Did you source the environment-variables, too? [1] https://github.com/thepowersgang/mrustc/issues/78#issuecomment-416073674 pgpTWTXZP6MQg.pgp Description: OpenPGP digital signature
problem with dockerd service
Hi! I'm trying to create a VM with a dockerd service installed I'm using the same configuration as the one used in this bug #34333 http://issues.guix.info/issue/34333 except I removed gfs package gnome and desktop services I get this error: --8<---cut here---start->8--- $ guix system vm ../labs/configuration/docker-test.scm -r docker-test guix system: error: service 'dockerd' requires 'file-system-/sys/fs/cgroup/blkio', which is not provided by any service --8<---cut here---end--->8--- it this related to bug #34333 or it's a different issue? Thanks! Giovanni -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: It's time to build "guix deploy"
On Thu, Feb 14, 2019 at 04:35:47PM +0100, Giovanni Biscuolo wrote: > the very reason I'm here is I don't want to use *anymore* *any* of them, > with all due _respect_ for the venerable projects, your included! I did not intend to push my 'solution'. I want to get away from that too! > I've used Puppet and some Ansible, studied CFengine and Salt > Stack... then discovered Nix and rigth next Guix: what else? :-) > > [...] > > > and the emacs files sit in a git directory in the same tree and get > > copied across running 'deploy emacs.yaml'. > > yes, we still miss "stateless user services config" (Pierre Neidhardt > wrote an interesting summary here > https://lists.gnu.org/archive/html/guix-devel/2019-02/msg00128.html) > > I'd like to be able to declaratively manage a *stateless* .config/ > instead of managing configuration with dotfiles [2] > > anyway Guix is _perfect_ to declare and deploy system services, what we > miss is a little more abstraction (from operating-system to > infrastructure?) and remote control of "guix system reconfigure" > > am I missing something? I think you misread my E-mail. No doubt my fault ;). Pj.
Re: problem with dockerd service
Hi Giovanni, On Thu, 14 Feb 2019 18:27:03 +0100 Giovanni Biscuolo wrote: > I'm trying to create a VM with a dockerd service installed > > I'm using the same configuration as the one used in this bug #34333 > http://issues.guix.info/issue/34333 > except I removed gfs package gnome and desktop services > > I get this error: > --8<---cut here---start->8--- > $ guix system vm ../labs/configuration/docker-test.scm -r docker-test > guix system: error: service 'dockerd' requires > 'file-system-/sys/fs/cgroup/blkio', which is not provided by any service > --8<---cut here---end--->8--- > > it this related to bug #34333 or it's a different issue? It's a different issue. docker requires elogind. I wonder why it doesn't complain about 'elogind' missing, though. Please add elogind to your service definition. If it's already there, that's weird, because elogind provides %control-groups, which includes 'file-system-/sys/fs/cgroup/blkio'. pgpiRl6r4X3tz.pgp Description: OpenPGP digital signature
Re: manage /boot/grub/grub.cfg without installing grub binaries to disk
Hi Clement! > > Thanks! Will do. > > @Jack. Can you also try this and let me know. My system is running dd command > for 2TB HDD. So gonna take a while. > > Thanks! Original Message On 14 Feb 2019, 12:15, Clément Lassieur wrote: > Hi Jack and Raghav, > > Could you try this? > > --8<---cut here---start->8--- > (bootloader-configuration > (bootloader > (bootloader > (inherit grub-bootloader) > (installer #~(const #t) > --8<---cut here---end--->8--- > > Clément publickey - raghavgururajan@protonmail.ch - 0xE1982130.asc Description: application/pgp-keys
Re: Tracking and inspecting how Guix changes over time
Ricardo Wurmus writes: > Christopher Baines writes: > >>> For an automated system like this, it’s a bit different, so using a >>> container makes a lot of sense. I’d suggest having an option directly >>> in (guix inferior) to allow users to choose whether to run an inferior >>> in separate name spaces. WDYT? >> >> That sounds great, I'm not quite sure how to make it happen though... >> >> So inferior-pipe in (guix inferior) uses open-pipe*. The root of the >> Linux container code in Guix looks to be run-container (gnu build >> linux-container). > > You can use “call-with-container”, which runs a thunk inside a container. I did see that, but I'm unsure how it would be applicable. What would the thunk do? In trying to isolate the inferior Guix, the natural separation point that I've been considering is the point between the host Guix, and the inferior Guix that communicate over a pipe. Since the isolation relates to processes, it would be great if the repl process could run in a "container", while the process that started the repl remains outside of the container. As far as I see it, you could start the repl from within the thunk passed to "call-with-container", but then you've got three processes in play. The repl is running in a container, and it's connected to by the process that launched the repl after being cloned from the third initial process that called call-with-container. At this point, doing stuff with the information from the inferior Guix is a little difficult as it's all happening in the container. When then thunk ends, the only information that gets back to the remaining process is the exit status from waitpid. signature.asc Description: PGP signature
Re: New topic: asking for help
Hi! > > * First entry maybe is the homepage as such. Guix site? > > * Then show the documentation [or: are we here already assuming that > > someone found that?]. We are adding in every video the link to the full documentation in the last slide. > > * Then mailing list (dev/help). > > * IRC channel is also quite a help, I would mention that too. > > * There is the debbugs bug tracker > > (https://debbugs.gnu.org/cgi/pkgreport.cgi?pkg=guix) where you could > > search for problems. It is maybe not the most obvious interface and > > explaining it a bit would be nice. uhm but isn't the idea of the video "hi, I'm new, I am trying to use GNU Guix, how can I ask for help?" That was what I had in mind, or at least what I understood. Maybe if there is enough time, we can add it, but I feel it is kind of advanced for the video. > > > > This ordering looks fine to me. > > I would add some emphasis to finding the > documentation and the contact page on the website, but that might be obvious. I agree with this, we can show a screenshot of that part of the site :) > > I would spilt up showing documentation, and first refer to the > location with the other videos, > then to the manual, the rationale being is that someone who is already > watching a documentation > video might be more interested in documentation videos in the first place. I mentioned that the videos show at the end a slide with the link for the documentation, but does not harm adding it again. > I guess I would skip the dev list here OK, just help. is it fine taking snapshots? > I also believe that the IRC channel is quite important. On thing to > consider here is to mention the > things related to nickname registration and logging in. Here we need to show like in cli sessions or just explain it? > We might also propose the mumi as the primary issue tracking > interface, and mention debbugs in > case more advanced stuff is needed. No strong opinion here. Already mentioned my idea about debbugs. Don't know what mumi is :/ Regards :) Laura
New Danish PO file for 'guix' (version 0.16.0)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'guix' has been submitted by the Danish team of translators. The file is available at: https://translationproject.org/latest/guix/da.po (We can arrange things so that in the future such files are automatically e-mailed to you when they arrive. Ask at the address below if you want this.) All other PO files for your package are available in: https://translationproject.org/latest/guix/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: https://translationproject.org/domain/guix.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
