Re: More man page improvements

[Helge Kreutzmann]

Hello Guillem,
On Sun, May 17, 2020 at 12:59:02AM +0200, Guillem Jover wrote:
> On Fri, 2020-05-15 at 22:04:36 +0200, Helge Kreutzmann wrote:
> > On Fri, May 15, 2020 at 02:57:28PM +0200, Guillem Jover wrote:
> > > On Tue, 2020-05-12 at 19:42:02 +0200, Helge Kreutzmann wrote:
> > > > I'm workin on stable, if this matters.
> > > 
> > > Hmm, right that would not work entirely. :/ The latest po4a release
> > > changed the default for the --porefs option, and removed the old way
> > > to change that default, so code that changed the default cannot
> > > specify it in a way that is backwards compatible. This should mostly
> > > affect wrapping, so I guess I could also relax the Build-Depends, but
> > > I assume we'll get flip-flops in the .po depending on where it got
> > > updated.
> > 
> > Ok, then I run this in a sid chroot.
> 
> I've improved this now in master, and the --porefs value will be
> selected based on what is needed, so it should be safe to run it on
> stable again.

No, it does not work:
make: Entering directory '/tmp/dpkg/man'
  PO4A   update-po
 (3149 entries)
Error: 'msgmerge -U po/de.add po/dpkg-man.pot --add-location=file --previous 
--backup=none' exited with value 1.
make: *** [Makefile:893: update-po] Error 1
make: Leaving directory '/tmp/dpkg/man'

But again, I can use a sid chroot.

> > > I'm also wondering about the addenda, which I refactored to specify
> > > them only once in the config, but that only works in testing/sid. We
> > > removed references to man page authors some time ago, so was
> > > considering whether to do the same for the addenda and remove them to
> > > match the upstream part, which would also remove that problem entirely.
> > > Not sure how that would fly with translators though?
> > 
> > I would rather keep the translators, because when translation issues
> > arise they should be known as first point of contact.
> 
> Ok, that makes sense. More so because with the switch to POD, the
> copyright header (for now) does not end up in the generated man pages,
> so even checking the source would not give any such indication.
> 
> > Also translation
> > is a significant effort often overlooked so having the names there is
> > also a way to acknowledge that effort and saying "thank you". 
> 
> Oh I'm completely aware, I've done translation stuff too and I know
> it's an endless ton of work and time, so please do not take this as
> undervaluing that work!
> 
> I also think documentation is important, but personally I tend to find
> AUTHOR sections in man pages distracting (even when I'm one of them :).
> First because it's usually not clear whether this is about the
> program or the man page, then because it tends to get out of sync with
> the copyright header, and finally because it feels like details that
> if interested in can be checked in the source code.
> 
> > (And except this hopefully temporary issue the maintenance effort for
> > your side is almost zero).
> 
> Sure, it's not a big deal, and I'm fine with keeping them, so let's do
> that then.

Great, thanks.

Greetings

 Helge
-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Re: Need help installing dpkg on an aarch64 system with no build tools

[Guillem Jover]

Hi!

On Thu, 2020-05-14 at 14:54:52 -0700, Alex Ryan wrote:
> If any of you have time, would you be so kind as to advise me on how I
> should solve my problem?
> 
> Alternatively, if you could point me in the right direction, that would be
> very much appreciated.
> 
> I've posted this on stack exchange:
> 
> https://unix.stackexchange.com/questions/586695/where-can-i-get-a-tarball-of-the-debian-package-manager-for-aarch64

I've replied there in more detail, but the very short summary is that
I think this is not a great idea, and you should consider using a
Debian chroot instead.

Regards,
Guillem

Re: More man page improvements

[Guillem Jover]

On Fri, 2020-05-15 at 22:04:36 +0200, Helge Kreutzmann wrote:
> On Fri, May 15, 2020 at 02:57:28PM +0200, Guillem Jover wrote:
> > On Tue, 2020-05-12 at 19:42:02 +0200, Helge Kreutzmann wrote:
> > > I'm workin on stable, if this matters.
> > 
> > Hmm, right that would not work entirely. :/ The latest po4a release
> > changed the default for the --porefs option, and removed the old way
> > to change that default, so code that changed the default cannot
> > specify it in a way that is backwards compatible. This should mostly
> > affect wrapping, so I guess I could also relax the Build-Depends, but
> > I assume we'll get flip-flops in the .po depending on where it got
> > updated.
> 
> Ok, then I run this in a sid chroot.

I've improved this now in master, and the --porefs value will be
selected based on what is needed, so it should be safe to run it on
stable again.

You'll not get addenda in translations in stable though, but it should
otherwise be fine for testing that the .po files are good, and
translated man pages build. So feel free to keep working in a stable
system if you want, and please let me know of similar regressions in
the future.

> > I'm also wondering about the addenda, which I refactored to specify
> > them only once in the config, but that only works in testing/sid. We
> > removed references to man page authors some time ago, so was
> > considering whether to do the same for the addenda and remove them to
> > match the upstream part, which would also remove that problem entirely.
> > Not sure how that would fly with translators though?
> 
> I would rather keep the translators, because when translation issues
> arise they should be known as first point of contact.

Ok, that makes sense. More so because with the switch to POD, the
copyright header (for now) does not end up in the generated man pages,
so even checking the source would not give any such indication.

> Also translation
> is a significant effort often overlooked so having the names there is
> also a way to acknowledge that effort and saying "thank you". 

Oh I'm completely aware, I've done translation stuff too and I know
it's an endless ton of work and time, so please do not take this as
undervaluing that work!

I also think documentation is important, but personally I tend to find
AUTHOR sections in man pages distracting (even when I'm one of them :).
First because it's usually not clear whether this is about the
program or the man page, then because it tends to get out of sync with
the copyright header, and finally because it feels like details that
if interested in can be checked in the source code.

> (And except this hopefully temporary issue the maintenance effort for
> your side is almost zero).

Sure, it's not a big deal, and I'm fine with keeping them, so let's do
that then.

Thanks,
Guillem

Re: [PATCH] i18n.c: add dependency on xlocale.h for DarwinBSD

[Guillem Jover]

Hi!

On Wed, 2020-05-13 at 18:11:00 +, Sirio Balmelli wrote:
> Subject: [PATCH] i18n.c: add dependency on xlocale.h for DarwinBSD

> Fixes build failures starting with:
> 
> i18n.c:27:8: error: unknown type name 'locale_t'
> 
> Signed-off-by: Sirio Balmelli 

Thanks for the report and patch! I've fixed this instead by checking
for the availability of the header:

  

Regards,
Guillem

RE: [PATCH] i18n.c: add dependency on xlocale.h for DarwinBSD

[Sirio Balmelli]

Hello :)

I am the author of this patch; submitted it to the mailing list kernel-style to 
see what would happen.

In my workflow I use dpkg on Darwin (macOS), through the Nix package manager.

Building dpkg 1.20 borked with this message about internationalization, so I 
submitted this patch which fixes the issue on Darwin.

The corresponding git commit for this patch is here: 
https://github.com/siriobalmelli-foss/dpkg/commit/afca7b4ae1db7926698f7a5ff47ce0f03f42c663

FYI the patch has also been submitted for inclusion into nixpkgs so that 
downstream is ok while I work to get this fixed upstream: 
https://github.com/NixOS/nixpkgs/pull/87755


So ... am I presenting this right for inclusion into dpkg upstream?

Thank you, and any feedback is welcome :)

