Tags: l10n patch
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
* What was the outcome of this action?
* What outcome did you expect instead?
*** End of the template - remove these template lines ***
Russian debconf templates translation update is attached.
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.16.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
ledgersmb_1.5.21+ds-2_source.changes uploaded successfully to localhost
along with the files:
Your Debian queue daemon (running on host usper.debian.org)
On Fri, Aug 10, 2018 at 82:09 PM Adriano Rafael Gomes <adrianorg(a)debian.org>
> Please, Could you update the Brazilian Portuguese Translation?
This is to advise that I have imported the new version of the pt_BR.po file
into the package git repository and the update will be included with the
next package release. Thanks!
Robert James Clay, jame(a)rocasa.us
On Thu, Aug 2, 2018 at 1:58 PM Shengjing Zhu <i(a)zhsj.me> wrote:
> Not about repack, current watch file will download tarball that github
> generated, not the one upstream uploading to github release. Look at
> https://github.com/ledgersmb/LedgerSMB/releases, please be careful
> that there're two kinds of tarball. Don't look at
> https://github.com/ledgersmb/LedgerSMB/tags, which doesn't have asc
If that were entirely true then where does the, in this case,
downloaded file ledgersmb-1.5.21.tar.gz.asc from? I'd always thought that
resulted from the GitHub pgpsigurlmangle entry, which does point to the
'releases'. And if the final URL is pointed to the 'releases' also, it fails
because it can't find the *.asc file as it's looking for the wrong file name
and ends up not downloading anything. That's why it confused me; the form
of watch I ended up using at least downloaded files but still failed due to
the apparently bad downloaded archive.
> And I think using upstream http release page is much simpler for you.
I'm inclined to agree and will look at using that site instead.
Robert James Clay
The upstream for the ledgersmb package  moved from Sourceforge to GitHub
including for where new releases of the application are made available; so
the debian/watch file in the package needed to be`updated for the new
locations of the distribution archive and its detached`gpg file that is used
for verification. Updating the watch file  so that uscan can see new
releases was successful but the *.asc file associated with the new releases
and used for the gpg verification does not seem to get referenced properly so
the verification step fails. (Or the verify is happening after the repack for
some reason but before renaming the archive? It's not clear...) Since the
verify step is failing, the step for doing the repack of the archive does not
happen. Manually downloading then verifying the archive can be done
successfully although then repacking the upstream archive also has to done
manually. The download, verify, and repacking was successful at the time
when the watch file was pointing to the old SourceForge site.
Running, for instance, the command "uscan --force-download --verbose --rename
--destdir .." results in the error "BAD signature". And indeed, checking
the resulting files from that command finds that the archive does look to
have been repacked (it's smaller) and so the verify fails.
The current upstream version in Debian is 1.5.21 but 1.6.3 has been
released; I'll be working on upgrading the packaging for the new series.
I'd appreciate if the current version of the debain/watch file be reviewed
and advice given about how it could be updated to work properly. Besides the
new releases being available at github (via their tags), they are also
available at a separate upstream site ; I wonder if it would be better
to try using that?
Robert James Clay, jame(a)rocasa.us, rjclay(a)gmail.com