This bug was fixed in the package pkgbinarymangler - 138.18.04.1
---
pkgbinarymangler (138.18.04.1) bionic-proposed; urgency=medium
[ Gunnar Hjalmarsson ]
* dh_translations:
- Prevent domain confusion for Meson packages when a help-* domain
is present (LP: #1762889).
Verified the test case using dh-translations 138.18.04.1 from bionic-
proposed.
** Description changed:
[Impact]
With version 136 of the dh-translations package, support for the Meson
build system was added. While that change is sufficient for making
dh_translations run successfully fo
Hello Jeremy, or anyone else affected,
Accepted pkgbinarymangler into bionic-proposed. The package will build
now and be available at
https://launchpad.net/ubuntu/+source/pkgbinarymangler/138.18.04.1 in a
few hours, and then in the -proposed repository.
Please help us by testing this new package.
** Changed in: pkgbinarymangler (Ubuntu Bionic)
Status: Incomplete => Triaged
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1762889
Title:
dh_translations doesn't strip .desktop files when mo
Packages like firefox and thunderbird still use cdbs in Ubuntu (those 2
use dh in Debian) and don't directly include gnome.mk but still get
their translations stripped for language packs.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Oh, I see that gnome.mk is provided directly by cdbs so we'll need to do
more investigation to figure out which cdbs-using packages use gnome.mk.
There are 67 packages in main using cdbs and around 2380 in total using
cdbs. The vast majority of those wouldn't be using Ubuntu language packs
but I do
The only packages in main that I am aware of that use cdbs and dh-
translations are these: (These use dh-translations via gnome-pkg-tools.
I've been keeping track because once these are converted to dh, we can
drop part of our diff from Debian in the cdbs packaging.):
* gst-plugins-base1.0
* gst-p
I guess dh_translations was written by Martin long before dh(1) came in,
and that's why it had its own euristic to determine the current build
system. This has never been revisited because the maintainance on this
package is low.
I agree though that it should have both systems:
- one for dh(1) pac
Hi Steve,
Since I'm the formal uploader of this SRU proposal, I'd better say
something, even if I think that e.g. Laney and Didier are better
prepared to comment on the approach.
For several cycles dh_translations has used its own, pretty simplistic,
heuristic to detemine both the gettext domain
I am concerned about the implementation in the package in the queue,
which is applying its own heuristics to determine which build system
should be used. Why is this not leveraging the debhelper Buildsystem
module, which would ensure dh_translations would be consistent with
dh(1) - and, in particu
** Description changed:
[Impact]
With version 136 of the dh-translations package, support for the Meson
build system was added. While that change is sufficient for making
dh_translations run successfully for some Meson packages, it's not
sufficient for packages with multiple gettext d
Gunnar pointed out to me that this would be a good case for the --domain
option that was added. If my proposal upstream is rejected, I'll use the
--domain option for Ubuntu's polari package.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubun
Gunnar, this fix assumes that the translation templates will match each
other and will match the meson project id.
polari 3.30.1's project id is 'polari'. Its 2 pot targets are polari-pot
and help-org.gnome.Polari-pot.
The project id needs to be 'polari' since that determines the tarball
name whe
** Also affects: pkgbinarymangler (Ubuntu Bionic)
Importance: Undecided
Status: New
** Changed in: pkgbinarymangler (Ubuntu Bionic)
Status: New => Triaged
** Changed in: pkgbinarymangler (Ubuntu Bionic)
Importance: Undecided => Medium
--
You received this bug notification be
** Patch added: "pkgbinarymangler_lp1762889_bionic.debdiff"
https://bugs.launchpad.net/ubuntu/+source/pkgbinarymangler/+bug/1762889/+attachment/5143361/+files/pkgbinarymangler_lp1762889_bionic.debdiff
** Description changed:
+ [Impact]
+
+ With version 136 of the dh-translations package, sup
This bug was fixed in the package pkgbinarymangler - 139
---
pkgbinarymangler (139) cosmic; urgency=medium
* dh_translations:
- Prevent domain confusion for Meson packages when a help-* domain
is present (LP: #1762889).
- Don't build help-*.pot. Those templates are use
I've uploaded that now, thanks. Please keep a close eye on Cosmic
uploads to watch out for any issues.
** Changed in: pkgbinarymangler (Ubuntu)
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu
Added the last(?) patch, with the following changes:
* Dropped the code for building help-* templates in accordance with the
above discussion, and clarified this in the docs.
* Changed the --domain option for non-Meson packages to be an override
instead of fallback. The issue reported in bug #176
Documenting the reasons makes sense. If it is to be documented in the
dh_translations man page, I suppose we should drop the code snippet I
included in comment #12 to be consistent.
@Laney, @Sebastien: Any thoughts on this?
--
You received this bug notification because you are a member of Ubuntu
I guess I don't have a big problem with it, but we should probably
document why we are discarding the help-* domains.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1762889
Title:
dh_translations doe
On 2018-04-14 14:22, Jeremy Bicha wrote:
> It sounds like you're saying that if any translator wants translated
> help for GNOME apps, they need to do that in GNOME directly.
Yes. That's what I already (since 17.10) have told the translators as
regards gnome-user-docs, and I think it would be cons
It sounds like you're saying that if any translator wants translated
help for GNOME apps, they need to do that in GNOME directly. Therefore,
why bother building the help pot files since we're just ignoring them
anyway right now?
We don't patch the help for GNOME apps (excluding ubuntu-docs), so th
It's true that dh_translations builds a POT file for the help files in
gnome-mahjongg. It's this code in dh_translations:
# try to build help POT
if (-e 'help/Makefile') {
chdir 'help';
system ('make', 'pot');
chdir '..';
}
Can't help wondering why that code is
Big oops. I believe my suggestion in my original bug report was wrong.
I compared gnome-chess and gnome-mines (two simple games in Ubuntu
main). gnome-mahjongg in its current release still uses autotools, but
gnome-chess uses meson.
The build produces gnome-mahjongg_3.22.0-3_amd64_translations.ta
In response to Laney's comment #8, and after some clarifications on IRC,
attached please find a new attempt.
Comment #6 still applies. In addition to that, g-c-c now fails to build
if you add a value via --domain which is unknown to Meson.
As regards non-Meson packages, --domain is a fallback, i.
Okay, I'll switch to an array. I'm used to hashes, and personally find
it just as readable, but maybe not.. And efficiency is indeed not an
issue for this non-runtime code.
On 2018-04-13 10:42, Iain Lane wrote:
> OK, a slight review, it's confusing that --domain only works for
> meson; is there an
Thanks for the patch!
On Thu, Apr 12, 2018 at 05:57:01PM -, Gunnar Hjalmarsson wrote:
> @Laney: I kept using %domains instead of @domains. ;) Given these
> adjustments I think that a hash is more suitable.
Not reviewing yet, but why? If the question is just asking one time
whether a string is
@Laney: I kept using %domains instead of @domains. ;) Given these
adjustments I think that a hash is more suitable.
** Patch added: "pkgbinarymangler_lp1762889_2.debdiff"
https://bugs.launchpad.net/ubuntu/+source/pkgbinarymangler/+bug/1762889/+attachment/5112622/+files/pkgbinarymangler_lp17628
I think the attached debdiff changes dh_translations in accordance with
the above discussion.
With all the workarounds in debian/rules dropped, g-c-c fails as
expected. But with this:
override_dh_translations:
dh_translations --domain=gnome-control-center-2.0
both the POT creation and th
Thanks Laney! I think I got enough guidance to prepare a patch for this.
** Changed in: pkgbinarymangler (Ubuntu)
Importance: Undecided => Medium
** Changed in: pkgbinarymangler (Ubuntu)
Status: New => In Progress
** Changed in: pkgbinarymangler (Ubuntu)
Assignee: (unassigned) =>
On Wed, Apr 11, 2018 at 10:37:11AM -, Gunnar Hjalmarsson wrote:
> > I don't like this - it puts the information in a hard to find place
> > that's remote from the packages it refers to. I think this should be
> > in the rules file for the affected projects, maybe
> >
> > $ dh_translations --
Thanks for your review!
On 2018-04-11 10:51, Iain Lane wrote:
> Thanks for the patch. I'm of the opinion that this isn't bionic-
> critical, since these are packages which have never worked with
> dh_translations + meson, do you agree?
Not quite. To the extent packages, which dh_translations previ
Thanks for the patch. I'm of the opinion that this isn't bionic-
critical, since these are packages which have never worked with
dh_translations + meson, do you agree?
Here's my review:
+# known domains to be ignored in this context
+my %ignores = (
+'gnome-control-cen
Attached please find an idea which addresses all the packages mentioned
above.
In addition to ignoring help-* domains, it makes dh_translations ignore
a hardcoded list of known domains. In case of g-c-c we could get rid of
all the workarounds in debian/control, and libgweather would only need
to b
34 matches
Mail list logo