best,

Sirio

‐‐‐ Original Message ‐‐‐
On Saturday, May 16, 2020 2:47 AM, Don Gould  wrote:

> Why does my temp gauge have this language message in it?  ;)
>
> Thanks for the help guys.
>
> D
>
> --
> Don Gould
> 5 Cargill Place
> Richmond
> Christchurch, New Zealand
> Mobile/Telegram: + 64 21 114 0699
> www.bowenvale.co.nz
>
>  Original message 
> From: Sirio Balmelli 
> Date: 16/05/20 4:13 am (GMT+12:00)
> To: debian-dpkg@lists.debian.org
> Subject: [PATCH] i18n.c: add dependency on xlocale.h for DarwinBSD
>
> >From afca7b4ae1db7926698f7a5ff47ce0f03f42c663 Mon Sep 17 00:00:00 2001
> From: Sirio Balmelli 
> Date: Wed, 13 May 2020 20:02:48 +0200
> Subject: [PATCH] i18n.c: add dependency on xlocale.h for DarwinBSD
> To: debian-dpkg@lists.debian.org
>
> Fixes build failures starting with:
>
>     i18n.c:27:8: error: unknown type name 'locale_t'
>
> Signed-off-by: Sirio Balmelli 
> ---
> lib/dpkg/i18n.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/lib/dpkg/i18n.c b/lib/dpkg/i18n.c
> index 495270003..d98392783 100644
> --- a/lib/dpkg/i18n.c
> +++ b/lib/dpkg/i18n.c
> @@ -24,6 +24,9 @@
> #include 
>
> #ifdef HAVE_USELOCALE
> +#if __APPLE__
> +#include 
> +#endif
> static locale_t dpkg_C_locale;
> #endif
>
> --
> 2.26.2