Bug#244215: #244215: gettext: /usr/bin/msginit reports java error (fwd)

Santiago Vila wrote: > I plan to create the Debian gettext > package using this call to the configure script: > > JAVAC=jikes-classpath ./configure --prefix=/usr --disable-csharp Looks good, yes. (Except for the --disable-csharp: do you have problems with pnet?) > By "if gcj is present, gettext w

Bug#244215: gettext: /usr/bin/msginit reports java error (fwd)

Santiago Vila wrote: > It seems that I forgot two important things: > > * Really put gnu.gettext.GetURL in the package (!). > * Run dpkg-shlibdeps on it. This explains everything. > Perhaps I was reading the PACKAGING file in verbatim mode. PACKAGING recommends to install $prefix/lib/gettext/*;

Bug#244215: gettext: /usr/bin/msginit reports java error (fwd)

Santiago Vila wrote: > Correction: gnu.gettext.GetURL does not seem to be created at all. > > I have put the build log here: > > http://people.debian.org/~sanvila/gettext/build.log.gz > > and this is the list of files installed to debian/tmp when > I do "make install DESTDIR=`pwd`/debian/tmp": > >

Bug#244215: gettext: /usr/bin/msginit reports java error (fwd)

Santiago Vila wrote: > configure:3190: checking for Java to native code compiler > configure:3213: found /usr/bin/gcj > configure:3254: gcj conftest.java --main=conftest -o conftest > gcj: libgcj.spec: No such file or directory > > Ok, libgcj.spec is in libgcj4-dev, which I will have to install as

Bug#400187: gettext: xgettext segfaults on .lisp files (fwd)

Martin Pitt wrote: > That bug has already been closed and the patch applied, so that's not > it (I just checked the package to verify this). So it must be > something else. But with this additional patch, it will work. Alternatively - since your code appears to be Scheme, not Lisp, anyway - you c

Bug#641371: xgettext -k_ hello.scm fails if block-comment are used inside a function (fwd)

e: xgettext 3")) > ;; hello.scm [modified] ends here Thank you. It is perfectly reproducible. The point is that you are using a syntax which is valid in guile-2.0 but not in guile-1.6.4 or guile-1.7.1. In these older versions, the !# had to come on a line of its own, without spaces. I'

Bug#671044: freedink: FTBFS[!linux]: too many args to install-reloc

et me know if this fixes the Freedink builds on GNU/kFreeBSD or not. 2012-05-01 Bruno Haible relocatable-prog: Enable ELF ORIGIN trick also on GNU/kFreeBSD. * m4/relocatable.m4 (gl_RELOCATABLE_BODY): Treat kFreeBSD like Linux. * build-aux/reloc-ldflags: Likewise. S

Bug#671044: install-reloc is invoked with too many arguments

Hi Sylvain, > I received the bug report below when compiling GNU FreeDink on > Debian/kFreeBSD and Debian/Hurd. > > It seems that there's an issue with install-reloc: > https://buildd.debian.org/status/fetch.php?pkg=freedink&arch=kfreebsd-amd64&ver=1.08.20120427-1&stamp=1335561117 > https://build

Bug#671257: gettext: msgfmt output format prevents multiarch migration (fwd)

Santiago Vila wrote: > I remember well the bug by Neil Williams: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468209 > > where he asked --endianness to be documented, as he was thinking about > using it in his embedded projects to override the current msgfmt default of > always creating l

Bug#858752: w_scan does not find the German DVB-T2 HD channels

Package: w-scan Version: 20141122-1 On an Ubuntu 2016.04 LTS system, with a TechnoTrend CT2-4400 TV tuner stick, I compare the results of different versions of w-scan (in Frankfurt am Main, Germany, using the command "w_scan -c DE"): 1) Version 20141122-1, included in Ubuntu, 2) Version 20161022-

Bug#859869: unhelpful completion of file name that contains equals sign and space

Package: bash-completion Version: 1:2.1-4.2ubuntu1.1 Hi, Using bash 4.3.46 (Ubuntu package version 4.3-14ubuntu1.1) and bash-completion (Ubuntu package version 1:2.1-4.2ubuntu1.1). In the current directory I have just one file: $ ls -1 vlc-record-2017-03-28-02h03m23s-dvb-t___frequency=48200

Bug#853649: gnulib intprops.h build error with gcc 7

Hi Adrian, Could you please give the complete output of "gcc --version"? Given that [1] references an URL that contains the string 'gcc7-20170126' whereas gcc 7 was released on 2017-05-02 [2], it could be that the report is about a gcc prerelease that came 3 months before the gcc 7 release. Brun

Bug#853649: gnulib intprops.h build error with gcc 7

Adrian Bunk wrote: > For reproducing and my tiny testcase I was using > gcc (Debian 7.1.0-13) 7.1.0 > from Debian unstable - that is GCC 7.2 release candidate 2 > with minimal Debian patching. OK thanks. Now about your test case: It is not valid C to try to compile just an expression. =

Bug#792687: [Reproducible-builds] Bug#792687: gettext: please support timestamps from environment

Hello, Daniel Shahaf wrote: > Putting the fix into msgfmt is an option when the .mo file needs to be > reproducible Yes, .mo files are binary files, installed on the end users' systems. Therefore we've made .mo files reproducible [1]. > but I'm facing an issue where I'd like the .pot file > gene

Bug#792687: [Reproducible-builds] Bug#792687: gettext: please support timestamps from environment

Daniel Shahaf wrote: > > it's plain text, and it's a small diff. > > This doesn't scale. (For example, in my use-case, I'm dealing with a > 5000-line unified diff full of one-line changes in date strings and C > comments and any number of other things. My goal is to get the number of > lines down

Bug#792687: [Reproducible-builds] Bug#792687: gettext: please support timestamps from environment

Santiago Vila wrote: > But so far, the non-reproducible Debian packages using gettext I've > seen fail to be reproducible because maintainers insist on > regenerating a .pot file at build time and performing msgmerge on all > the .po files with the newly generated .pot file "just in case", or > doi

Bug#457930: [bug #22095] Possibly wrong code on hppa/ia64

Update of bug #22095 (project libffcall): Status:None => Not a Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: Thank you for the

Bug#792687: [Reproducible-builds] Bug#792687: gettext: please support timestamps from environment

A bug has been opened in the Gettext bug tracker about this issue: https://savannah.gnu.org/bugs/?49654 In my opinion (as former Gettext maintainer) the fix ought to go into msgfmt, not xgettext. The gettext.diff.txt patch from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792687 is therefore

Bug#451356: [bug #22436] callback/minitests fails on x86_64

Update of bug #22436 (project libffcall): Status:None => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #4: This is a duplica

Bug#752135: git-merge-changelog: Overstates the need for .gitattributes

ent 16 years ago. But what matters are the 'git' versions in use today.) > Maybe today it is > more fashionable to use top-level .gitattributes and not bother with > per-directory files that feels like a CVS idiom. Absolutely. I'm committing this: 2024-07-02 Bru

Bug#1077059: Fwd: Bug#1077059: gettext: xgettext complains about missing charset header when using the exclude option

>From d64216aecaf15883c944539657562127b10d0e1a Mon Sep 17 00:00:00 2001 From: Bruno Haible Date: Sat, 27 Jul 2024 21:05:27 +0200 Subject: [PATCH] xgettext: PO: Fix error when a --exclude-file option is present (regression 2023-03-10). Reported by Nicolas Peugnet via Santiago Vila at <https://lists.gnu.org/a

Bug#1018950: Fwd: Bug#1018950: gettext-el: warnings when po-mode.el is compiled with GNU Emacs 28

Hello Santiago, Vincent, > Here are the details of the warnings (note that the compilation of > the other .el files does not yield any warning; this is specific > to po-mode.el): > > In toplevel form: > po-mode.el:180:2: Warning: custom-declare-variable `po-highlight-face' > docstring has wrong

Bug#1056357: general: Command line of any program invocation is limited to less than 3544 bytes

Package: general Severity: important X-Debbugs-Cc: br...@clisp.org I'm using Debian GNU/Linux on hppa, in a virtual machine emulated by QEMU 8.0.2. $ uname -srm Linux 6.3.0-2-parisc parisc In this machine, for the invocation of any program, the length of the command line (= all arguments together

Bug#1056357: general: Command line of any program invocation is limited to less than 3544 bytes

Zebediah Beck, You haven't read my bug report. Bruno

Bug#1057120: Fwd: Bug#1057120: gettext: FTBFS on amd64 in sid chroot due to failing autopoint-3 test

Santiago Vila wrote: > FAIL: autopoint-3 > = > > make[7]: warning: jobserver unavailable: using -j1. Add '+' to parent make > rule. > : error: macro names must be identifiers To analyze this error, I would add a 'set -x' command in line 2 of gettext-tools/tests/autopoint-3, and

Bug#1057120: Fwd: Bug#1057120: gettext: FTBFS on amd64 in sid chroot due to failing autopoint-3 test

Santiago Vila wrote: > The message about jobserver disappeared when I disabled parallel build. > I guess it is some kind of Makefile bug. The message was: warning: jobserver unavailable: using -j1. To me, this sounds like 'make' could not create a jobserver, because the jobservers rely on named

Bug#1031952: Fwd: Bug#1031952: gettext: Missing source for an installed windows binary

Santiago Vila wrote: > Summary: There is no source for gettext-tools/m4/csharpexec-test.exe. Fixed through https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commitdiff;h=1bda6586b87f7e258c16bd0dca5c43048b9920a9 Thanks for the report. > Note: The Debian package disabled the mono stuff in vers

Bug#1031952: Fwd: Bug#1031952: gettext: Missing source for an installed windows binary

Adrian Bunk wrote: > In practice the main usecase for Mono on Linux is porting of > proprietary Windows programs to Linux. > > > and also isn't it useful for building mobile apps [2]? > > "Build cross-platform Android & iOS apps using C# and .NET in Visual > Studio on Windows and macOS."[3] >

Bug#1031952: Fwd: Bug#1031952: gettext: Missing source for an installed windows binary

Santiago Vila wrote: > For completeness: Would it make sense to add an indication, somewhere, about > the way > to create the .exe from the .cs? This is something that surely everybody using > mono knows, but I had to search for it. I guess this would be correct: > > mcs -out:csharpexec-test.exe

Bug#1031952: Fwd: Bug#1031952: gettext: Missing source for an installed windows binary

Santiago Vila wrote: > And yes, I assume it already works in maintainer mode, but only if mcs is in > PATH. The point of distributing the csharpexec-test.exe as a binary is to be able to have C# support in 'msgunfmt' even when the environment contains a C# execution engine but no C# compiler. Br

Bug#1032011: Fwd: Bug#1032011: gettext: Private library should go to private subdir under lib

Santiago Vila wrote: > Mensaje reenviado > Asunto: Bug#1032011: gettext: Private library should go to private subdir > under lib > Fecha: Sun, 26 Feb 2023 14:57:45 + > De: Bastien Roucariès > Responder a: Bastien Roucariès , 1032...@bugs.debian.org > Para: Debian Bug Trackin

Bug#786885: Broken gettext check in the build system of bison

The issue was fixed through https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commitdiff;h=b67399b40bc5bf3165b09e6a095ec941d4b30a97 and is thus contained in gettext-0.19.8 and newer. The *gettext functions in musl libc work seamlessly with .mo files produced by msgfmt 0.22 or newer, except for

Bug#1032010: gettext: binary in /usr/lib should move to libexec

Hi, Bastien Roucariès wrote in : > /usr/lib/x86_64-linux-gnu/gettext/cldr-plurals > /usr/lib/x86_64-linux-gnu/gettext/hostname > /usr/lib/x86_64-linux-gnu/gettext/project-id > /usr/lib/x86_64-linux-gnu/gettext/urlget > /usr/lib/x86_64-lin

Bug#480774: diff -y in UTF-8: bad alignment

Vincent Lefevre reported in : > When "diff -y" in run on files that contain multibyte characters (in > UTF-8), the alignment is incorrect in the output. This is fixed upstream, in the CVS version of diffutils at https://savannah.gnu.org/

Bug#521737: Segfault in memchr when called via strstr

The Austin group has clarified in the specification of memchr: "Implementations shall behave as if they read the memory byte by byte from the beginning of the bytes pointed to by s and stop at the first occurrence of c." So passing a

Bug#385005: gettext-el: po-mode inserts header if buffer is narrowed (fwd)

Sven Joachim wrote: > There is a small bug in the function po-check-file-header. If the > buffer is narrowed, M-x po-mode can insert a header even if the buffer > already has one in its not currently visible part. Can you please describe more in detail how to reproduce it? Ideally in a step-by-st

Bug#385005: gettext-el: po-mode inserts header if buffer is narrowed (fwd)

Hello, Sven Joachim wrote: > Surely. Open some PO file (in po-mode). Type 'E' and confirm that > you want to edit the whole file. Narrow the buffer so that the PO > header is not visible (e.g. go to the last msgid string, then press > M-> and C-x n n). Type M-x po-mode. Now Emacs will insert

Bug#404364: Various typos in manpages

Hello Michael, > I'm not so sure of the details here, but maybe you are, since it relates to > iconv stuff. Can you confirm/disconfirm the > correctness of this part of the patch below: > > > -values are listed by the \fBiconv \-\-list\fP command, and all combinations > > +values are listed by

Bug#548493: test-yesno.sh failure

Jim Meyering wrote: > # Test with seekable stdin; the followon process must see remaining data. > -cat < ${p}in.tmp > +cat < ${p}in.tmp This can be simplified to: tr @ '\177' < ${p}in.tmp Bruno -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubs

Bug#538150: gettext: autopoint does not see additional po/ directories (fwd)

Guillem Jover wrote: > > > getttextize used to support more than one podir > > > > No, gettextize always only supported one podir. > I can see gettextize's --po-dir option which can be > specified several times Oops, you are right. I was wrong. Since version 0.17, gettextize *does* support multip

Bug#538150: gettext: autopoint does not see additional po/ directories (fwd)

-tools/misc/ChangeLog 2009-08-09 16:05:06.0 +0200 ******* *** 1,3 --- 1,13 + 2009-08-09 Bruno Haible + + Add support for multiple PO directories to autopoint. + * autopoint.in (sed_extract_config_files, configfiles, + sed_remove_Makefile_in, podirs): New variables. + (

Bug#474901: build failure when gcj is present

Santiago Vila wrote: > Maybe --disable-native-java is what I need? Yes. You hit the nail on the head. Bruno -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#474901: build failure when gcj is present

Ralf Wildenhues wrote: > Have you tried './configure GCJ=none'? > > BTW, it would be nice if gt_GCJ used or accepted 'no' instead of 'none' > as special value. The former is recognized e.g. in Libtool GCJ macros, Both uses that you mention are undocumented. If someone wants to disable the use of

Bug#482364: gettext-el: patch for po-mode to save buffer when PO-Revision-Date is hold

Kobayashi Noritada wrote on 2008-05-22: > po-mode provides po-auto-replace-revision-date, an option for users to > decide whether PO-Revision-Date field in the header should be > automatically updated or not. However, when users choose holding that > field, by setting that variable to "ask" and an

Bug#468209: msgfmt: no documentation of the --endianness option

Hi, While reading http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468209 I have to agree with most of what Santiago said. Neil Williams said: > On big endian systems, the CPU wastes time converting the endianness at > loadtime which is important for embedded devices. Do you have any figures?

Bug#491978: gettext: error in Plural-Forms documentation - an old version of docs perhaps?

rect form is: > > Plural-Forms: nplurals=3; \ > plural=((n==1) ? 0 : \ > (n>=2 && n<=4) ? 1 : 2);\n You are right. It's already corrected in gettext 0.17 and on the web: http://www.gnu.org/software/gettext/manual/html_node/Plural-forms

Bug#330990: iso-codes .pot msgid strings contain non-ASCII characters

Paul Eggert wrote: > the GNU gettext manual says: > > Note that the MSGID argument to `gettext' is not subject to >character set conversion. Also, when `gettext' does not find a >translation for MSGID, it returns MSGID unchanged - independently of >the current output character se

Bug#978315: xgettext complains about UTF conformance of strings not marked for translation

Hi Santiago, Samuel, > The upload of gettext 0.21 for Debian unstable has made package "dasher", > maintained by Samuel Thibault (in Cc), not to build anymore, as reported here > by Lucas Nussbaum: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978315 > > We are not sure where is exactly

Bug#886986: please remove bump-fasl-loader-version.patch

Hi Norbert, > thanks for your email and your explanations. I am not clisp packager, > but TeX Live (upstream and Debian) maintainer and thus also xindy > maintainer. I appreciate this work that you do. Nevertheless, your view of clisp .mem file does not match reality: 1) The error "initializatio

Bug#886986: please remove bump-fasl-loader-version.patch

Sébastien Villemot wrote: > The right solution would be to extract the > hash for the .mem format when compiling clisp, and then turn it into a virtual > package (like "clisp-mem-", pretty much like we do for FASL version > format). Then, when xindy is compiled, it would acquire the dependency on t

Bug#886986: please remove bump-fasl-loader-version.patch

Norbert Preining wrote: > this is the way the build process is set up by the upstream author, and > rewritting the whole build and distribution process *independently* from > upstream xindy is not an option AFAIU, the "virtual package with a hash code in its name" concept, proposed by Sébastien, i

Bug#886986: please remove bump-fasl-loader-version.patch

Sébastien Villemot wrote: > > 1) Will the package manager report a conflict? > > Yes. > > > 2) Will the package manager propose, as solution of this conflict, to > > install > > another binary package for xindy? Or will it only propose to remove > > xindy? > > Only two options will be

Bug#876498: [bug-gettext] Bug#876498: gettext: msgunfmt: heap corruption

Hi Daiki, > Running msgunfmt under valgrind might give you more hints. Anyway, I am > suspecting this is caused by a missing NUL termination in > get_sysdep_string in read-mo.c, which should be fixed by the attached patch. Yes, the valgrind run points into this direction: #CHECKER = valgrind --t

Bug#920824: libunistring: please disable --as-needed

> Maybe eventually Debian will use --as-needed by default too In this case, I would suggest to apply the fix that has been done upstream: https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=cca32830b57e91f837c01d15b8732f23ff97fc36 Bruno

Bug#507091: xgettext: fails to detect 'gettext -e' and 'eval_gettext -e' strings

Hi, Eugene V. Lyubimkin wrote in : > While 'gettext "abcde"' in shell script is well recognizeable, > 'gettext -e "abcde"' is not recognizeable at all. This is now fixed: https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commitdiff;h=7

Bug#764483: gettext: Please support setting COPYRIGHT_HOLDER from an autoconf variable (fwd)

Hi Santiago, Re > For dpkg, which uses muliple po directories, I'd like to be able to > set the COPYRIGHT_HOLDER variable centrally, instead of having to set > it o

Bug#925129: ffcall failed to build mips64 R6 version due to Illegal instruction

Hi, In you reported a problem with the use of the 'jr $25' instruction on MIPS32R6. Thanks for this report. I've changed the code to use the new opcode (previously written as 'jal $0,$25') always, since this opcode is supported since the

Bug#910246: [ebo...@apache.org: Bug#910246: gettext: FTBFS with Java 11: unknown target-version 11, please update gt_JAVACOMP macro]

Hi Santiago, > Dear gettext maintainers: > > I have received this report from the Debian bug system. > > A problem like this was already reported by Emmanuel and fixed in git, > from where I took the fix for the Debian package, but Java keeps > evolving all the time and the fix from March is not

Bug#910246: [ebo...@apache.org: Bug#910246: gettext: FTBFS with Java 11: unknown target-version 11, please update gt_JAVACOMP macro]

Hi Emmanuel, > Out of curiosity, why is such a sophisticated Java version detection > logic necessary? As far as I know it's rather unique. If gettext only > needs a Java 1.4 compiler any version of Java released in the past 15 > years is suitable anyway. The 'javacomp' macro and module are made

Bug#314832: unzip: does not respect umask

Package: unzip Version: 6.0 Severity: normal I still see this bug in version 6.0 (6.0-26ubuntu3, to be precise). It's a security issue (because it allows other users on the same machine to overwrite the extracted files, if they know the file names). As such: * It should be treated with severit

Bug#314832: Fwd: Bug#314832: unzip: does not respect umask

Santiago Vila wrote: > If you want to follow Bruno's suggestion that unzip is secure by default > (which I would support), I guess it would not be a lot of work, because, > once that there is already a new command line option for that, it would > be just a matter of reversing its logic (i.e. ins

Bug#507091: xgettext: fails to detect 'gettext -e' and 'eval_gettext -e' strings

I wrote: > This is now fixed: > https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commitdiff;h=7643c58c13761bf0062c73d3114d4243250e8be9 > > The fix will be contained in the next release. The fix is contained in gettext 0.20.2. Bruno

Bug#968437: xindy-rules: Incorrect Norwegian sorting of č and š

Hi Norbert, >From your description, it looks like an issue in xindy, not in GNU clisp on which xindy is based in TeX Live. Therefore the proper place to report this issue is with the xindy developer Joachim Schrod. Probably at https://github.com/jschrod/xindy.ctan . Bruno

Bug#1085990: torbrowser-launcher: message catalog installed in wrong location

Oops, I misspoke regarding zh_SG. Chinese in Singapore uses Simplified Chinese characters. Therefore please *don't* install the translation for zh_SG. Bruno

Bug#1085964: sphinx-common: message catalog for Norwegian Bokmål installed in wrong location

Package: sphinx-common Version: 4.3.2-1 Severity: minor Tags: l10n X-Debbugs-Cc: br...@clisp.org Dear Maintainer, The message catalog for Norwegian Bokmål is installed in /usr/share/locale/nb_NO/LC_MESSAGES/sphinx.mo . This has the effect that for users who set LANGUAGE=nb (per the documentation

Bug#1085963: libmypaint-common: message catalog for Norwegian Nynorsk installed in wrong location

Package: libmypaint-common Version: 1.6.0-2 Severity: minor Tags: l10n X-Debbugs-Cc: br...@clisp.org Dear Maintainer, The message catalog for Norwegian Nynorsk is installed in /usr/share/locale/nn_NO/LC_MESSAGES/libmypaint.mo . This has the effect that for users who set LANGUAGE=nn (per the docu

Bug#1085950: gajim: message catalog for Serbian (Latin script) installed in wrong place

Package: gajim Version: 1.3.3-1 Severity: minor Tags: l10n X-Debbugs-Cc: br...@clisp.org Dear Maintainer, The message catalog for Serbian with Latin script is installed in /usr/share/locale/sr@Latn/LC_MESSAGES/gajim.mo (or /usr/lib/python3/dist-packages/gajim/data/locale/sr@Latn/LC_MESSAGES/gaji

Bug#1085952: xdg-user-dirs: message catalog for Serbian (Latin script) installed in wrong place

Package: xdg-user-dirs Version: 0.17-2ubuntu4 Severity: minor Tags: l10n X-Debbugs-Cc: br...@clisp.org Dear Maintainer, The message catalog for Serbian with Latin script is installed in /usr/share/locale/sr@Latn/LC_MESSAGES/xdg-user-dirs.mo . But the lookup (done by glibc) uses the locale name,

Bug#1085954: fontforge-common: message catalog for Turkish installed in wrong location

Package: fontforge-common Version: 1:20201107~dfsg-4+deb11u1build0.22.04.1 Severity: minor Tags: l10n X-Debbugs-Cc: br...@clisp.org Dear Maintainer, The message catalog for Turkish is installed in /usr/share/locale/tr_TR/LC_MESSAGES/FontForge.mo . This has the effect that for users who set LANGU

Bug#1085961: vlc-l10n: message catalog for Assamese installed in wrong location

Package: vlc-l10n Version: 3.0.16-1build7 Severity: minor Tags: l10n X-Debbugs-Cc: br...@clisp.org Dear Maintainer, The message catalog for Assamese is installed in /usr/share/locale/as_IN/LC_MESSAGES/vlc.mo . This has the effect that for users who set LANGUAGE=as (per the documentation at https

Bug#1085985: libfilezilla-common: 23 message catalogs installed in wrong location

Package: libfilezilla-common Version: 0.36.0-2 Severity: minor Tags: l10n X-Debbugs-Cc: br...@clisp.org Dear Maintainer, The message catalog for Thai is installed in /usr/share/locale/th_TH/LC_MESSAGES/libfilezilla.mo . This has the effect that for users who set LANGUAGE=th (per the documentatio

Bug#1085987: filezilla-common: 24 message catalogs installed in wrong location

Package: filezilla-common Version: 3.58.0-1ubuntu0.1 Severity: minor Tags: l10n X-Debbugs-Cc: br...@clisp.org Dear Maintainer, The message catalog for Thai is installed in /usr/share/locale/th_TH/LC_MESSAGES/filezilla.mo . This has the effect that for users who set LANGUAGE=th (per the documenta

Bug#1085988: iso-codes: 2 message catalogs installed in wrong location

Package: iso-codes Version: 4.9.0-1 Severity: minor Tags: l10n X-Debbugs-Cc: br...@clisp.org Dear Maintainer, 2 message catalogs installed in wrong location The message catalogs iso_639-5.mo for Chinese are installed in /usr/share/locale/zh_Hans/LC_MESSAGES/iso_639-5.mo /usr/share/locale/zh_Hant

Bug#1085962: gajim: message catalog for Norwegian Bokmål installed in wrong location

Package: gajim Version: 1.3.3-1 Severity: minor Tags: l10n X-Debbugs-Cc: br...@clisp.org Dear Maintainer, The message catalog for Norwegian Bokmål is installed in /usr/share/locale/nb_NO/LC_MESSAGES/gajim.mo (or /usr/lib/python3/dist-packages/gajim/data/locale/nb_NO/LC_MESSAGES/gajim.mo in newer

Bug#1080330: bug#73928: Bug#1080330: coreutils: who no longer works

Paul Eggert wrote: > If I configure current (f2e323430193956709aacca33f6b4fcab4fb9d8b) > Coreutils with --enable-systemd on my Ubuntu 24.10 desktop, the output > gets worse: > >$ ./who-no-systemd # Configured normally. >eggert seat02025-02-15 10:11 (login screen) >eggert

Bug#1080330: bug#73928: Bug#1080330: coreutils: who no longer works

Arsen Arsenović wrote: > >> I agree with you that this _looks_like_ as if a user named 'gdm' was logged > >> in, and thus is misleading. But I don't think this should be fixed in > >> coreutils. Rather, this is something to work out between systemd-logind > >> and gdm. > > > > OK, but until that's

Bug#1080330: bug#73928: Bug#1080330: coreutils: who no longer works

his commit to gnulib. Paul, does it work for you (after installing package 'systemd-devel' and rebuilding coreutils with --enable-systemd)? 2025-02-19 Bruno Haible readutmp: Let callers distinguish LOGINs from USERs. Reported by Paul Eggert in <https://list

Bug#1098478: guile-fibers: Please add support for loong64

gt; gl_cv_host_cpu_c_abi_32bit=unknown ;; This change is correct, but is missing a corresponding change for loongarch32. I'm applying the patch below instead. [1] LoongArch toolchain conventions, https://loongson.github.io/LoongArch-Documentation/LoongArch-toolchain-

Bug#1080330: bug#73928: Bug#1080330: coreutils: who no longer works

Arsen Arsenović wrote: > Sure, but one cannot name two users on a Unix system 'gdm', and there is > a passwd entry for 'gdm', so that scenario is impossible (save for > administrative errors): > > arsen@fedora:~$ grep gdm /etc/passwd > gdm:x:42:42:GNOME Display Manager:/var/lib/gdm:/usr/sbin/n