Re: Racket packages / build system

[Christopher Lemmer Webber]

Dimos Dimakakos writes:

> Bonface M. K. writes:
>
>> To simply put it, AFAIU updating a package would
>> require racket to update it's references(either
>> links, and other references that I won't go into),
>> hence creating some form of "global state";
>> thereby if you use raco, every package updated
>> would lead to some update with racket's search
>> paths or dirs somewhere. Any ideas to overcome
>> this wall? (or anything I've got wrong somewhere?)
>
> This was one of the main problems that I also encountered when working
> on this. racket2nix solves this by generating a temporary environment
> (by coping most of the racket folders and the deps needed as writable
> folders) where it installs with raco and then tries to update the global
> state of racket.
>
> To be honest this solution is kinda hacky and also slow, but I couldn't
> think of another one at the time I tried to work on the issue. It's a
> reality that the racket install system is quite stateful and also many
> operations seem to try to touch files. Installing with raco for example
> will try to recompile the dependencies of the new package and other such
> examples.
>
> Anyway, I hope you can find a way to move this forward!

I wonder if it would be a good idea to copy many of the points from this
email and the parent to racket-users or racket-dev and see if someone
more familiar with the structure of the system can provide guidance from
there?

If we have to go the racket2nix route, it would be better than nothing I
guess.

Another possible route: don't use the Racket installer tooling.
Instead, read the info.rkt file of the package to understand what raco
*probably would* do, and then do it in a more Guix way instead.

What do you think of that route?

Re: branch master updated: gnu: nyxt: Update to 2-pre-release-3.

[Marius Bakke]

Marius Bakke  writes:

> Pierre Neidhardt  writes:
>
>> Can't wait for staging to merge, the Common Lisp build-system is vastly
>> improved!
>
> I've just fixed a 'totem' test failure.  Unless other regressions show
> up it should be ready for merge within a few days.  Testers wanted!

Speaking of the Common Lisp build system on 'staging', the newly-added
'sbcl-static-dispatch' fails to build when merged or cherry-picked.

Can you look into it?


signature.asc
Description: PGP signature

Re: Racket packages / build system

[Dimos Dimakakos]

Bonface M. K. writes:

> To simply put it, AFAIU updating a package would
> require racket to update it's references(either
> links, and other references that I won't go into),
> hence creating some form of "global state";
> thereby if you use raco, every package updated
> would lead to some update with racket's search
> paths or dirs somewhere. Any ideas to overcome
> this wall? (or anything I've got wrong somewhere?)

This was one of the main problems that I also encountered when working
on this. racket2nix solves this by generating a temporary environment
(by coping most of the racket folders and the deps needed as writable
folders) where it installs with raco and then tries to update the global
state of racket.

To be honest this solution is kinda hacky and also slow, but I couldn't
think of another one at the time I tried to work on the issue. It's a
reality that the racket install system is quite stateful and also many
operations seem to try to touch files. Installing with raco for example
will try to recompile the dependencies of the new package and other such
examples.

Anyway, I hope you can find a way to move this forward!

Guix now compiles on my Talos II

[Tobias Platen]

I checked out the wip-ppc branch which I compiled on my Talos II.

-- 
Tobias Platen 

Re: branch master updated: gnu: nyxt: Update to 2-pre-release-3.

[Marius Bakke]

Pierre Neidhardt  writes:

> I've just pushed a fix in 98a15c796afcc91894b7400b1d548cd50604db0c, so
> Nyxt should be back to its pristine defintion.

Oh my, thanks for catching that.

I did have the lparallel removal in my notes and distinctly remember
adjusting for it, but obviously messed up at some point.  At least I got
the additions right...

I'm not usually this sloppy with merges, promise!  :-)

> Can't wait for staging to merge, the Common Lisp build-system is vastly
> improved!

I've just fixed a 'totem' test failure.  Unless other regressions show
up it should be ready for merge within a few days.  Testers wanted!


signature.asc
Description: PGP signature

Re: Racket packages / build system

[Bonface M. K.]

Christopher Lemmer Webber 
writes:

> Bonface M. K. writes:
>

[...]

> I have the notes that Dimos wrote up not long ago in case anyone is
> interested.  Dimos, do you mind if I post them to the list?
>
>  - Chris

Hi! I've been trying to hack around the racket
build system(see attached) for some time now;
mostly using raco... The biggest problem I've
faced so far is that AFAICT, when you use raco to
install packages, racket updates some files from
where it's called(in guix's case store this is the
store where racket is in)--- and I don't think you
are allowed to do this. I've tried doing "raco
install ", and also just doing "raco
install" from inside the directory.

The command for building:

--8<---cut here---start->8---
env 
GUIX_PACKAGE_PATH="/home/bonface/projects/guix-bioinformatics:/home/bonface/projects/guix-past/modules"
 ./pre-inst-env guix build racket-hello-racket -K
--8<---cut here---end--->8---

with the error:

--8<---cut here---start->8---
starting phase `install'
make-directory: cannot make directory
  path: /homeless-shelter/
  system error: Permission denied; errno=13
  context...:
   
/gnu/store/4f148vh30qmrdl6apq1ff6yqb7kl8xlm-racket-minimal-7.8/share/racket/collects/racket/file.rkt:114:0:
 make-directory*
   [repeats 1 more time]
   
/gnu/store/4f148vh30qmrdl6apq1ff6yqb7kl8xlm-racket-minimal-7.8/share/racket/collects/pkg/private/lock.rkt:26:0:
 with-pkg-lock*
   
/gnu/store/4f148vh30qmrdl6apq1ff6yqb7kl8xlm-racket-minimal-7.8/share/racket/collects/pkg/main.rkt:216:16
   (submod 
"/gnu/store/4f148vh30qmrdl6apq1ff6yqb7kl8xlm-racket-minimal-7.8/share/racket/collects/pkg/main.rkt"
 main): [running body]
   temp35_0
   for-loop
   run-module-instance!
   for-loop
   [repeats 1 more time]
   run-module-instance!
   
"/gnu/store/4f148vh30qmrdl6apq1ff6yqb7kl8xlm-racket-minimal-7.8/share/racket/collects/raco/raco.rkt":
 [running body]
   temp35_0
   for-loop
   run-module-instance!
   
"/gnu/store/4f148vh30qmrdl6apq1ff6yqb7kl8xlm-racket-minimal-7.8/share/racket/collects/raco/main.rkt":
 [running body]
   ...
Inferred package name from given `--clone' path
  package: source
  given path: /tmp/guix-build-racket-hello-racket-0.0.1.drv-0/source
command "raco" "pkg" "install" "--no-cache" "--no-setup" "--ignore-checksums" 
"--clone" "/tmp/guix-build-racket-hello-racket-0.0.1.drv-0/source" failed with 
status 1
builder for 
`/gnu/store/filph2d8m7k1rq6rpglwx1y082ris6g0-racket-hello-racket-0.0.1.drv' 
failed with exit code 1
build of 
/gnu/store/filph2d8m7k1rq6rpglwx1y082ris6g0-racket-hello-racket-0.0.1.drv failed
View build log at 
'/var/log/guix/drvs/fi/lph2d8m7k1rq6rpglwx1y082ris6g0-racket-hello-racket-0.0.1.drv.bz2'.
guix build: error: build of 
`/gnu/store/filph2d8m7k1rq6rpglwx1y082ris6g0-racket-hello-racket-0.0.1.drv' 
failed

--8<---cut here---end--->8---

And when troubleshooting:

--8<---cut here---start->8---
cd /tmp/guix-build-racket-hello-racket-0.0.1.drv-0

/home/bonface/guix/pre-inst-env guix environment \
--no-grafts -C racket-hello-racket --ad-hoc strace gdb

source ./environment-variables

$GUIX_ENVIRONMENT/bin/raco pkg install --no-cache \
--no-setup --ignore-checksums

--8<---cut here---end--->8---

Which works just fine since I'm updating files
inside $GUIX_ENVIRONMENT. Right now I'm looking
for ideas to experiment with to try to overcome
this, and the low hanging fruit is to successfully
build a hello-racket package with zero deps and no
tests.

To simply put it, AFAIU updating a package would
require racket to update it's references(either
links, and other references that I won't go into),
hence creating some form of "global state";
thereby if you use raco, every package updated
would lead to some update with racket's search
paths or dirs somewhere. Any ideas to overcome
this wall? (or anything I've got wrong somewhere?)


;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2020 Bonface Munyoki Kilyungi 
;;;
;;; This file is part of GNU Guix.
;;;
;;; GNU Guix is free software; you can redistribute it and/or modify it
;;; under the terms of the GNU General Public License as published by
;;; the Free Software Foundation; either version 3 of the License, or (at
;;; your option) any later version.
;;;
;;; GNU Guix is distributed in the hope that it will be useful, but
;;; WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;;; GNU General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License
;;; along with GNU Guix.  If not, see .

(define-module (guix build racket-build-system)
  #:use-module ((guix build gnu-build-system) #:prefix gnu:)
  #:use-module (guix build union)
  #:use-module (guix build u

Re: [PATCH] gnu: oath-toolkit: Update to 2.6.3.

[Leo Famulari]

On Mon, Nov 09, 2020 at 02:18:21PM +0100, Simon Josefsson via Development of 
GNU Guix and the GNU System distribution. wrote:
> * gnu/packages/authentication.scm (oath-toolkit): Update to 2.6.3.  Drop 
> patch.

Thanks!

> -   (patches
> -(append (search-patches "oath-toolkit-glibc-compat.patch")
> -(list (origin
> -;; This huge commit updates gnulib for GCC 7 
> compatibility.
> -(method url-fetch)
> -(uri (string-append
> -  
> "https://gitlab.com/oath-toolkit/oath-toolkit/commit/";
> -  
> "2fffce2a471f74a585939c84cce16ef3015e5d3d.diff"))
> -(file-name "oath-toolkit-update-gnulib.patch")
> -(sha256
> - (base32
> -  
> "088c9s4ay1b54bjqc4mwfs5l3f6357zj5vpw771zlq5g4addd4s0"))

I notice that the commit message says "Drop patch", but that this change
actually removes two patches from the oath-toolkit.

It removes the application of both "oath-toolkit-glibc-compat.patch" and
also the "oath-toolkit-update-gnulib.patch". Is that intended?

If so, we should also delete the former's patch file and remove it from
'gnu/local.mk'.

Strange ld error when building libring (Jami daemon) help needed

[Jan Wielkiewicz]

Hello everyone,

I'm still trying to update Jami to "Together", fixed some errors
already with the help from upstream, but I get the strange error nor me
nor Sébastien (Jami developer) knows the reason of.
See my last message in this issue:
https://git.jami.net/savoirfairelinux/jami-packaging/issues/83
For some reason OpenDHT can't be linked with libring.
I'm open to your ideas and suggestions, because currently I have none.
I did some work already, but my git history is a mess. I can send my
current work, if you need it - I mostly updated dependencies, fixed the
patching procedure (whitespace errors) and that's basically it.

Stay warm (or cool on the southern hemisphere),
Jan Wielkiewicz

Re: Questions regarding Python packaging

[Hartmut Goebel]

Hi,

seems like another messages of mine, regarding the first thread  about a 
poetry build system, did not make it to the list.


Am 08.11.20 um 15:27 schrieb Tanguy Le Carrour:

I've just learned, by accident (working on `python-keyring` [1]), that
`python setup.py install` was somehow deprecated


This statement is not exactly true - well, depending on interpretation 
of "somehow". I've not set seen an official deprecation.


It's true that users are encouraged to use pip for installing packages. 
But the official Python Packaging Tutorial [1] is still based on 
setuptools (not even recommending a setup.cfg file). Thus setuptools 
will be around for quite some more time, as will "python setup.py install".


In the future Python world, any build-tool can be specified in 
"pyproject.toml". User will then call "pip install", and pip will 
(AFAIU) call a Python function (aka entry-point) specified in that file. 
(If this file does not exist, setuptools are assumed). For our 
python-build-system, we would use "pip wheel" (for phase build) and "pip 
install" (for phase install).


So, if we switch to "pip wheel" and "pip install", different python 
build systems could share a common base, just redefining some 
dependencies (setuptools, poetry, build, ...) and some tool-dependent 
flags. Is this the direction you are working towards?


[1] https://packaging.python.org/tutorials/packaging-projects/



in favor of tools like`pep517` or `build`.


Thanks for point to these, both are new to me.

"build" sounds interesting, esp. for guix: "It is a simple build tool 
and does not perform any dependency management." This would help us 
spliting dependency management and build phase. Anyhow, it's quite new 
(half an year old) and implements a PEP 517 package builder - and PEP 
517 (defining the build system in pyproject.toml) is not yet adopted widely.


"pep517" seems o be a library used for "build". Its high-level interface 
has been deprecated in favor for "build".


I as just about to write "So, while this might be one road to go, this 
is not of much use for us yet.". Anyhow, this might be a good base for 
pep517 based packages. On the other hand: Maybe we'd better stick with 
"pip wheel" and "pip install", see above.


--
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

New French PO file for 'guix' (version 1.2.0-pre3)

[Translation Project Robot]

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 French team of translators.  The file is available at:

https://translationproject.org/latest/guix/fr.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.

[PATCH] gnu: oath-toolkit: Update to 2.6.3.

[Development of GNU Guix and the GNU System distribution.]

* gnu/packages/authentication.scm (oath-toolkit): Update to 2.6.3.  Drop patch.
---
 gnu/packages/authentication.scm | 16 ++--
 1 file changed, 2 insertions(+), 14 deletions(-)

diff --git a/gnu/packages/authentication.scm b/gnu/packages/authentication.scm
index b3ff912c8f..52ab445775 100644
--- a/gnu/packages/authentication.scm
+++ b/gnu/packages/authentication.scm
@@ -33,26 +33,14 @@
 (define-public oath-toolkit
   (package
 (name "oath-toolkit")
-(version "2.6.2")
+(version "2.6.3")
 (source
  (origin
(method url-fetch)
(uri (string-append "https://download.savannah.nongnu.org/releases/";
name "/" name "-" version ".tar.gz"))
-   (patches
-(append (search-patches "oath-toolkit-glibc-compat.patch")
-(list (origin
-;; This huge commit updates gnulib for GCC 7 
compatibility.
-(method url-fetch)
-(uri (string-append
-  
"https://gitlab.com/oath-toolkit/oath-toolkit/commit/";
-  "2fffce2a471f74a585939c84cce16ef3015e5d3d.diff"))
-(file-name "oath-toolkit-update-gnulib.patch")
-(sha256
- (base32
-  
"088c9s4ay1b54bjqc4mwfs5l3f6357zj5vpw771zlq5g4addd4s0"))
(sha256
-(base32 "182ah8vfbg0yhv6mh1b6ap944d0na6x7lpfkwkmzb6jl9gx4cd5h"
+(base32 "1cjial8njck2sd7452jcxspbi5h5fnp3n8v3wbmlw8fzqmgzvxx1"
 (build-system gnu-build-system)
 (arguments
  ;; TODO ‘--enable-pskc’ causes xmlsec-related test suite failures.
-- 
2.20.1



signature.asc
Description: PGP signature

New Spanish PO file for 'guix-packages' (version 1.2.0-pre3)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'guix-packages' has been submitted
by the Spanish team of translators.  The file is available at:

https://translationproject.org/latest/guix-packages/es.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-packages/

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-packages.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.

New Spanish PO file for 'guix-manual' (version 1.2.0-pre3)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'guix-manual' has been submitted
by the Spanish team of translators.  The file is available at:

https://translationproject.org/latest/guix-manual/es.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-manual/

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-manual.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.

New Spanish PO file for 'guix' (version 1.2.0-pre3)

[Translation Project Robot]

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 Spanish team of translators.  The file is available at:

https://translationproject.org/latest/guix/es.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.

Re: “guix pack -RR r“ fails?

[zimoun]

Hi,

On Sun, 8 Nov 2020 at 18:34, Ludovic Courtès  wrote:

> Oh right, you’d need to pick a different execution engine, most likely
> ‘fakechroot’ is the only one that works on this machine:
>
>   export GUIX_EXECUTION_ENGINE=fakechroot
>   strace -f -s 500 -o log ./bin/R

Hum?  I do not know if I am doing correctly.  The packages
fakechroot-2.9-24.5.el6_1.1.x86_64.rpm and
fakechroot-libs-2.9-24.5.el6_1.1.x86_64.rpm are installed.  And I get
as regular user:

--8<---cut here---start->8---
$ export GUIX_EXECUTION_ENGINE=fakechroot
$ strace -f -s 500 -o logg ./bin/R
fakechroot: unsupported Guix execution engine; ignoring
./bin/Rproot error: ptrace(TRACEME): Operation not permitted
proot error: 
execve("/gnu/store/nqqhaz59gdr5q6mb6mw9dd8jk133rna2-r-minimal-4.0.3/bin/R"):
Operation not permitted
proot info: possible causes:
  * the program is a script but its interpreter (eg. /bin/sh) was not found;
  * the program is an ELF but its interpreter (eg. ld-linux.so) was not found;
  * the program is a foreign binary but qemu was not specified;
  * qemu does not work correctly (if specified);
  * the loader was not found or doesn't work.
fatal error: see `proot --help`.
proot error: can't chmod '/tmp/proot-41950-9kDMBf': No such file or directory
--8<---cut here---end--->8---
However, as root, simply running ./bin/R returns:

--8<---cut here---start->8---
# ./bin/R
R: run.c:245: disallow_setgroups: Unexpected error: No such file or directory.
Abandon
[root@HEAD foo]#
R version 4.0.3 (2020-10-10) -- "Bunny-Wunnies Freak Out"
Copyright (C) 2020 The R Foundation for Statistical Computing
Platform: x86_64-unknown-linux-gnu (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

During startup - Warning messages:
1: Setting LC_CTYPE failed, using "C"
2: Setting LC_COLLATE failed, using "C"
3: Setting LC_TIME failed, using "C"
4: Setting LC_MESSAGES failed, using "C"
5: Setting LC_MONETARY failed, using "C"
6: Setting LC_PAPER failed, using "C"
7: Setting LC_MEASUREMENT failed, using "C"
>
--8<---cut here---end--->8---


All the best,
simon

Re: Fixing Zabbix db-secret-file documentation.

[Miguel Ángel Arruga Vivas]

Hi!

Tobias Geerinckx-Rice  writes:
> Miguel,
>
> Thank you, and everyone else, for all your translation efforts. I've
> translated before.  It's ruddy hard work.

You're welcome, and thank you too: we had nothing to translate if nobody
pushed changes to make Guix even more awesome than it currently is. :-)

> Miguel Ángel Arruga Vivas 写道：
>> Tobias Geerinckx-Rice  writes:
>> Just for the record, I'm glad to translate that change or whatever
>> comes
>> next, but it makes me a bit sad when that effort is reduced to a
>> number,
>
> I'm not reducing your effort to a number, quite the opposite: I meant
> that keeping the old wording ‘just because it's already been
> translated’ would be doing so.

No problem, I understood, but my point really was that it isn't a
problem because "it's already been translated" but because "it triggers
again a procedure which was already taking place".

> Nobody actually suggested that, and I'm very happy that you're both
> willing and able to translate new strings so late.  I wasn't expecting
> that.

I try to maintain the translation up to date, as I'd like to keep "info
guix.es" as close as possible to a fully translated "info guix" (quite
hard to do though, and not really an option with our current flow), so
for me it actually means just one change in my working PO file, but that
isn't usually the case for everybody.

> Let me know what needs to happen if there's still time!

I guess that pushing another tarball to TP isn't the path we're going to
take as I feel it will cause more friction on that side, but surely we
could do it, even only sending one for the manual is a possibility
there.  On the other hand, removing that phrase is an editorial change
that perhaps could be done at project level instead of at TP: querying
the translators directly how to remove the old bits from their
translation may be an option for this.  The last option (that I don't
like neither, but it isn't on my hand to take a final decision) is to
keep the release as it is: it wouldn't affect the manual shown by the
installation, but it'll be lost as soon as a pull is performed.

WDYT?

Happy hacking!
Miguel


signature.asc
Description: PGP signature

Re: Make guix-publish's URL identical to cache file name

[Peng Mei Yu]

Hello,

Ludovic Courtès writes:

>> Then a mirror site can simply pull the directory
>> /var/cache/guix/publish/nar from the Berlin server and serve this
>> directory through a static HTTP server.  There will be cache misses.
>> But guix-daemon will safely fallback to the next server in
>> substitute-urls.
>
> The simplest solution for now (I think that’s what Ricardo & co. had in
> mind) would be for you to retrieve /var/cache/guix/publish on your
> server, as is, and then run ‘guix publish’ on your sever: it will know
> where to find files.  As I wrote to Jonathan, you can/should also run
> nginx on top of that as a proxy to your local ‘guix publish’.

I am afraid having to install Guix and run 'guix publish' will be a
major obstacle for most mirror sites, especially when their maintainers
have no previous experience with Guix and have no interest in learning a
new software and do not want to pollute their server with an unknown
software and do not want to increase maintenance burden. This is the
simplest solution on our side, but a complex solution on mirror site
maintainers' side.

I guess a complex Nginx URL rewrite rule might also convert the URL into
real filename in the cache.  Can anyone familiar with Nginx explain?


--
Peng Mei Yu

New Serbian PO file for 'shepherd' (version 0.6.2-pre1)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'shepherd' has been submitted
by the Serbian team of translators.  The file is available at:

https://translationproject.org/latest/shepherd/sr.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/shepherd/

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/shepherd.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.