Bug#1081259: libreoffice:FTBFS:build failure (test failed on riscv64)
Hi again, Am 10.09.24 um 06:15 schrieb Yue Gui: The patch is in the attachment. That "patch" just hides everything under the carpet on riscv64. Whereas this check exactly was added upstream in knowledge riscv64 had that problem. And yes, IMHO that needs to be tested, not blacked out on the arch it was done for. As I said in my other mail (which I sent from my vaction "unauthenticated" so gmail rejected it) I still disabled it in 24.8.x packages, but with a prominent debconf note, which I think is better. Regards, Rene
Bug#1080096: fail to build with kernel 6.10.6+bpo-amd64 - implicit declaration of function ‘follow_pfn’
Thank you very much for the backport. I didn't know Sid and bookworm/backport provided the same version of Nvidia drivers (plus I try to avoid Sid because 'it's dangerous ' ;) ) I am doing some stuff with docker/Nvidia and I have a little issue with software which don't seem to see the HW properly. I was thinking it was due to different version of drivers/lib between the host and the container. That is why I needed this particular version to work. The solution to fix the problem here was trivial and I was thinking that some people might need it until a proper solution is found. Anyway, thank you again. François
Bug#825790: Bug#941335: Patch
On Sat, Aug 31, 2024 at 07:01:21PM +, Eric Wong wrote: > Rene Kita wrote: [...] > > Eric, just in case you are still interested I also have a patch to force > > folding in tags. > > Thanks, I am still interested in the folding patch as well. Patch is below. > I didn't find an improvement from using > Do-not-override-cols-option-value.patch on my -heavy sites I read this as: The patch worked, but the result was not satisfying because of the many s, right? Thanks for testing. > Thanks again. Your welcome. I don't expect those patches to be available in Debian in the near future. You might check out my fork at [0], those patches are currently staged in branch 'next' for some beta testing. [0]: https://sr.ht/~rkta/w3m ->8-- >From 6e93a36c274dd2a3b9541730aa59023915660c2f Mon Sep 17 00:00:00 2001 From: Rene Kita Date: Sun, 1 Sep 2024 12:23:17 +0200 Subject: [PATCH] Enable folding in pre tags Some bug trackers are really annoying to read, because they place comments in elements. They usually provide some CSS to make it readable. As we do not speak CSS, add a command to reload the page folding those long lines. This is a one-time operation. Additionally add an option to make this behaviour permanent. --- doc-de/README.func | 1 + doc/README.func| 1 + file.c | 7 +-- fm.h | 1 + main.c | 11 +++ proto.h| 1 + rc.c | 3 +++ 7 files changed, 23 insertions(+), 2 deletions(-) diff --git a/doc-de/README.func b/doc-de/README.func index cb175db4..7adabfba 100644 --- a/doc-de/README.func +++ b/doc-de/README.func @@ -31,6 +31,7 @@ EXEC_SHELLFühre Shell-Befehl aus und zeige Ausgabe an EXIT Sofort beenden EXTERN Verwende externen Browser zur Anzeige EXTERN_LINKVerwende externen Browser zur Anzeige des Linkziels +FOLD_PRE Erzwinge Umbruch von langen Zeilen in -Elementen FRAME Wechsle zwischen Kennung und Umsetzung von HTML-Frames GOTO Öffne angegebenes Dokument in neuem Puffer GOTO_HOME Zurück zur Startseite (die Variablen HTTP_HOME oder WWW_HOME spezifiziert wurden) diff --git a/doc/README.func b/doc/README.func index 55523a4b..65ca1f84 100644 --- a/doc/README.func +++ b/doc/README.func @@ -31,6 +31,7 @@ EXEC_SHELLExecute shell command and display output EXIT Quit without confirmation EXTERN Display using an external browser EXTERN_LINKDisplay target using an external browser +FOLD_PRE Fold long lines in elements FRAME Toggle rendering HTML frames GOTO Open specified document in a new buffer GOTO_HOME Return to the homepage (specified HTTP_HOME or WWW_HOME variable) diff --git a/file.c b/file.c index fb0a75ef..74927de9 100644 --- a/file.c +++ b/file.c @@ -30,6 +30,7 @@ #define MAX_INPUT_SIZE 80 /* TODO - max should be screen line length */ +extern int fold_pre; static int frame_source = 0; static int need_number = 0; @@ -2604,7 +2605,7 @@ check_breakpoint(struct readbuffer *obuf, int pre_mode, char *ch) int tlen, len = obuf->line->length; append_tags(obuf); -if (pre_mode) +if (pre_mode && !fold_pre) return; tlen = obuf->line->length - len; if (tlen > 0 @@ -6695,7 +6696,8 @@ HTMLlineproc0(char *line, struct html_feed_environ *h_env, int internal) proc_mchar(obuf, 1, delta, &str, mode); } if (obuf->flag & (RB_SPECIAL & ~RB_PRE_INT)) - continue; + if (!fold_pre) + continue; } else { if (!IS_SPACE(*str)) @@ -6923,6 +6925,7 @@ loadHTMLBuffer(URLFile *f, Buffer *newBuf) if (src) newBuf->sourcefile = tmp->ptr; } +fold_pre |= FoldPre; loadHTMLstream(f, newBuf, src, newBuf->bufferprop & BP_FRAME); diff --git a/fm.h b/fm.h index a2ca9ead..5353589e 100644 --- a/fm.h +++ b/fm.h @@ -1058,6 +1058,7 @@ global int ignore_null_img_alt init(TRUE); #define DISPLAY_INS_DEL_FONTIFY2 global int displayInsDel init(DISPLAY_INS_DEL_NORMAL); global int FoldTextarea init(FALSE); +global int FoldPre init(FALSE); global int FoldLine init(FALSE); #define DEFAULT_URL_EMPTY 0 #define DEFAULT_URL_CURRENT1 diff --git a/main.c b/main.c index 144c21b7..4c0b8613 100644 --- a/main.c +++ b/main.c @@ -129,6 +129,7 @@ static int searchKeyNum(void); int enable_inline_image; extern int opt_cols; +int fold_pre; static void fversion(FILE * f) @@ -4963,6 +4964,14 @@ DEFUN(vwSrc, SOURCE VIEW, "Toggle between HTML shown or processed") displayBuffer(Currentbuf, B_NORMAL); } +DEFUN(foldPre, FOLD_PRE, "Fold long lines in elements") +{ +fold_pre = 1; +Currentbuf->need_reshape = TRUE; +displayBuffer(Currentbuf, B_FOR
Bug#1079858: ITS: textdraw
Am 28.08.24 um 19:36 schrieb Andreas Tille: Could you please give some example for what you conaiser "quite nicely"? Not filing a RFS in the first place (with even already importing the stuff into a salvage team space, referring reasons fr salvaging which *all* do not apply in this package[1]) and no open bugs which warrant any "salvaging". But asking per mail whether it could be moved to "Debian". Regards, Rene [1] I don't reply to obvious stuff wher ethere's no more info needed like the typo fix or the FTBCFS one (however uneeded that one is inself, maybe I should have done)
Bug#1079858: ITS: textdraw
[ greeting intentionally left out ] Am 28.08.24 um 10:53 schrieb Andreas Tille: I would like to salvage your package textdraw by following the Package Salvaging procedur which is described in Developers Reference[1]. Your package is fulfilling the following criteria for the salvage process: - NMUs, especially if there has been more than one NMU in a row. lol? There was only one for already dubious reasons. - Bugs filed against the package do not have answers from the maintainer. What should I reply to a minor typo which could be fixed anytime but does not need to be and a "bug" for cross-building for a package which does not need to be cross-built since it's one gcc call? - There are QA issues with the package. For example? I have created a repository inside the salvage-team space[2]. Remove it, please. Or at least directly put it into Debina WITHOUT EVEN MENTIONING ANY "salvaging" BULLS*. Your package showed up in the Bug of the Day[3] initiative. I don't care. At all. There's useful stuff to do. This bug is the contrary. Rene, as a personal note since we know for a long time: I know you are doing great work on a lot of way more important packages. I simply would love to see also those tiny, low maintenance packages available on Salsa. Its a really great example for the newcomers that should be attracted by the Bug of the Day initiative. Thanks a lot for all your other work. A personal note: If you did ask quite nicely I 'd have agreed. It might have make sense. This pure nonsensical bug is not that and therefore this is not senseful. Rene
Bug#825790: Patch
Below is a patch for this. Eric, just in case you are still interested I also have a patch to force folding in tags. >8- From: Rene Kita Date: Sun Aug 25 15:43:35 CEST 2024 Subject: Do not override cols option value Patch: patches/Do-not-override-cols-option-value.patch Fixes Debian BTS #825790, Debian BTS #941335, GitHub Issue #253. Fixes: https://todo.sr.ht/~rkta/w3m/23 --- main.c | 13 + terms.c |3 +++ 2 files changed, 8 insertions(+), 8 deletions(-) --- a/main.c +++ b/main.c @@ -132,6 +132,7 @@ static int searchKeyNum(void); #define usage() fusage(stderr, 1) int enable_inline_image; +extern int opt_cols; static void fversion(FILE * f) @@ -713,7 +714,7 @@ main(int argc, char **argv) else if (!strcmp("-cols", argv[i])) { if (++i >= argc) usage(); - COLS = atoi(argv[i]); + opt_cols = atoi(argv[i]); } else if (!strcmp("-ppc", argv[i])) { double ppc; @@ -904,14 +905,10 @@ main(int argc, char **argv) CookieFile = rcFile(COOKIE_FILE); #endif -if (!isatty(1) && !w3m_dump) { - /* redirected output */ +if (!isatty(1) && !w3m_dump) /* redirected output */ w3m_dump = DUMP_BUFFER; -} -if (w3m_dump) { - if (COLS == 0) - COLS = DEFAULT_COLS; -} +if (w3m_dump) + COLS = opt_cols ? opt_cols : DEFAULT_COLS; #ifdef USE_BINMODE_STREAM setmode(fileno(stdout), O_BINARY); --- a/terms.c +++ b/terms.c @@ -426,6 +426,7 @@ char *T_cd, *T_ce, *T_kr, *T_kl, *T_cr, *T_ti, *T_te, *T_nd, *T_as, *T_ae, *T_eA, *T_ac, *T_op; int LINES, COLS; +int opt_cols; #if defined(__CYGWIN__) int LASTLINE; #endif /* defined(__CYGWIN__) */ @@ -1255,6 +1256,8 @@ setlinescols(void) LINES = tgetnum("li"); /* number of line */ if (COLS <= 0) COLS = tgetnum("co"); /* number of column */ +if (opt_cols && COLS > opt_cols) + COLS = opt_cols; #if defined(__CYGWIN__) LASTLINE = LINES - (isWinConsole == TERM_CYGWIN_RESERVE_IME ? 2 : 1); #endif /* defined(__CYGWIN__) */
Bug#1077806: libreoffice-core: libreoffice (i386) crashes on startup
Hi, Am 22.08.24 um 23:01 schrieb Andres Alla: reede, 2. august 2024 20:01:10 EEST kirjutas Rene Engelhard: Am 02.08.24 um 17:25 schrieb Andres Alla: [] I suspect it may be i386 specific. I suspect, too. Works definitely on amd64. It may be fixed in 24.8.0 but see below. After some detouring I stumbled on upstream commit https://github.com/LibreOffice/core/commit/542e590 that supposedly fixes this bug. Interesting. I now upgraded to 4:24.8.0~rc3-2 from experimental and everything works fine with SAL_USE_VCLPLUGIN set either kf5 or gen. 4:24.2.5-3 from unstable also worked if libreoffice-plasma installed and SAL_USE_VCLPLUGIN set to kf5; crashed if gen. Well, as I said I tried with "gen" in my VM, too. I am not sure why it did not show up on amd64 because it seems to be rather KDE- than i386-specific. As said hee it didn't even affect a clean i386 VM. Now that I got it working, it is back to all original Debian, without these weird packages. OK, hopefully even without dmo :) But should we close it with 4:24.8.0~rc3-2 then? Regards, Rene
Bug#1079598: Right-clicking 'New Style' in inactive Writer window opens menu in active window on another monitor.
forwarded 1079598 https://bugs.documentfoundation.org/show_bug.cgi?id=162620 thanks Hi, Am 25.08.24 um 07:18 schrieb Fabrice Quenneville: Upstream Bug Report I had already submitted before reading https://www.debian.org/Bugs/Reporting#reportbug saying not to report upstream first : - https://bugs.documentfoundation.org/show_bug.cgi?id=162620 Thanks anyway, Would forward it anyway and it's better IMHO to directly report it upstream here and me then forward it manually and play ping-pong. So you IHO did it correct. Marking as forwarded to your upstream bug. Regards, Rene
Bug#1074338: Bug#1073508: Bug#1074338: src:libxml2: fails to migrate to testing for too long: unresolved RC issue
Hi, Am 17.08.24 um 05:58 schrieb Aron Xu: After some research, I prefer making a t64-like transition for libxml2 for the following reasons: - Upstream is not prepared to bump the SONAME to something like libxml3. Given the long history of this function library, determining which APIs should be public and which should be private is challenging. [...] I've prepared a preliminary debdiff and tested locally. What do you think? - dh_makeshlibs -plibxml2 -V 'libxml2 (>= 2.9.11)' -- -c4 + dh_makeshlibs -plibxml2n -V 'libxml2 (>= 2.9.11)' -- -c4 Look wrong to me, should be libxml2 in the version, too. --- libxml2-2.13.3+dfsg/debian/libxml2n.symbols 1970-01-01 08:00:00.0 +0800 +++ libxml2-2.13.3+dfsg/debian/libxml2n.symbols 2024-08-16 22:13:37.0 +0800 @@ -0,0 +1,146 @@ +libxml2.so.2 libxml2 #MINVER# [...] here, too. Otherwise stuff built against the NEW ABI still gets dependencies fullfillable by old ones. For the same reason +Provides: libxml2 (= ${binary:Version}) is bad, that is the other way round and stuff using the old ABI will happily install with libxml2n. (That Provides: was there in t64 where the ABI didn't change, aka all 64bit + i386) And I *think* you need Breaks/Conflicts in addition to Replaces at the new libxml2n. Regards, Rene
Bug#1078568: RM: libreoffice-sdbc-hsqldb [armel] -- NBS; Java disabled
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: libreoff...@packages.debian.org, r...@debian.org Control: affects -1 + src:libreoffice Hi, please remove libreoffice-sdbc-hsqldb from unstable on armel, it is disabled since 4:24.2.5-2. dak rm -a armel -R -s unstable -o libreoffice -n (without -n for you of course) does what it should do: $ dak rm -a armel -R -s unstable -o libreoffice -n W: -a/--architecture implies -p/--partial. Will remove the following packages from unstable: libofficebean-java | 4:24.2.5-1 | armel libreoffice | 4:24.2.5-1 | source libreoffice-report-builder-bin | 4:24.2.5-1 | armel libreoffice-sdbc-hsqldb | 4:24.2.5-1 | armel ure-java | 4:24.2.5-1 | armel Regards, Rene
Bug#1078569: RM: ure-java [armel] -- NBS; Java disabled
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: libreoff...@packages.debian.org, r...@debian.org Control: affects -1 + src:libreoffice Hi, please remove ure-java from unstable on armel, it is disabled since 4:24.2.5-2. dak rm -a armel -R -s unstable -o libreoffice -n (without -n for you of course) does what it should do: $ dak rm -a armel -R -s unstable -o libreoffice -n W: -a/--architecture implies -p/--partial. Will remove the following packages from unstable: libofficebean-java | 4:24.2.5-1 | armel libreoffice | 4:24.2.5-1 | source libreoffice-report-builder-bin | 4:24.2.5-1 | armel libreoffice-sdbc-hsqldb | 4:24.2.5-1 | armel ure-java | 4:24.2.5-1 | armel Regards, Rene
Bug#1078567: RM: libreoffice-report-builder-bin [armel] -- NBS; Java disabled
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: libreoff...@packages.debian.org, r...@debian.org Control: affects -1 + src:libreoffice Hi, please remove libreoffice-report-builder-bin from unstable on armel, it is disabled since 4:24.2.5-2. dak rm -a armel -R -s unstable -o libreoffice -n (without -n for you of course) does what it should do: $ dak rm -a armel -R -s unstable -o libreoffice -n W: -a/--architecture implies -p/--partial. Will remove the following packages from unstable: libofficebean-java | 4:24.2.5-1 | armel libreoffice | 4:24.2.5-1 | source libreoffice-report-builder-bin | 4:24.2.5-1 | armel libreoffice-sdbc-hsqldb | 4:24.2.5-1 | armel ure-java | 4:24.2.5-1 | armel Regards, Rene
Bug#1078566: RM: libofficebean-java [armel] -- NBS; Java disabled
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: libreoff...@packages.debian.org, r...@debian.org Control: affects -1 + src:libreoffice Hi, please remove libofficebean-java from unstable on armel, it is disabled since 4:24.2.5-2. dak rm -a armel -R -s unstable -o libreoffice -n (without -n for you of course) does what it should do: $ dak rm -a armel -R -s unstable -o libreoffice -n W: -a/--architecture implies -p/--partial. Will remove the following packages from unstable: libofficebean-java | 4:24.2.5-1 | armel libreoffice | 4:24.2.5-1 | source libreoffice-report-builder-bin | 4:24.2.5-1 | armel libreoffice-sdbc-hsqldb | 4:24.2.5-1 | armel ure-java | 4:24.2.5-1 | armel Regards, Rene
Bug#1078537: unblock: libreoffice/4:24.2.5-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: Deiban Korean L10N , Debian Accessibility Team Control: affects -1 + src:libreoffice Hi, Please hint package libreoffice in (unblock is strictly speaking wrong here, but...) This is blocked by autopkgtests: ∙ ∙ autopkgtest for h2orestart/0.6.6-1: amd64: Pass, arm64: Pass, armel: Regression or new test ♻ (reference ♻), armhf: Failed (not a regression), i386: Pass, ppc64el: Failed (not a regression) ∙ ∙ autopkgtest for libreoffice/4:24.2.5-3: amd64: Pass, arm64: Pass, armel: Test in progress (will not be considered a regression), armhf: Test in progress, i386: Test in progress (will not be considered a regression), ppc64el: Test in progress (will not be considered a regression) ∙ ∙ autopkgtest for natbraille/2.0rc3-15: amd64: No tests, superficial or marked flaky ♻ (reference ♻), arm64: No tests, superficial or marked flaky ♻ (reference ♻), armel: Regression or new test ♻ (reference ♻), armhf: Failed (not a regression), i386: No tests, superficial or marked flaky ♻ (reference ♻), ppc64el: Failed (not a regression) (cf. https://qa.debian.org/excuses.php?package=libreoffice) -2 and -3 fix two (unreported) FTBFS with gcc 14 (-2) and openjdk-21 (I assume) as default (-3). Whereas the openjdk 21 is a testsuite failure ("exception occurred: Could not create Java implementation loader at ./stoc/source/javaloader/javaloader.cxx:551") and thus I simply disabled Java there too. This is for armel only. And s390x, ppc64el, armhf has it already so now armel also is consistent with armhf. The autopkgtests of h2orestart and natbraille (Both arch: all) is there since Java support in armel is gone now (as said as before for armhf etc) and this was hinted in alreday for those. I hope I got the syntax right, no idea whether that is correct for tests in other packages affected by libreoffice. Adapt as needed, please :) force-badtest libreoffice/4:24.2.5-3/armel Regards, Rene
Bug#1077806: libreoffice-core: libreoffice (i386) crashes on startup
0.19.2-3+b3 ii liborcus-parser-0.18-0 0.19.2-3+b3 ii libpng16-16t64 1.6.43-5 ii libpoppler134 24.02.0-5+b1 ii libraptor2-02.0.16-4 ii librdf0t64 1.0.17-4 ii libreoffice-common 4:24.2.5-1+f1 ii librevenge-0.0-00.0.5-3+b1 ii libsm6 2:1.2.3-1+b1 ii libstdc++6 14.1.0-5 ii libtiff64.5.1+git230720-4 ii libuno-cppu3t64 4:24.2.5-1 ii libuno-cppuhelpergcc3-3t64 4:24.2.5-1 ii libuno-sal3t64 4:24.2.5-1 ii libuno-salhelpergcc3-3t64 4:24.2.5-1 ii libwebp71.4.0-0.1 ii libx11-62:1.8.7-1+b1 ii libx11-xcb1 2:1.8.7-1+b1 ii libxext62:1.3.4-1+b1 ii libxinerama12:1.1.4-3+b1 ii libxml2 2.12.7+dfsg-3+b1 ii libxmlsec1t64 1.2.41-1 ii libxmlsec1t64-nss 1.2.41-1 ii libxrandr2 2:1.5.4-1 ii libxrender1 1:0.9.10-1.1+b1 ii libxslt1.1 1.1.35-1.1 ii libzxcvbn0 2.5+dfsg-2 ii libzxing3 2.2.1-3+b1 ii uno-libs-private4:24.2.5-1 ii ure 4:24.2.5-1+f1 What on earth is this? This is some random version which doesn't exist? ii zlib1g 1:1.3.dfsg+really1.3.1-1 Versions of packages libreoffice-core recommends: ii gstreamer1.0-libav 1:1.24.6-dmo1 ii gstreamer1.0-plugins-bad 1:1.24.6-dmo1 ii gstreamer1.0-plugins-base 1.24.6-dmo1 ii gstreamer1.0-plugins-good 1.24.6-1 ii gstreamer1.0-plugins-ugly 1:1.24.6-dmo1 ii libpaper-utils 1.1.29+b1 Try with Debian. This is not Debian. And you even have inside gstreamer a mix between dmo and not-dmo. In any case: Just installed a debian i386 stable VM + dist-upgraded to sid. Just starts. (Also with SAL_USE_VCLPLUGIN=gen to match your config, also not with LANG=en-US.UTF_8 - as your locale. => unreproducible, moreinfo Regards, Rene
Bug#1077268: hunspell LIBDIR, USEROOODIR and OOO are either obsolete or wrong
Hi, Am 27.07.24 um 17:52 schrieb Jiri Belka: `hunspell -D' shows either MacOS, obsolete or incorrect paths: Mac OS and obsolete ones, yes. ---%>--- $ hunspell -D SEARCH PATH: .::/usr/share/hunspell:/usr/share/myspell: That is where the (system) dicts are /usr/share/myspell/dicts:/Library/Spelling:/home/jiri/.openoffice.org/3/user/wordbook:/home/jiri/.openoffice.org2/user/wordbook:/home/jiri/.openoffice.org2.0/user/wordbook:/home/jiri/Library/Spelling:/opt/openoffice.org/basis3.0/share/dict/ooo:/usr/lib/openoffice.org/basis3.0/share/dict/ooo:/opt/openoffice.org2.4/share/dict/ooo:/usr/lib/openoffice.org2.4/share/dict/ooo:/opt/openoffice.org2.3/share/dict/ooo:/usr/lib/openoffice.org2.3/share/dict/ooo:/opt/openoffice.org2.2/share/dict/ooo:/usr/lib/openoffice.org2.2/share/dict/ooo:/opt/openoffice.org2.1/share/dict/ooo:/usr/lib/openoffice.org2.1/share/dict/ooo:/opt/openoffice.org2.0/share/dict/ooo:/usr/lib/openoffice.org2.0/share/dict/ooo AVAILABLE DICTIONARIES (path is not mandatory for -d option): /usr/share/hunspell/en_US /usr/share/hunspell/cs_CZ /usr/share/hunspell/cs /usr/share/hunspell/it_IT /usr/share/hunspell/it_CH /usr/share/myspell/dicts/cs /usr/share/myspell/dicts/cs_CZ LOADED DICTIONARY: /usr/share/hunspell/en_US.aff /usr/share/hunspell/en_US.dic ---%<--- As seen here. For example, hunspell in OpenBSD ports patches that in the following way: ---%>--- Index: src/tools/hunspell.cxx --- src/tools/hunspell.cxx.orig +++ src/tools/hunspell.cxx @@ -116,28 +116,14 @@ #include "../parsers/odfparser.hxx" #define LIBDIR\ - "/usr/share/hunspell:" \ - "/usr/share/myspell:" \ - "/usr/share/myspell/dicts:" \ - "/Library/Spelling" + "${PREFIX}/share/hunspell:" \ + "${LOCALBASE}/share/myspell:" \ + "${LOCALBASE}/share/myspell/dicts:" \ + "${LOCALBASE}/share/mozilla-dicts" #define USEROOODIR { \ - ".openoffice.org/3/user/wordbook", \ - ".openoffice.org2/user/wordbook", \ - ".openoffice.org2.0/user/wordbook",\ - "Library/Spelling" } + ".config/libreoffice/4/user/wordbook" } #define OOODIR \ - "/opt/openoffice.org/basis3.0/share/dict/ooo:" \ - "/usr/lib/openoffice.org/basis3.0/share/dict/ooo:" \ - "/opt/openoffice.org2.4/share/dict/ooo:" \ - "/usr/lib/openoffice.org2.4/share/dict/ooo:" \ - "/opt/openoffice.org2.3/share/dict/ooo:" \ - "/usr/lib/openoffice.org2.3/share/dict/ooo:" \ - "/opt/openoffice.org2.2/share/dict/ooo:" \ - "/usr/lib/openoffice.org2.2/share/dict/ooo:" \ - "/opt/openoffice.org2.1/share/dict/ooo:" \ - "/usr/lib/openoffice.org2.1/share/dict/ooo:" \ - "/opt/openoffice.org2.0/share/dict/ooo:" \ - "/usr/lib/openoffice.org2.0/share/dict/ooo" + "${LOCALBASE}/lib/libreoffice/share/wordbook" #define HOME getenv("HOME") #define DICBASENAME ".hunspell_" #define LOGFILE "/tmp/hunspell.log" ---%<--- Why except solely for cosmetic? * What led up to the situation? I was checking how hunspell might work with LO dictionaries. LO dictionaries *ARE* hunspell directories. LO looks in /usr/share/hunspell * What exactly did you do (or not do) that was effective (or ineffective)? Next, I checked if `hunspell' is able to read my LO dict, but it wasn't. It does. What exactly doesn't work? Still assuming system dicts. (If you mean user dicts like below, you need to state that from the beginning.) * What was the outcome of this action? hunspell returns "bad (rejected) work - with '&', that is, with suggestion - for a work which is correct and present in my dictionary; an example: ---%>--- $ hunspell -d cs_CZ <<< "autobusáků" Hunspell 1.7.2 & autobusáků 1 0: autobusů ---%<--- * What outcome did you expect instead? I expected the previous command would return '*' as the word is present it my LO user dict: ---%>--- $ grep -n 'autobusáků' ~/.config/libreoffice/4/user/wordbook/standard.dic 114:autobusáků ---%<--- The workaround is to use `-p ~/.config/libreoffice/4/user/wordbook/standard.dic', but I would expect `hunspell' would use such a path automatically - see OpenBSD hunspell diff. ---%>--- hunspell -d cs_CZ -p ~/.config/libreoffice/4/user/wordbook/standard.dic <<< "autobusáků" error - iconv: ISO8859-2 -> UTF-8 Hunspell 1.7.2 * ---%<--- Ah, you are talking about user dicts.. That might make sense, and then also the OpenBSD patch would make sensein part (one could just add the libreoffice dir)... Regards, Rene
Bug#1077190: Accepted curl 8.9.0-2 (source) into unstable
Hi again, Am 27.07.24 um 08:07 schrieb Rene Engelhard: Am 27.07.24 um 08:00 schrieb Rene Engelhard: b) even more, pbuilder disables the install of recommends. That means builds inside pbuilder still will fail. This doesn't even work in sbuild (and thus the buildds). After I gave back libreoffice I got https://buildd.debian.org/status/fetch.php?pkg=libreoffice&arch=all&ver=4%3A24.8.0%7Erc2-1&stamp=1722060303&raw=0 Nevermind, I noticed that one actually still took -1 even though said curl was already Installed and thus it should have taken it from incoming. Ah, well. But e.g. https://buildd.debian.org/status/fetch.php?pkg=libreoffice&arch=armhf&ver=4%3A24.8.0%7Erc2-1&stamp=1722060618&raw=0 also shows that with Get:33 https://incoming.debian.org/debian-buildd buildd-unstable/main armhf libcurl4-openssl-dev armhf 8.9.0-2 [533 kB] etc it dosn't work. Regards, Rene
Bug#1077190: Accepted curl 8.9.0-2 (source) into unstable
Hi, Am 27.07.24 um 08:00 schrieb Rene Engelhard: b) even more, pbuilder disables the install of recommends. That means builds inside pbuilder still will fail. This doesn't even work in sbuild (and thus the buildds). After I gave back libreoffice I got https://buildd.debian.org/status/fetch.php?pkg=libreoffice&arch=all&ver=4%3A24.8.0%7Erc2-1&stamp=1722060303&raw=0 so exactly the same as before. Regards, Rene
Bug#1077190: Accepted curl 8.9.0-2 (source) into unstable
Hi, Am 27.07.24 um 08:00 schrieb Rene Engelhard: a) Is this needed for anything using liburls .pc. A pure --cflags now needs those. Even when not doing static linking. Recommends here is wrong. This needs to be a Depends. b) even more, pbuilder disables the install of recommends. That means builds inside pbuilder still will fail. [...] c) And even when recommends would work, it allowed removal of the mentioned libs, also causing breakage (like in big transitions), breaking pkg-config --cflags again. Regards, Rene
Bug#1077190: Accepted curl 8.9.0-2 (source) into unstable
reopen 1077197 reopen 1077190 thanks Hi, Am 27.07.24 um 06:34 schrieb Debian FTP Masters: * debian/control: make libcurl*-dev packages Recommends -dev packages. (Closes: #1077197, #1077190) This is not going to work. a) Is this needed for anything using liburls .pc. A pure --cflags now needs those. Even when not doing static linking. Recommends here is wrong. This needs to be a Depends. b) even more, pbuilder disables the install of recommends. That means builds inside pbuilder still will fail. $ sudo pbuilder login --basetgz /var/cache/pbuilder/base.testing.armhf.tgz [sudo] Passwort für rene: W: /root/.pbuilderrc does not exist W: cgroups are not available on the host, not using them. I: Building the build Environment I: extracting base tarball [/var/cache/pbuilder/base.testing.armhf.tgz] I: copying local configuration I: mounting /proc filesystem I: mounting /sys filesystem I: creating /{dev,run}/shm I: mounting /dev/pts filesystem I: redirecting /dev/ptmx to /dev/pts/ptmx I: mounting /dev/pts/4 over /dev/console I: policy-rc.d already exists I: Obtaining the cached apt archive contents I: entering the shell I: File extracted to: /var/cache/pbuilder/build/2896014 root@rpi4:/# cat /etc/apt/ apt.conf.d/ keyrings/ sources.list trusted.gpg.d/ auth.conf.d/ preferences.d/ sources.list.d/ root@rpi4:/# cat /etc/apt/apt.conf.d/ 01autoremove 15pbuilder 70debconf root@rpi4:/# cat /etc/apt/apt.conf.d/ 01autoremove 15pbuilder 70debconf root@rpi4:/# cat /etc/apt/apt.conf.d/15pbuilder APT::Install-Recommends "false"; APT::AutoRemove::SuggestsImportant false; APT::AutoRemove::RecommendsImportant false; Acquire::Languages none; root@rpi4:/# Regards, Rene
Bug#1077190: breaks build of uncounted packages
severity 1077190 serious thanks Now really... Am 26.07.24 um 18:04 schrieb Rene Engelhard: Hi, this bug means that uncounted packages (anything directly or indirectly using libcurl via pkg-config) now FTBFS in unstable. Raising the severity ti serious Regards, Rene
Bug#1077190: breaks build of uncounted packages
Hi, this bug means that uncounted packages (anything directly or indirectly using libcurl via pkg-config) now FTBFS in unstable. Raising the severity ti serious Regards, Rene
Bug#1076944: w3m: with -dump and large -cols, w3m inserts line breaks at column 1024 or before
On Wed, Jul 24, 2024 at 02:47:43PM +0200, Vincent Lefevre wrote: > Package: w3m > Version: 0.5.3+git20230121-2+b3 > Severity: normal > > With -dump and large -cols, w3m inserts line breaks to make lines > no longer than 1024 characters. This is due to an undocumented arbitrary upper limit to the value of -cols. fm.h defines MAXIMUM_COLS as 1024 and when parsing the command line parameters the argument to -cols is checked against this limit - if the argument is greater then MAXIMUM_COLS that will be used instead. I appended a patch to drop that feature. Thanks for your report! From: Rene Kita Date: Wed Jul 24 17:15:06 CEST 2024 Subject: Drop upper limit on COLS Patch: patches/Drop-upper-limit-on-COLS.patch The parameter -cols has an undocumented arbitrary limit of 1024. If a number greater than that is passed as an argument the value will be set to 1024 instead. I don't see a reason for this behavior. Drop that limit and let the user decide. This fixes Debian BTS #1076944 and GH issue #286. --- fm.h |1 - main.c |3 --- 2 files changed, 4 deletions(-) --- a/fm.h +++ b/fm.h @@ -103,7 +103,6 @@ void bzero(void *, int); #define LINELEN256 /* Initial line length */ #define PAGER_MAX_LINE 1 /* Maximum line kept as pager */ -#define MAXIMUM_COLS 1024 #define DEFAULT_COLS 80 #ifdef USE_IMAGE --- a/main.c +++ b/main.c @@ -692,9 +692,6 @@ main(int argc, char **argv) if (++i >= argc) usage(); COLS = atoi(argv[i]); - if (COLS > MAXIMUM_COLS) { - COLS = MAXIMUM_COLS; - } } else if (!strcmp("-ppc", argv[i])) { double ppc;
Bug#1076944: w3m: with -dump and large -cols, w3m inserts line breaks at column 1024 or before
On Wed, Jul 24, 2024 at 02:47:43PM +0200, Vincent Lefevre wrote: > Package: w3m > Version: 0.5.3+git20230121-2+b3 > Severity: normal > > With -dump and large -cols, w3m inserts line breaks to make lines > no longer than 1024 characters. This is due to an undocumented arbitrary upper limit to the value of -cols. fm.h defines MAXIMUM_COLS as 1024 and when parsing the command line parameters the argument to -cols is checked against this limit - if the argument is greater then MAXIMUM_COLS that will be used instead. I appended a patch to drop that feature. Thanks for your report! From: Rene Kita Date: Wed Jul 24 17:15:06 CEST 2024 Subject: Drop upper limit on COLS Patch: patches/Drop-upper-limit-on-COLS.patch The parameter -cols has an undocumented arbitrary limit of 1024. If a number greater than that is passed as an argument the value will be set to 1024 instead. I don't see a reason for this behavior. Drop that limit and let the user decide. This fixes Debian BTS #1076944 and GH issue #286. --- fm.h |1 - main.c |3 --- 2 files changed, 4 deletions(-) --- a/fm.h +++ b/fm.h @@ -103,7 +103,6 @@ void bzero(void *, int); #define LINELEN256 /* Initial line length */ #define PAGER_MAX_LINE 1 /* Maximum line kept as pager */ -#define MAXIMUM_COLS 1024 #define DEFAULT_COLS 80 #ifdef USE_IMAGE --- a/main.c +++ b/main.c @@ -692,9 +692,6 @@ main(int argc, char **argv) if (++i >= argc) usage(); COLS = atoi(argv[i]); - if (COLS > MAXIMUM_COLS) { - COLS = MAXIMUM_COLS; - } } else if (!strcmp("-ppc", argv[i])) { double ppc;
Bug#1076720: "Insert symbol" and libreoffice-gtk3
retitle 1076720 "Insert symbol" in tabbed ui doesn't appear with libreoffice-gtk3 thanks Hi, Am 22.07.24 um 22:05 schrieb Stefano: See attachment for the steps to reproduce on it_IT.UTF-8 locale. I am unsure what more information to offer I see. That is not standard UI but the ribbon stuff they unfortunately added ("Tabbed" / "A schede")... I usually don't even try anything there, so people should mention they use that. I use standard, "normal" UI :) as this used to happen consistently on my setup before the upgrade to backport, just by clicking on the elements circled in the screenshot. Even there I do get a "drop down" with symbols there. Yes, stable with it_IT even. So still unreproducible. In GNOME with gtk3. But anyway, as it's fixed in newer versions... Sorry for not making myself clearer earlier. The expected behavior is a new window opening up to select symbols(/special characters?). The actual behavior is nothing happening. The expected behaviour is a "drop down" here, not a new window. Regards, Rene
Bug#1076720: "Insert symbol" and libreoffice-gtk3
[ please don't uselessly mail stuff you don't need to CC. Especially submit@ and -done and control ] Hi, Am 22.07.24 um 20:09 schrieb Stefano: The tab and button actually read "Inserisci" and "Simbolo", respectively. Which tab and button? *I* mean the menu, did you mean something else? (I don't see Inserisci in the navigator bar either, in neither of the choices/icons etc. In any case: *You* need to tell people how to reproduce.) Special Character in the "Insert" toolbar also just works. Regards, Rene
Bug#1076720: "Insert symbol" and libreoffice-gtk3
Hi, Am 22.07.24 um 19:51 schrieb Stefano: Which one? Maybe it's even locale-specific? (tried de_DE and en_US here.) it_IT Hmm. Inseirici -> Cattatere speciale... also works here in it_IT.UTF-8 locale. Regards, Rene
Bug#1076720: "Insert symbol" and libreoffice-gtk3
tag 1076720 + moreinfo tag 1076720 + unreproducible thanks Hi, Am 22.07.24 um 15:33 schrieb Stefano Volpe: Package: libreoffice-gtk3 Version: 4:7.4.7-1+deb12u3 When libreoffice-gtk3 is not installed, the "Insert -> Symbols" menu of LibreOffice Writer (4:7.4.7-1+deb12u3) can be opened correctly. When There's none like this afaics. Did you man Insert -> Special Characters? libreoffice-gtk3 is installed, such menu does not open, but no error in printed on the terminal either. Does here. I am on Debian 6.1.99-1 (2024-07-15) i686 GNU/Linux. C library version is 2.36-9+deb12u7. amd64 though (as it should be). In any case, even if it was a bug, stable doesn't get any bugfixes except really important ones. Can you try whether a current 24.2 (as available in backports) works? Regards, Rene
Bug#1076014: RM: python-ooolib -- RoQA; explicitly unmaintained; RC-buggy
Hi, Am 09.07.24 um 17:04 schrieb Bastian Germann: Please remove python-ooolib from unstable. It did not make it to bookworm because RC fixes were actively removed by the only active uploader, who commented on the two RC bugs: "How is it unclear that noone seriously cares about this package? Old upstream version, popcon 4, ignored by the maintainer." So please remove the package. For avoidance of doubt: ACK. Regards, Rene
Bug#1059158: fixed in 4:7.4.7-1+deb12u3, too
# mark bugs fixed in 4:7.4.7-1+deb12u3 correctly, didn't get done # because they were already archived unarchive 1059158 fixed 1059158 4:7.4.7-1+deb12u3 unarchive 1069835 fixed 1069835 4:7.4.7-1+deb12u3
Bug#1071826: bookworm-pu: package libreoffice/4:7.4.7-1+deb12u3
Hi again, Am 17.06.24 um 20:29 schrieb Rene Engelhard: Apologies if I'm missing something, but + - recommend kio >> 5.103.0-1 in -kf5 makes the package uninstallable on a default bookworm setup (i.e. Recommends are installed by APT). apt TTBOMK doesn't complain if a Recommends isn't fullfillable. I also asked on #debian-devel about that because I wasn't sure either. AFAICR I did this in sid before the matching sid Recommendation was in place and no complaints from apt. (Except telling me that "kio" is Recommended) As per our IRC conversation, I'm still very surprised by this. Looks like stable behaves different and/or I implicitely did dist-upgrade on sid anyway because of other stuff, too Just tried: [...] For the record on IRC: 0:33 < adsb> and whether tools tend to do just upgrades or d-u (e.g unattended-upgrades, but also others) 20:33 < _rene_> the ideal way(tm) would just be to make kio do their stuff... 20:35 < _rene_> but if it helps I can back out the recommends. but that probably will make the actual bug in -kf5 still cause havoc 20:36 < _rene_> s/bug in -kf5/bug in kio still cause havoc with -kf5/ 20:43 < _rene_> can't get unattended-upgrades to upgrade from my local (non-signed, non-Release, etc) apt repo to try that one 20:46 < adsb> ah 20:46 < _rene_> ah, there. orgin=* 20:46 < _rene_> Option --dry-run given, *not* performing real actions 20:46 < _rene_> Packages that will be upgraded: fonts-opensymbol libreoffice-base-core libreoffice-calc libreoffice-common libreoffice-core libreoffice-draw libreoffice-gnome libreoffice-gtk3 libreoffice-help-common libreoffice-help-de libreoffice-help-en-us libreoffice-impress libreoffice-kf5 libreoffice-l10n-de libreoffice-math libreoffice-plasma libreoffice-qt5 libreoffice-style-breeze libreoffice-style-colibre 20:46 < _rene_> libreoffice-style-elementary libreoffice-writer libuno-cppu3 libuno-cppuhelpergcc3-3 libuno-purpenvhelpergcc3-3 libuno-sal3 libuno-salhelpergcc3-3 python3-uno uno-libs-private ure 20:46 < _rene_> s/orgin/origin/ 20:46 < adsb> promising 20:46 < _rene_> unatteded-upgrades seems to wrk 20:46 < _rene_> work 20:46 < adsb> I guess we can try it and see what qa tooling does 20:47 < _rene_> so I should upload and we can back out the recommends "in emergency"? 20:47 < adsb> sure 20:47 < _rene_> k 20:47 < adsb> neither way is great, as you say 20:48 < adsb> without the other half of the fix 20:48 < _rene_> didn't want to upload prematurely, even with your "half-ACK" in the bug :) 20:48 < _rene_> better safe than sorry :) 20:49 < adsb> coucouf: were you planning on submitting a p-u request for kio 5.103.0-1+deb12u1? 20:49 < _rene_> they wanted andi to do that 20:50 < _rene_> (fwiw, without --dry-run it actually upgrades all that) 20:50 < _rene_> all that in a clean stable VM 20:50 < adsb> I don't really mind who requests it :) 20:50 * _rene_ neither :) 20:51 < _rene_> Uploading libreoffice_7.4.7-1+deb12u3_source.changes: done. 20:51 < _rene_> Successfully uploaded packages. Regards, Rene
Bug#1071826: bookworm-pu: package libreoffice/4:7.4.7-1+deb12u3
Hi, Am 17.06.24 um 19:05 schrieb Adam D. Barratt: Control: tags -1 -moreinfo +confirmed On Sat, 2024-06-15 at 17:44 +0200, Rene Engelhard wrote: Hi, Am 15.06.24 um 17:28 schrieb Adam D. Barratt: Control: tags -1 + moreinfo On Sat, 2024-05-25 at 10:35 +0200, Rene Engelhard wrote: I'd like to fix 2 libreoffice bugs in stable. Most important is the SMB fix (which - for kf5 - also needs a kio stable update, but those can be done in parallel or kio later as there's no updated (build)-dependency needed. Merely I added a Recommends: for documentation purposes. Apologies if I'm missing something, but + - recommend kio >> 5.103.0-1 in -kf5 makes the package uninstallable on a default bookworm setup (i.e. Recommends are installed by APT). apt TTBOMK doesn't complain if a Recommends isn't fullfillable. I also asked on #debian-devel about that because I wasn't sure either. AFAICR I did this in sid before the matching sid Recommendation was in place and no complaints from apt. (Except telling me that "kio" is Recommended) As per our IRC conversation, I'm still very surprised by this. Looks like stable behaves different and/or I implicitely did dist-upgrade on sid anyway because of other stuff, too Just tried: root@debian12:~# dpkg -l libreoffice-kf5 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-===-=--= ii libreoffice-kf5 4:7.4.7-1+deb12u2 amd64 office productivity suite -- KDE Frameworks 5 integration root@debian12:~# apt upgrade Reading package lists... Done Building dependency tree... Done Reading state information... Done Calculating upgrade... Done The following packages were automatically installed and are no longer required: libwpe-1.0-1 libwpebackend-fdo-1.0-1 Use 'apt autoremove' to remove them. The following packages have been kept back: libreoffice-base-core libreoffice-calc libreoffice-core libreoffice-draw libreoffice-gnome libreoffice-gtk3 libreoffice-impress libreoffice-kf5 libreoffice-math libreoffice-plasma libreoffice-qt5 libreoffice-writer python3-uno The following packages will be upgraded: fonts-opensymbol libreoffice-common libreoffice-help-common libreoffice-help-de libreoffice-help-en-us libreoffice-l10n-de libreoffice-style-breeze libreoffice-style-colibre libreoffice-style-elementary libuno-cppu3 libuno-cppuhelpergcc3-3 libuno-purpenvhelpergcc3-3 libuno-sal3 libuno-salhelpergcc3-3 uno-libs-private ure 16 upgraded, 0 newly installed, 0 to remove and 13 not upgraded. Need to get 54.8 MB of archives. After this operation, 9216 B disk space will be freed. Do you want to continue? [Y/n] ^C root@debian12:~# apt dist-upgrade Reading package lists... Done Building dependency tree... Done Reading state information... Done Calculating upgrade... Done The following packages were automatically installed and are no longer required: libwpe-1.0-1 libwpebackend-fdo-1.0-1 Use 'apt autoremove' to remove them. The following packages will be upgraded: fonts-opensymbol libreoffice-base-core libreoffice-calc libreoffice-common libreoffice-core libreoffice-draw libreoffice-gnome libreoffice-gtk3 libreoffice-help-common libreoffice-help-de libreoffice-help-en-us libreoffice-impress libreoffice-kf5 libreoffice-l10n-de libreoffice-math libreoffice-plasma libreoffice-qt5 libreoffice-style-breeze libreoffice-style-colibre libreoffice-style-elementary libreoffice-writer libuno-cppu3 libuno-cppuhelpergcc3-3 libuno-purpenvhelpergcc3-3 libuno-sal3 libuno-salhelpergcc3-3 python3-uno uno-libs-private ure 29 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 110 MB of archives. After this operation, 50.2 kB of additional disk space will be used. Do you want to continue? [Y/n] ^C root@debian12:~# apt install libreoffice-kf5 Reading package lists... Done Building dependency tree... Done Reading state information... Done The following packages were automatically installed and are no longer required: libwpe-1.0-1 libwpebackend-fdo-1.0-1 Use 'apt autoremove' to remove them. The following additional packages will be installed: fonts-opensymbol libreoffice-base-core libreoffice-calc libreoffice-common libreoffice-core libreoffice-draw libreoffice-gnome libreoffice-gtk3 libreoffice-help-common libreoffice-help-de libreoffice-help-en-us libreoffice-impress libreoffice-l10n-de libreoffice-math libreoffice-plasma libreoffice-qt5 libreoffice-style-breeze libreoffice-style-colibre libreoffice-style-elementary libreoffice-writer libuno-cppu3 libuno-cppuhelpergcc3-3 libuno-purpenvhelpergcc3-3 libuno-sal3 libuno-salhelpergcc3-3 python3-uno u
Bug#1071826: bookworm-pu: package libreoffice/4:7.4.7-1+deb12u3
Hi, Am 15.06.24 um 17:28 schrieb Adam D. Barratt: Control: tags -1 + moreinfo On Sat, 2024-05-25 at 10:35 +0200, Rene Engelhard wrote: I'd like to fix 2 libreoffice bugs in stable. Most important is the SMB fix (which - for kf5 - also needs a kio stable update, but those can be done in parallel or kio later as there's no updated (build)-dependency needed. Merely I added a Recommends: for documentation purposes. Apologies if I'm missing something, but +- recommend kio >> 5.103.0-1 in -kf5 makes the package uninstallable on a default bookworm setup (i.e. Recommends are installed by APT). apt TTBOMK doesn't complain if a Recommends isn't fullfillable. I also asked on #debian-devel about that because I wasn't sure either. AFAICR I did this in sid before the matching sid Recommendation was in place and no complaints from apt. (Except telling me that "kio" is Recommended) But I can back that out, that's for documentation only anyways. Regards, Ren
Bug#1071834: same with zlib
Hi, same with zlib: Package 'zlib', required by 'libxml-2.0', not found (from https://ci.debian.net/packages/i/igraph/testing/amd64/47001876/) Regards, Rene
Bug#1071834: libxml2-dev: missing Depends on liblzma-dev (used by pkg-config file)
Hi, Am 25.05.24 um 14:00 schrieb Rene Engelhard: root@frodo:/# pkg-config --cflags libxml-2.0 Package liblzma was not found in the pkg-config search path. Perhaps you should add the directory containing `liblzma.pc' to the PKG_CONFIG_PATH environment variable Package 'liblzma', required by 'libxml-2.0', not found This is the reason for some/many autopkgtest failures at https://qa.debian.org/excuses.php?package=libxml2 and also means that any package using libxml2-dev without build-depending on anything else pulling it liblzma-dev by chance now FTBFS in unstable... Regards, Rene
Bug#1071834: libxml2-dev: missing Depends on liblzma-dev (used by pkg-config file)
Package: libxml2-dev Severity: serious Version: 2.12.7+dfsg-1 root@frodo:/# dpkg -l | grep lzma ii liblzma5:amd64 5.6.1+really5.4.5-1 amd64XZ-format compression library root@frodo:/# pkg-config --cflags libxml-2.0 Package liblzma was not found in the pkg-config search path. Perhaps you should add the directory containing `liblzma.pc' to the PKG_CONFIG_PATH environment variable Package 'liblzma', required by 'libxml-2.0', not found root@frodo:/# apt install liblzma-dev [...] Installing: liblzma-dev Suggested packages: liblzma-doc Summary: Upgrading: 0, Installing: 1, Removing: 0, Not Upgrading: 0 Download size: 293 kB Space needed: 803 kB / 4844 MB available Get:1 http://deb.debian.org/debian unstable/main amd64 liblzma-dev amd64 5.6.1+really5.4.5-1 [293 kB] Fetched 293 kB in 0s (1580 kB/s) perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), LC_ALL = (unset), LANG = "de_DE.UTF-8" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory debconf: delaying package configuration, since apt-utils is not installed Error: Can not write log (Is /dev/pts mounted?) - posix_openpt (19: No such device) Selecting previously unselected package liblzma-dev:amd64. (Reading database ... 107997 files and directories currently installed.) Preparing to unpack .../liblzma-dev_5.6.1+really5.4.5-1_amd64.deb ... Unpacking liblzma-dev:amd64 (5.6.1+really5.4.5-1) ... Setting up liblzma-dev:amd64 (5.6.1+really5.4.5-1) ... root@frodo:/# pkg-config --cflags libxml-2.0 -I/usr/include/libxml2 If libxml-2.0.pc references liblzma, libxml2-dev needs to Depend on it. Regards, Rene
Bug#1071826: bookworm-pu: package libreoffice/4:7.4.7-1+deb12u3
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: libreoff...@packages.debian.org, k...@packages.debian.org Control: affects -1 + src:libreoffice Hi, I'd like to fix 2 libreoffice bugs in stable. Most important is the SMB fix (which - for kf5 - also needs a kio stable update, but those can be done in parallel or kio later as there's no updated (build)-dependency needed. Merely I added a Recommends: for documentation purposes. [ Reason ] a) #1059158 If using python3-uno, loadComponentFromURL apparently needs the internal libforuilo.so ("formula ui") library to actually open it since it tried to open that one. Unfortunately this file if left out in the -nogui packages because it is*ui.so. (In 32bit packages that is; in 64bit LO due to --enable-mergelibs this is already in a bigger library called libmergedlo.so) b) 1069835 We shouldn't leave people having documents on SMB shares loose their files :-) [ Impact ] a) opening calc files via python3-uno remaining broken b) possible file loss for files on SMB shares [ Tests ] No test coverage. But a) is pretty straightforward abd b) was confirmed that it fixes it by the submitter. [ Risks ] a) would be better fixed by upstream not requiring that but the bug I filed upstream (https://bugs.documentfoundation.org/show_bug.cgi?id=158795) didn't really get any serious attention. b) more SMB surprises can be possible, though I have not seen any since this is in unstable since 24.2.2 is there. (And that exact patch caused a 32bit FTBFS which I backported the fix of which went into 24.2.2~rc1-2 packages and is upstream since 24.2.2 rc2 anyways, too.) [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable [ Changes ] a) see above. It it just excluded from the find which removes *.ui.so. b) patches from upstream applied verbatim (from 24.2.2) [ Other info ] kio needs one update, too for complete fix of 1069835 in libreoffice-kf5. I see https://salsa.debian.org/qt-kde-team/kde/kio/-/commi t/082a2b7e9208a9d0a552049aafd898960fc15998 (debian/patches/fix_cifs_file_locks.patch). According to https://salsa.debian.org/qt-kde-team/kde/kio/-/commit/9db715803c0c87298dbf70644b98a95bb984322c this was already supposed to be "released to bookworm" but I don't see a release.debian.org bug nor the package in p-u either. Debdiff attached. Regards, Renediff -Nru libreoffice-7.4.7/debian/changelog libreoffice-7.4.7/debian/changelog --- libreoffice-7.4.7/debian/changelog 2024-04-01 11:05:27.0 +0200 +++ libreoffice-7.4.7/debian/changelog 2024-05-24 21:06:45.0 +0200 @@ -1,3 +1,18 @@ +libreoffice (4:7.4.7-1+deb12u3) bookworm; urgency=medium + + * debian/patches/Fix-backup-copy-creation-for-files-on-mounted-samba-shares.diff: +as name says, from 24.2.2+ (closes: #1069835) + * debian/patches/fix-32bit-build.diff: as name says; fix 32bit build with +above + + * debian/rules: +- don't remove libforuilo.so in -core-nogui. (closes: #1059158) + It's subsumed in libmerged on 64bit archs anyway which we definitely + need to keep anyway (similar as libuuilo.so). +- recommend kio >> 5.103.0-1 in -kf5 + + -- Rene Engelhard Fri, 24 May 2024 21:06:45 +0200 + libreoffice (4:7.4.7-1+deb12u2) bookworm-security; urgency=high * debian/patches/add-notify-for-script-use.diff: add fix for diff -Nru libreoffice-7.4.7/debian/control libreoffice-7.4.7/debian/control --- libreoffice-7.4.7/debian/control 2024-04-01 11:05:27.0 +0200 +++ libreoffice-7.4.7/debian/control 2024-05-22 18:16:51.0 +0200 @@ -5028,7 +5028,7 @@ ${kf5-qt5-depends}, ${misc:Depends}, ${shlibs:Depends} -Recommends: ${plasma-iconset-dep} +Recommends: kio (>> 5.103.0-1), ${plasma-iconset-dep} Replaces: libreoffice-kde (<< 1:6.1.0~alpha1-1) Section: kde Enhances: libreoffice diff -Nru libreoffice-7.4.7/debian/patches/fix-32bit-build.diff libreoffice-7.4.7/debian/patches/fix-32bit-build.diff --- libreoffice-7.4.7/debian/patches/fix-32bit-build.diff 1970-01-01 01:00:00.0 +0100 +++ libreoffice-7.4.7/debian/patches/fix-32bit-build.diff 2024-05-22 09:46:59.0 +0200 @@ -0,0 +1,54 @@ +From 0f5dfaebd61b9cabbe9762865563c2296ebb0112 Mon Sep 17 00:00:00 2001 +From: Stephan Bergmann +Date: Fri, 8 Mar 2024 08:38:44 +0100 +Subject: [PATCH] Blind fix for Linux 32-bit builds +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +...which, according to +<https://lists.freedesktop.org/archives/libreoffice/2024-March/091666.html> "32 +bit build failure (smb, narrowing)", started to fail with + +> /<>/sal/osl/unx/file.cxx: In fu
Bug#1070888: PLEASE IGNORE
Hi, Am 11.05.24 um 13:45 schrieb Emmanuel Charpentier: In fact, both submission worked, but the second is but a duplicate of the first. My apologies for the noise... No problem, I already merged them. :) (Intestestingly 1070888 only made it to the BTS and not to the mailing list where 1070887 <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070887> did...) Regards, Rene
Bug#1070862: and this looses files
/ Name VersionArchitecture Description +++--==--== ii libpoppler-cpp0t64:amd64 22.12.0-2.2+b1 amd64PDF rendering library (CPP shared library) root@frodo:/# apt remove libpoppler-cpp0t64 The following package was automatically installed and is no longer required: libpoppler126t64 Use 'sudo apt autoremove' to remove it. REMOVING: libpoppler-cpp0t64 Summary: Upgrading: 0, Installing: 0, Removing: 1, Not Upgrading: 0 Freed space: 144 kB Continue? [Y/n] perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), LC_ALL = (unset), LANG = "de_DE.UTF-8" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory Error: Can not write log (Is /dev/pts mounted?) - posix_openpt (19: No such device) (Reading database ... 9615 files and directories currently installed.) Removing libpoppler-cpp0t64:amd64 (22.12.0-2.2+b1) ... Processing triggers for libc-bin (2.38-8) ... root@frodo:/# ls -l /usr/lib/x86_64-linux-gnu/libpoppler-cpp.so* lrwxrwxrwx 1 root root 19 May 10 09:43 /usr/lib/x86_64-linux-gnu/libpoppler-cpp.so -> libpoppler-cpp.so.0 root@frodo:/# The actual library file is gone. root@frodo:/# dpkg -l | grep poppler ii libpoppler-cpp-dev:amd64 24.02.0-2 amd64 PDF rendering library -- development files (CPP interface) ii libpoppler-cpp0v5:amd64 24.02.0-2 amd64 PDF rendering library (CPP shared library) ii libpoppler-dev:amd64 24.02.0-2 amd64 PDF rendering library -- development files ii libpoppler126t64:amd64 22.12.0-2.2+b1 amd64 PDF rendering library ii libpoppler134:amd64 24.02.0-2 amd64 PDF rendering library ii poppler-data 0.4.12-1 all encoding data for the poppler PDF rendering library libpoppler-cpp0v5 is nominally installed, though.. Regards, Rene
Bug#1069835: libreoffice-kf5: documents may get lost on SMB shares
# splt up the LO and kio parts properly clone 1069835 -1 reassign -1 kio retitle -1 kio: Don't leak existing file handles to newly spanwed KIO workers block 1069835 by -1 # LOs part is done, at least for this one. close 1069835 4:24.2.2-1 thanks Am 03.05.24 um 10:54 schrieb Andreas B. Mundt: On Fri, May 03, 2024 at 10:18:22AM +0200, Sune Stolborg Vuorela wrote: On Friday, May 3, 2024 10:06:27 AM CEST you wrote: On Thu, May 02, 2024 at 04:37:30PM +0200, Sune Stolborg Vuorela wrote: […] If it works for you, I'll ask the debian kde maintainers to fix it. It looks like it fixes the libreoffice issue (no modifications applied to libreoffice). With a patched kio package I was not able to reproduce the issue. Replacing just the kio binary package seems to be sufficient. We are going to test a bit more on other setups too. Tested with libreoffice from bookworm-backports: Fixed. Cool. So that means we don't even need the LO part here? The changes needed to libreoffice are already in Debian ( https:// gerrit.libreoffice.org/c/core/+/162935 ) - also by Kevin Ottens who also authored this patch. Great! Yes, that is the one mentioned earlier and fixed in 24.2.2. Cleaning those bugs up and making an own one for kio. Regards, Rene
Bug#1069835: needs a fix in KIO as well
Hi, Am 26.04.24 um 10:02 schrieb Sune Stolborg Vuorela: https://invent.kde.org/frameworks/kio/-/commit/ 45b306dc0653fa42672e8a49afe8f42d24585ed4 is also needed for it to work. Thanks for mentioning this. As talked about on IRC this morning, that commit is only for kf6s kio. So unless that one is backported to kf5 we'd get the fix then if we shipped libreoffice-kf6 and KF6/Plasma6 is what is used. (According to IRC it isn't sure whether this will be backported to kf5. Let's see) Regards, Rene
Bug#1069835: libreoffice-kf5: documents may get lost on SMB shares
Hi, Am 25.04.24 um 18:37 schrieb Andreas B. Mundt: On Thu, Apr 25, 2024 at 05:43:29PM +0200, Rene Engelhard wrote: Am 25.04.24 um 17:03 schrieb Andreas B. Mundt: For now, we traced the issue back to libreoffice-kf5. If this package is removed, neither the document disappears on closing libreoffice nor the popup is shown when 'nobrl' is removed from the mount options. Which doesn't do IO itself though? But maybe the KDE file picker (over kio) does something weird? But saving (ttbomk) isn't done by the file picker itself? I just tried a trixie XFCE desktop and cannot reproduce the issue there. Then I installed KDE and switched the DE. In KDE again the issue is reproducable, removing libreoffice-kf5 makes the problem go away. Installing libreoffice-kf5 again: Issue is back. Shrugs. However, back in XFCE, even with libreoffice-kf5 installed, the issue does not show up. Because in XFCE you don't get the KDE File Picker but the Gtk one. Unless you force kf5, which I don't think you do. The different file chooser GUIs seem to trigger the issue. Interesting. Removing libreoffice-kf5 or switching to XFCE results in a different file chooser, which somehow causes the problem. So the bug is probably not in libreoffice-kf5 … -kf5 does contain the KDE file picker used in LibreOffice. In any case, try with >= 24.2.2 (so sid). If that commit was it (which I somehow doubt, see my previous reply) sid should work. Regards, Rene
Bug#1069835: libreoffice-kf5: documents may get lost on SMB shares
Hi, Am 25.04.24 um 17:03 schrieb Andreas B. Mundt: For now, we traced the issue back to libreoffice-kf5. If this package is removed, neither the document disappears on closing libreoffice nor the popup is shown when 'nobrl' is removed from the mount options. Which doesn't do IO itself though? But maybe the KDE file picker (over kio) does something weird? But saving (ttbomk) isn't done by the file picker itself? There also is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935182 since some time. It looks a bit like the issue found in [2]. Which doesn't touch any KDE stuff either. In fact it caused 32bit builds to fail[1] and I don't know what more regressions this caused. I would be wary of "just" backporting it in a point release... Regards, Rene [1] by relying on internal glibc/kernel types, see https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/blob/libreoffice_24.2.2_rc1-2/patches/fix-32bit-build.diff?ref_type=tags - later updated upstream for https://cgit.freedesktop.org/libreoffice/core/commit/sal/osl/unx/file.cxx?id=434065478d35fe8e144aec916ac06438c0150270
Bug#1069835: libreoffice-kf5: documents may get lost on SMB shares
close 1069835 4:24.2.2-1 forwarded 1069835 https://bugs.documentfoundation.org/show_bug.cgi?id=55004 tag 1069835 + moreinfo thanks Am 25.04.24 um 17:03 schrieb Andreas B. Mundt: Package: libreoffice-kf5 Version? Severity: grave Come on... Not downgrading just yet, but I don't believe it's grave. we run Debian bookworm KDE plasma clients with home directories mounted from an SMB share. From time to time, users reported that Ah, bookworm. You should have mentioned it in Version: libreoffice documents have disappeared completely when closing libreoffice. We were now able to reproduce the issue on both, the current bookworm and bookworm-backports version of libreoffice. Mount an SMB share. I use the following in fstab: //SHARE/DIR /media/share cifs user,nobrl,user=USER,password=PASS 0 0 Open/create an ODT document, write some text, save the file and check it's appearance on the share. Then click Insert → Image and (perhaps with the image still selected in the document) close libreoffice. The file disappears on the share. This is almost always reproducible (we tested multiple SMB servers) if not, just open the file again, insert another image, Ctrl-S, Ctrl-Q, the file is gone! If 'nobrl' is removed from the mount options (but we need it for other programs to work properly), instead of the file disappearing, a popup shows: Error saving the document Untitled 1: Error creating object. Could not create backup copy. This looks like already reported upstream [1]. For now, we traced the issue back to libreoffice-kf5. If this package is removed, neither the document disappears on closing libreoffice nor the popup is shown when 'nobrl' It looks a bit like the issue found in [2]. So fixed in sid? (If I only could update the bookworm backport to 24.2.2+, but given it's sstill stuck behind time_t...) Regards, Rene
Bug#1069554: [Pkg-pascal-devel] Bug#1069554: this is no bug in the package, bug in the script doing the rebuild?
Hi, Am 24.04.24 um 21:35 schrieb Peter B: Why is it bad? The nogui's are lighter dependencies than the gui packages. Exactly. That#s why they should be used in package building for converting stuff. One or the other is needed. Surely better to use the nogui if its available? It is available. As indep builds are not done on armel that it's not available on armel does not really matter :) My point is that you don't need the alternative. Regards, Rene
Bug#1069554: this is no bug in the package, bug in the script doing the rebuild?
Hi Lucas, this is no bug in the package AFAICS. libreoffice-draw-nogui is clearly only in Build-Depends-Indep: Build-Depends: debhelper-compat (= 13), fpc, libgtk2.0-dev, lcl, lcl-qt5, Build-Depends-Indep: libreoffice-draw-nogui, libreoffice-writer, So it's only needed for _all builds. So why would the build-deps be uninstallable on armel? Or do your scripts do full builds and not --binary-arch/-B or whatever applicable? (And yes, that nogui is not available on armel is a deliberate decision. It's dead, and nooone will hopefully want to use it for document conversion. And I don't want to force a full double build on armel.) This bugreport now caused the following "fix" in winff: Build-Depends-Indep: faketime, libreoffice-draw-nogui | libreoffice-draw, libreoffice-writer-nogui | libreoffice-writer, which I consider bad... Regards, Rene
Bug#1069123: RM: libreoffice != 24.3/experimental [armhf ppc64el s390x mips64el riscv64] -- ROM, NVIU; obsolete cruft
Package: ftp.debian.org Hi, The following packages are cruft: $ rmadison -s experimental -S libreoffice | grep -v 24\.2\.3 fonts-opensymbol | 4:102.12+LibO7.5.4~rc2-1 | experimental | all fonts-opensymbol | 4:102.12+LibO7.5.5~rc1-2 | experimental | all fonts-opensymbol | 4:102.12+LibO7.6.3~rc2-1 | experimental | all fonts-opensymbol | 4:102.12+LibO24.2.0~rc2-1 | experimental | all fonts-opensymbol | 4:102.12+LibO24.2.1~rc2-1 | experimental | all gir1.2-lokdocview-0.1| 4:7.5.4~rc2-1 | experimental | mips64el gir1.2-lokdocview-0.1| 4:24.2.1~rc2-1| experimental | riscv64 liblibreoffice-java | 4:7.5.4~rc2-1 | experimental | all liblibreoffice-java | 4:7.5.5~rc1-2 | experimental | all liblibreoffice-java | 4:7.6.3~rc2-1 | experimental | all liblibreoffice-java | 4:24.2.0~rc2-1| experimental | all liblibreoffice-java | 4:24.2.1~rc2-1| experimental | all liblibreofficekitgtk | 4:7.5.4~rc2-1 | experimental | mips64el liblibreofficekitgtk | 4:24.2.1~rc2-1| experimental | riscv64 libofficebean-java | 4:7.5.4~rc2-1 | experimental | mips64el libofficebean-java | 4:7.5.5~rc1-2 | experimental | armhf, ppc64el, s390x libofficebean-java | 4:24.2.1~rc2-1| experimental | riscv64 libreoffice | 4:7.5.4~rc2-1 | experimental | source, mips64el libreoffice | 4:7.5.5~rc1-2 | experimental | source libreoffice | 4:7.6.3~rc2-1 | experimental | source libreoffice | 4:24.2.0~rc2-1| experimental | source libreoffice | 4:24.2.1~rc2-1| experimental | source, riscv64 libreoffice-base | 4:7.5.4~rc2-1 | experimental | mips64el libreoffice-base | 4:24.2.1~rc2-1| experimental | riscv64 libreoffice-base-core| 4:7.5.4~rc2-1 | experimental | mips64el libreoffice-base-core| 4:24.2.1~rc2-1| experimental | riscv64 libreoffice-base-drivers | 4:7.5.4~rc2-1 | experimental | mips64el libreoffice-base-drivers | 4:24.2.1~rc2-1| experimental | riscv64 libreoffice-calc | 4:7.5.4~rc2-1 | experimental | mips64el libreoffice-calc | 4:24.2.1~rc2-1| experimental | riscv64 libreoffice-common | 4:7.5.4~rc2-1 | experimental | all libreoffice-common | 4:7.5.5~rc1-2 | experimental | all libreoffice-common | 4:7.6.3~rc2-1 | experimental | all libreoffice-common | 4:24.2.0~rc2-1| experimental | all libreoffice-common | 4:24.2.1~rc2-1| experimental | all libreoffice-core | 4:7.5.4~rc2-1 | experimental | mips64el libreoffice-core | 4:24.2.1~rc2-1| experimental | riscv64 libreoffice-dev | 4:7.5.4~rc2-1 | experimental | mips64el libreoffice-dev | 4:24.2.1~rc2-1| experimental | riscv64 libreoffice-dev-common | 4:7.5.4~rc2-1 | experimental | all libreoffice-dev-common | 4:7.5.5~rc1-2 | experimental | all libreoffice-dev-common | 4:7.6.3~rc2-1 | experimental | all libreoffice-dev-common | 4:24.2.0~rc2-1| experimental | all libreoffice-dev-common | 4:24.2.1~rc2-1| experimental | all libreoffice-dev-doc | 4:7.5.4~rc2-1 | experimental | all libreoffice-dev-doc | 4:7.5.5~rc1-2 | experimental | all libreoffice-dev-doc | 4:7.6.3~rc2-1 | experimental | all libreoffice-dev-doc | 4:24.2.0~rc2-1| experimental | all libreoffice-dev-doc | 4:24.2.1~rc2-1| experimental | all libreoffice-dev-gui | 4:7.5.4~rc2-1 | experimental | mips64el libreoffice-dev-gui | 4:24.2.1~rc2-1| experimental | riscv64 libreoffice-draw | 4:7.5.4~rc2-1 | experimental | mips64el libreoffice-draw | 4:24.2.1~rc2-1| experimental | riscv64 libreoffice-evolution| 4:7.5.4~rc2-1 | experimental | mips64el libreoffice-evolut
Bug#1069121: RM: libuno-sal3 libuno-cppu3 ibuno-salhelpergcc3-3 libuno-cppuhelpergcc3-3 libuno-purpenvhelpergcc3-3 -- ROM, NBS; obsolete cruft pre-t64
Package: ftp.debian.org Hi, please remove rene@frodo:~$ rmadison -s unstable libuno-sal3 libuno-cppu3 libuno-salhelpergcc3-3 libuno-cppuhelpergcc3-3 libuno-purpenvhelpergcc3-3 libuno-cppu3 | 4:24.2.0-1 | unstable | amd64, arm64, armel, armhf, i386, ppc64el, s390x libuno-cppuhelpergcc3-3 | 4:24.2.0-1 | unstable | amd64, arm64, armel, armhf, i386, ppc64el, s390x libuno-purpenvhelpergcc3-3 | 4:24.2.0-1 | unstable | amd64, arm64, armel, armhf, i386, ppc64el, s390x libuno-sal3 | 4:24.2.0-1 | unstable | amd64, arm64, armel, armhf, i386, ppc64el, s390x libuno-salhelpergcc3-3 | 4:24.2.0-1 | unstable | amd64, arm64, armel, armhf, i386, ppc64el, s390x on all those archs, they all have been renamed for t64. No idea why the auto-decrufter doesn't pick it up. That also makes it possible to remove this cruft: $ rmadison -s unstable -S libreoffice | grep 24\.2\.0 fonts-opensymbol | 4:102.12+LibO24.2.0-1 | unstable | all liblibreoffice-java | 4:24.2.0-1 | unstable | all libreoffice | 4:24.2.0-1 | unstable | source libreoffice-common | 4:24.2.0-1 | unstable | all libreoffice-dev-common | 4:24.2.0-1 | unstable | all libreoffice-dev-doc | 4:24.2.0-1 | unstable | all libreoffice-help-ca | 4:24.2.0-1 | unstable | all libreoffice-help-common | 4:24.2.0-1 | unstable | all libreoffice-help-cs | 4:24.2.0-1 | unstable | all libreoffice-help-da | 4:24.2.0-1 | unstable | all libreoffice-help-de | 4:24.2.0-1 | unstable | all libreoffice-help-dz | 4:24.2.0-1 | unstable | all libreoffice-help-el | 4:24.2.0-1 | unstable | all libreoffice-help-en-gb | 4:24.2.0-1 | unstable | all libreoffice-help-en-us | 4:24.2.0-1 | unstable | all libreoffice-help-es | 4:24.2.0-1 | unstable | all libreoffice-help-et | 4:24.2.0-1 | unstable | all libreoffice-help-eu | 4:24.2.0-1 | unstable | all libreoffice-help-fi | 4:24.2.0-1 | unstable | all libreoffice-help-fr | 4:24.2.0-1 | unstable | all libreoffice-help-gl | 4:24.2.0-1 | unstable | all libreoffice-help-hi | 4:24.2.0-1 | unstable | all libreoffice-help-hu | 4:24.2.0-1 | unstable | all libreoffice-help-id | 4:24.2.0-1 | unstable | all libreoffice-help-it | 4:24.2.0-1 | unstable | all libreoffice-help-ja | 4:24.2.0-1 | unstable | all libreoffice-help-km | 4:24.2.0-1 | unstable | all libreoffice-help-ko | 4:24.2.0-1 | unstable | all libreoffice-help-nl | 4:24.2.0-1 | unstable | all libreoffice-help-om | 4:24.2.0-1 | unstable | all libreoffice-help-pl | 4:24.2.0-1 | unstable | all libreoffice-help-pt | 4:24.2.0-1 | unstable | all libreoffice-help-pt-br | 4:24.2.0-1 | unstable | all libreoffice-help-ru | 4:24.2.0-1 | unstable | all libreoffice-help-sk | 4:24.2.0-1 | unstable | all libreoffice-help-sl | 4:24.2.0-1 | unstable | all libreoffice-help-sv | 4:24.2.0-1 | unstable | all libreoffice-help-tr | 4:24.2.0-1 | unstable | all libreoffice-help-vi | 4:24.2.0-1 | unstable | all libreoffice-help-zh-cn | 4:24.2.0-1 | unstable | all libreoffice-help-zh-tw | 4:24.2.0-1 | unstable | all libreoffice-java-common | 4:24.2.0-1 | unstable | all libreoffice-l10n-af | 4:24.2.0-1 | unstable | all libreoffice-l10n-am | 4:24.2.0-1 | unstable | all libreoffice-l10n-ar | 4:24.2.0-1 | unstable | all libreoffice-l10n-as | 4:24.2.0-1 | unstable | all libreoffice-l10n-ast | 4:24.2.0-1 | unstable | all libreoffice-l10n-be | 4:24.2.0-1 | unstable | all libreoffice-l10n-bg | 4:24.2.0-1 | unstable | all libreoffice-l10n-bn | 4:24.2.0-1 | unstable | all libreoffice-l10n-br | 4:24.2.0-1 | unstable | all libreoffice-l10n-bs | 4:24.2.0-1 | unstable | all libreoffice-l10n-ca | 4:24.2.0-1 | unstable | all libreoffice-l10n-cs | 4:24.2.0-1 | unstable | all libreoffice-l10n-cy | 4:24.2.0-1 | unstable | all libreoffice-l10n-da | 4:24.2.0-1 | unstable | all libreoffice-l10n-de | 4:24.2.0-1 | unstable | all libreoffice-l10n-dz | 4:24.2.0-1 | unstable | all libreoffice-l10n-el | 4:24.2.0-1 | unstable | all libreoffice-l10n-en-gb | 4:24.2.0-1 | unstable | all libreoffice-l10n-en-za | 4:24.2.0-1 | unstable | all libreoffice-l10n-eo | 4:24.2.0-1 | unstable | all libreoffice-l10n-es | 4:24.2.0-1 | unstable | all libreoffice-l10n-et | 4:24.2.0-1 | unstable | all libreoffice-l10n-eu | 4:24.2.0-1 | unstable | all libreoffice-l10n-fa | 4:24.2.0-1 | unstable | all libreoffice-l10n-fi | 4:24.2.0-1 | unstable | all libreoffice-l10n-fr | 4:24.2.0-1 | unstable | all libreoffice-l10n-ga | 4:24.2.0-1 | unstable | all libreoffice-l10n-gd | 4:24.2.0-1 | unstable | all libreoffice-l10n-gl | 4:24.2.0-1 | unstable | all libreoffice-l10n-gu | 4:24.2.0-1 | unstable | all libreoffice-l10n-gug | 4:24.2.0-1 | unstable | all libreoffice-l10n-he | 4:24.2.0-1 | unstable | all libreoffice-l10n-hi | 4:24.2.0-1 | unstable | all libreoffice-l10n-hr | 4:24.2.0-1 | unstable | all libreoffice-l10n-hu | 4:24.2.0-1 | unstable | all libreoffice-l10n-id | 4:24.2.0-1 | unstable | all libreoffice-l10n-in | 4:24.2.0-1 | unstable | all libreoffice-l10n-is | 4:24.2.0-1 | unstable | all libreoffice-l10n-it | 4:24.2.0-1 | unstable | all libreoffice-l10n-ja | 4:24.
Bug#1069120: RM: ure-java libofficebean-java libreoffice-sdbc-hsqldb libreoffice-report-builder libreoffice-report-builder-bin [armhf ppc64el s390x] -- ROM, ANAIS; obsolete cruft
| unstable | all libreoffice-l10n-in | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-is | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-it | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-ja | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-ka | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-kk | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-km | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-kmr | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-kn | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-ko | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-lt | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-lv | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-mk | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-ml | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-mn | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-mr | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-nb | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-ne | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-nl | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-nn | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-nr | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-nso | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-oc | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-om | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-or | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-pa-in | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-pl | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-pt | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-pt-br | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-ro | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-ru | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-rw | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-si | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-sk | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-sl | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-sr | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-ss | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-st | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-sv | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-szl | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-ta | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-te | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-tg | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-th | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-tn | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-tr | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-ts | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-ug | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-uk | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-uz | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-ve | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-vi | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-xh | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-za | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-zh-cn | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-zh-tw | 4:7.5.9~rc1-1 | unstable | all libreoffice-l10n-zu | 4:7.5.9~rc1-1 | unstable | all libreoffice-librelogo | 4:7.5.9~rc1-1 | unstable | all libreoffice-nlpsolver | 4:0.9+LibO7.5.9~rc1-1 | unstable | all libreoffice-report-builder | 4:7.5.9~rc1-1 | unstable | all libreoffice-report-builder-bin | 4:7.5.9~rc1-1 | unstable | armhf, ppc64el, s390x libreoffice-report-builder-bin-nogui | 4:7.5.9~rc1-1 | unstable | armhf, ppc64el libreoffice-script-provider-bsh | 4:7.5.9~rc1-1 | unstable | all libreoffice-script-provider-js | 4:7.5.9~rc1-1 | unstable | all libreoffice-script-provider-python | 4:7.5.9~rc1-1 | unstable | all libreoffice-sdbc-hsqldb | 4:7.5.9~rc1-1 | unstable | armhf, ppc64el, s390x libreoffice-smoketest-data | 4:7.5.9~rc1-1 | unstable | all libreoffice-style-breeze | 4:7.5.9~rc1-1 | unstable | all libreoffice-style-colibre | 4:7.5.9~rc1-1 | unstable | all libreoffice-style-elementary | 4:7.5.9~rc1-1 | unstable | all libreoffice-style-karasa-jaga | 4:7.5.9~rc1-1 | unstable | all libreoffice-style-sifr | 4:7.5.9~rc1-1 | unstable | all libreoffice-style-sukapura | 4:7.5.9~rc1-1 | unstable | all libreoffice-subsequentcheckbase | 4:7.5.9~rc1-1 | unstable | all libreoffice-wiki-publisher | 4:1.2.0+LibO7.5.9~rc1-1 | unstable | all libreofficekit-data | 4:7.5.9~rc1-1 | unstable | all libunoloader-java | 4:7.5.9~rc1-1 | unstable | all python3-access2base | 4:7.5.9~rc1-1 | unstable | all ure-java | 4:7.5.9~rc1-1 | unstable | armhf, ppc64el, s390x Please remove them, too. Nobody references them in sid anymore. Or maybe after the above removal the auto-crufter will be able to do this? Regards, Rene
Bug#1068609: (no subject)
fixed 1068609 4:24.2.2-2 notfixed 1068609 4:24.2.2-3 thanks 4:24.2.2-2 has it fixed of course, not 4:24.2.2-3: libreoffice (4:24.2.2-2) unstable; urgency=medium * debian/patches/split-sdbc-firebird-mariadb.diff: create extra {mysqlc,firebird_sdbc}.xcd as for evoab. Otherwise configuration parts of it ends up (or not in indep builds) in libreoffice-commons main.xcd * debian/rules: - install new {mysqlc,firebird_sdbc}.xcd into the respective packages - build-depend on liborcus-dev (>> 0.19.2-3+b1) as for libxmlsec1-dev * debian/libreoffice-sdbc-{mysql,firebird}.ucf: add * debian/control.in: add Breaks: -sdbc-{mysql,firebird} (<< 4:24.2.2-2) to libreoffice-common -- Rene Engelhard Sat, 30 Mar 2024 09:30:30 + even though -2 was never attempted on armhf due to that build-dep (-3 was built then)
Bug#1068609: failure log for reference
Hi, for the sake of this bug (since it misses the mail history) this is the FTBFS: Test name: testContentGnumeric::TestBody assertion failed - Expression: xServiceInfo->supportsService("com.sun.star.sheet.SpreadsheetDocument") Failures !!! Run: 64 Failure total: 1 Failures: 1 Errors: 0 4:24.2.2-1 build failed with an orcus not rebult for time_t and after that it succeeded (-3 forced an appropriate build-dep) 4:24.2.0-1 from testing now fails in that way after the orcus bin-NMU (0.19.2-3+b2) migrated. Regards, Rene
Bug#1068609: libreoffice: FTBFS on arrmhf: testContentGnumeric assertion failed,- Expression: xServiceInfo->supportsService("com.sun.star.sheet.SpreadsheetDocument")
Source: libreoffice Version: 4:24.2.0-1 Severity: serious Tags: trixie ftbfs Hi, Am 30.03.24 um 12:56 schrieb Rene Engelhard: Am 30.03.24 um 08:49 schrieb Rene Engelhard: That would mean a bin-NMU of liborcus would work and then a rebuild of libreoffice (gb, but I need a new upload anyway) So we probably missed a rename? (Or more for stuff silently using time-date?) boost1.83 (iostream)? liborcus? Both? I prepared a time_t rename of liborcus. Can upload it (to NEW...) any time. A bin-NMU would also work, except for a needed runtime dependency, then again it's "only" the gnumeric filter...). I wouldn't mind a simple bin-NMU at least. That one got done on April 1 :) > Ran the full tests with it. Passed. (Unfortunately) that (expectedly) now causes the reverse issue in testing. Just verified in a local build. Fortunately the startup of LO works fine (tried on my machine here) so it's probably "just" gnumeric (and maybe other gnumeric-using filters) affected. Filing a bug for reference. This is fixed in 4:24.2.2-3, will mark it as such when I get the bug number. Regards, Rene
Bug#1068479: cynically closed by Rene Engelhard (Re: Bug#1068479: libreoffice-writer: space between paragraphs missing in spacing and indentation)
Hi, Am 07.04.24 um 20:59 schrieb José Luis González: Am 06.04.24 um 00:34 schrieb José Luis González: The setting for spacing between paragraphs is missing in the spacing and indentation tab of the paragraph dialog. ? It's definitely there. Format -> Paragraph has spacing "after/before". I meant spacing between paragraphs, not spacing after and before paragraphs. The report was crystal clear. No, it wasn't. The difference, for those who didn't realize is space after paragraph happens always, and between only between them, being the regular separation between paragraphs (the other is formatting, and isn't useful as a substitute because it adds something undesirable at the end of the document or between paragraphs and other kinds of block elements). Aha. Still not RC. You could have replied to my mails, though. As said here and proved by screenshots in en,de and es this is present. Why should anybody provide a screenshot of a feature that is missing? What would be the screenshot of? Vacuum? Read again, I didn't ask for screenshots. Closing this non-bug. The non-bug that should be closed is your brain pretending a RC bug doesn't exist, especially since you fully knew it was a bug, and you closed it just because it bothers you having a RC one in the package. If you don't want to maintain the package leave the position for other who does, and stop ruining Debian's Quality and bothering me. Even if there was a bug it's not RC. From: José Luis González To: sub...@bugs.debian.org Subject: libreoffice-writer: space between paragraphs missing in spacing and indentation Date: Sat, 6 Apr 2024 00:34:12 +0200 X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Package: libreoffice-writer Version: 4:7.4.7-1+deb12u1 Severity: serious The setting for spacing between paragraphs is missing in the spacing and indentation tab of the paragraph dialog. Serious severity because the bug has a major effect on the usability of the package, without rendering it completely unusable, considering paragraphs are a key feature in a word processor, and spacing is something very very basic for them and incredibly necessary. And again: That is the definition of important at most, not serious. Read the bug severities. Regards, Rene
Bug#1068595: libreoffice-writer: insert space missing
tag 1068595 + moreinfo thanks Am 07.04.24 um 20:02 schrieb José Luis González: Space insertion is missing in the insert menu. Huh? What? Normal space is "Space". Non breaking space is Insert -> Formatting Mark -> Non breaking space if you want to use the menu. One can argue that it's not visible enough but that's by no means important. Or what space do you mean? What are you aiming at with your non-bugs? Regards, Rene
Bug#1068479: libreoffice-writer: space between paragraphs missing in spacing and indentation
Hi, Am 06.04.24 um 11:43 schrieb Rene Engelhard: Am 06.04.24 um 11:31 schrieb Rene Engelhard: Am 06.04.24 um 11:11 schrieb Rene Engelhard: See https://people.debian.org/~rene/libreoffice/1068479-works.png Just for avoidance of doubt since the screenshot is in German: [...] And the first part is the indentation: ("Einzug"): - Before - After - First Line Sorry, ignore that one, you were just aiming at the spacing before/after the paragraph, not the indentation (not enough coffee yet). Still, as shown before the spacing before/after the paragraph is there. Regards, Rene
Bug#1068479: libreoffice-writer: space between paragraphs missing in spacing and indentation
Hi again, Am 06.04.24 um 11:11 schrieb Rene Engelhard: Am 06.04.24 um 11:03 schrieb Rene Engelhard: Am 06.04.24 um 00:34 schrieb José Luis González: The setting for spacing between paragraphs is missing in the spacing and indentation tab of the paragraph dialog. ? It's definitely there. Format -> Paragraph has spacing "after/before". See here (yes, from stable): Got lost. See https://people.debian.org/~rene/libreoffice/1068479-works.png Just tried in es_ES.UTF-8 (since that is what your other report used) and C (english) and also there: https://people.debian.org/~rene/libreoffice/1068479-works-es.png https://people.debian.org/~rene/libreoffice/1068479-works-en.png So not reproducible in either spanish or english locale either. Regards, Rene
Bug#1068479: libreoffice-writer: space between paragraphs missing in spacing and indentation
Hi, Am 06.04.24 um 11:31 schrieb Rene Engelhard: Am 06.04.24 um 11:11 schrieb Rene Engelhard: See https://people.debian.org/~rene/libreoffice/1068479-works.png Just for avoidance of doubt since the screenshot is in German: That is the second part "Absatz". First is "above", second is "below" (the paragraph) And the first part is the indentation: ("Einzug"): - Before - After - First Line Regards, Rene
Bug#1068479: libreoffice-writer: space between paragraphs missing in spacing and indentation
Hi again, Am 06.04.24 um 11:11 schrieb Rene Engelhard: Am 06.04.24 um 11:03 schrieb Rene Engelhard: Am 06.04.24 um 00:34 schrieb José Luis González: The setting for spacing between paragraphs is missing in the spacing and indentation tab of the paragraph dialog. ? It's definitely there. Format -> Paragraph has spacing "after/before". See here (yes, from stable): Got lost. See https://people.debian.org/~rene/libreoffice/1068479-works.png Just for avoidance of doubt since the screenshot is in German: That is the second part "Absatz". First is "above", second is "below" (the paragraph) Regards, Rene
Bug#1068479: libreoffice-writer: space between paragraphs missing in spacing and indentation
Hi, Am 06.04.24 um 11:03 schrieb Rene Engelhard: Am 06.04.24 um 00:34 schrieb José Luis González: The setting for spacing between paragraphs is missing in the spacing and indentation tab of the paragraph dialog. ? It's definitely there. Format -> Paragraph has spacing "after/before". See here (yes, from stable): Got lost. See https://people.debian.org/~rene/libreoffice/1068479-works.png Regards, Rene
Bug#1068479: libreoffice-writer: space between paragraphs missing in spacing and indentation
tag 1068479 + moreinfo tag 1068479 + unreproducible severity 1068479 important thanks Hi, Am 06.04.24 um 00:34 schrieb José Luis González: The setting for spacing between paragraphs is missing in the spacing and indentation tab of the paragraph dialog. ? It's definitely there. Format -> Paragraph has spacing "after/before". See here (yes, from stable): Serious severity because the bug has a major effect on the usability of the package, without rendering it completely unusable, considering paragraphs are a key feature in a word processor, and spacing is something very very basic for them and incredibly necessary. Don't overfinflate severities. That is the definition of important "5 important a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone. 6 serious is a severe violation of Debian policy (that is, the problem is a violation of a 'must' or 'required' directive); may or may not affect the usability of the package. Note that non-severe policy violations may be 'normal,' 'minor,' or 'wishlist' bugs. (Package maintainers may also designate other bugs as 'serious' and thus release-critical; however, end users should not do so.). For the canonical list of issues deserving a serious severity you can refer to this webpage: https://release.debian.org/testing/rc_policy.txt . " This matches 5, not 6. And it's unreproducible. Regards, Rene
Bug#1036805: Processed: Severity for 1036805 was serious and we even released with it
severity 1036805 important thanks Hi, > Serious severity because it has a major effect on the usability of the > package without rendering it completely unusable, not minor No, it's not. "serious" has it's own meaning though and that's not it. At most it's important but I don't buy this since as I said back then it looked fine here. And you didn't even reply to the mail. Ignoring the moreinfo tag. Ii's also not the fine style to not CC the actual bug so the text gets actually sent there. Regards, Rene
Bug#1068023: libreoffice: libreoffice does not work under Wayland (no X11) using gtk4
Hi, Also see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977857 Regards, Rene
Bug#1068023: libreoffice: libreoffice does not work under Wayland (no X11) using gtk4
reassign 1068023 libreoffice-gtk4 thanks Hi, Am 29.03.24 um 21:04 schrieb Rene Engelhard: Package: libreoffice if it happens only with gtk4, isn't it better suited at libreoffice-gtk4? I use other gtk applications (e.g. evince, audacity, inkscape, firefox) in this same environment with no problems. But those are gtk3, not gtk4. No idea whether using gtk4 makes a difference here. Regards, Rene
Bug#1068023: libreoffice: libreoffice does not work under Wayland (no X11) using gtk4
Package: libreoffice Version: 4:24.2.0-1 Severity: normal X-Debbugs-Cc: Daniel Kahn Gillmor I have qtwayland5 5.15.10-2+b1 installed. I do not have XWayland installed at all. I'm running from within a Wayland session, using sway 1.9-1 as a compositor. When i try to launch libreoffice using the gtk4 VCLPLUGIN, i get a complaint that it doesn't want to launch because there is no X11 error: ``` 0 dkg@alice:~$ SAL_USE_VCLPLUGIN=gtk4 libreoffice Failed to open display /usr/lib/libreoffice/program/soffice.bin X11 error: Can't open display: Set DISPLAY environment variable, use -display option or check permissions of your X-Server (See "man X" resp. "man xhost" for details) 0 dkg@alice:~$ ``` In this case, no libreoffice session starts up. On the other hand, i get some warnings when using the qt5 plugin, but it actually starts up with no problem: ``` 0 dkg@alice:~$ SAL_USE_VCLPLUGIN=qt5 libreoffice Failed to open display qt.qpa.wayland: Wayland does not support QWindow::requestActivate() qt.qpa.wayland: Wayland does not support QWindow::requestActivate() 0 dkg@alice:~$ ``` I use other gtk applications (e.g. evince, audacity, inkscape, firefox) in this same environment with no problems. --dkg -- Package-specific info: All deployed bundled extensions: All deployed shared extensions: All deployed user extensions: Experimental features enabled: false Installed VCLplugs: Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++----= un libreoffice-gtk3 (no description available) un libreoffice-kf5(no description available) ii libreoffice-qt5 4:24.2.0-1 amd64office productivity suite -- Qt 5 integration Java (javaldx): /usr/lib/jvm/java-17-openjdk-amd64/lib/amd64/client:/usr/lib/jvm/java-17-openjdk-amd64/lib/amd64/server:/usr/lib/jvm/java-17-openjdk-amd64/lib/amd64/native_threads:/usr/lib/jvm/java-17-openjdk-amd64/lib/amd64 Java: http://openoffice.org/2004/java/framework/1.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> file:///usr/lib/jvm/java-17-openjdk-amd64 Configuration filePackage Exists Changed /etc/libreoffice/registry/writer.xcd libreoffice-writer Yes No All deployed bundled extensions: All deployed shared extensions: All deployed user extensions: Experimental features enabled: false Installed VCLplugs: Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++----= un libreoffice-gtk3 (no description available) un libreoffice-kf5(no description available) ii libreoffice-qt5 4:24.2.0-1 amd64office productivity suite -- Qt 5 integration Java (javaldx): /usr/lib/jvm/java-17-openjdk-amd64/lib/amd64/client:/usr/lib/jvm/java-17-openjdk-amd64/lib/amd64/server:/usr/lib/jvm/java-17-openjdk-amd64/lib/amd64/native_threads:/usr/lib/jvm/java-17-openjdk-amd64/lib/amd64 Java: http://openoffice.org/2004/java/framework/1.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> file:///usr/lib/jvm/java-17-openjdk-amd64 Configuration filePackage Exists Changed /etc/libreoffice/registry/calc.xcdlibreoffice-calcYes No All deployed bundled extensions: All deployed shared extensions: All deployed user extensions: Experimental features enabled: false Installed VCLplugs: Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++----= un libreoffice-gtk3 (no description available) un libreoffice-kf5(no description available) ii libreoffice-qt5 4:24.2.0-1 amd64office productivity suite -- Qt 5 integration Java (javaldx): /usr/lib/jvm/java-17-openjdk-amd64/lib/amd64/client:/usr/lib/jvm/java-17-openjdk-amd64/lib/amd64/server:/usr/lib/jvm/java-17-openjdk-amd64/lib/amd64/native_threads:/usr/lib/jvm/java-17-openjdk-amd64/lib/amd64 Java: http://openoffice.org/2004/java/framework/1.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> file:///usr/lib/jvm/java-17-openjdk-amd64 Configuration filePackage Exists Changed /etc/libreoffice/registry/base.xcdlibreoffice-b
Bug#970021: Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)
Hi, Am 25.03.24 um 19:17 schrieb Julian Gilbey: * Reading and writing file formats (like CSV, Apache ORC, and Apache Parquet) liborcus supports this (Apache Parquet) if built with Apache Arrow. And thus makes LibreOffice being able to handle it. I didn't invest any time in Apache Arrow since I am already too low on time anyway and I deemed it too a "low popularity" thing anyway. So this is a plea for anyone looking for something really helpful to do: it would be great to have a group of developers finally package this! Indeed. There was some initial work done (see the RFP bug report for details: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970021), but that is fairly old now. As Apache Arrow supports numerous languages, it may well benefit from having a group of developers with different areas of expertise to build it. (Or perhaps it would make more sense to split the upstream source into a collection of different Debian source packages for the different supported languages. I don't know.) Would definitely make transitions easier. Unfortunately I don't have the capacity to devote any time to it myself. Dito. Regards, Rene
Bug#1058545: due to #1058653
block 1058545 by 1058653 tag 1058545 + patch thanks Hi, This is due to > dh_installdocs: error: Cannot find (any matches for) "doc/Esnacc.pdf" (tried in .) which is due to (cd /home/rene/esnacc-1.8.1/doc && unzip eSNACCManuals.zip && libreoffice --headless --convert-to pdf Esnacc.doc) Archive: eSNACCManuals.zip inflating: EsnaccOriginalMaterial.doc inflating: Esnacc.doc Warning: failed to launch javaldx - java may not function correctly Error: source file could not be loaded (the last message is it, the javaldx warning is harmless) failing. Which is due to a bug in libreoffice which is fixed by libreoffice (4:24.2.0-2) experimental; urgency=medium * debian/patches/sw-do-not-require-cui.diff: do not require cui in sw, from upstream (closes: #1058653) which is fixed but (well, it's followers) are held up by the time_t transition. (So this bug is not there anymore when building in sid) Workaround (as other packages did) is to build-deped on libreoffice-writer for now (instead of libreoffice-writer-nogui). Or just wait until said fix is in testing (whenever that may be) Regards, Rene
Bug#1066970: FTBFS: error: implicit declaration of function 'InitNibbleMem' [-Werror=implicit-function-declaration]
Source: esnacc Version: 1.8.1-3 Severity: serious Justification: FTBFS Tags: sid ftbfs User: lu...@debian.org Usertags: ftbfs-impfuncdef Hi, esnacc FTBFS: gcc -DHAVE_CONFIG_H -I. -Wdate-time -D_FORTIFY_SOURCE=2 -I./asn1specs -I./asn1specs -I./c-lib/inc -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/home/rene/esnacc-1.8.1=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -O0 -Wall -Wextra -c -o c-examples/simple/sbuf-sbuf-ex.o `test -f 'c-examples/simple/sbuf-ex.c' || echo './'`c-examples/simple/sbuf-ex.c /bin/bash ./libtool --tag=CC --mode=link gcc -I./asn1specs -I./asn1specs -I./c-lib/inc -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/home/rene/esnacc-1.8.1=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -O0 -Wall -Wextra -Wl,-z,relro -o c-examples/simple/sbuf asn1specs/c_examples_simple_sbuf-p-rec.o c-examples/simple/sbuf-sbuf-ex.o c-lib/libcasn1.la -lm libtool: link: gcc -I./asn1specs -I./asn1specs -I./c-lib/inc -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/home/rene/esnacc-1.8.1=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -O0 -Wall -Wextra -Wl,-z -Wl,relro -o c-examples/simple/.libs/sbuf asn1specs/c_examples_simple_sbuf-p-rec.o c-examples/simple/sbuf-sbuf-ex.o c-lib/.libs/libcasn1.so -lm -pthread gcc -DHAVE_CONFIG_H -I. -Wdate-time -D_FORTIFY_SOURCE=2 -I./c-lib/inc -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/home/rene/esnacc-1.8.1=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -O0 -Wall -Wextra -c -o c-examples/test-lib/testlib-test-lib.o `test -f 'c-examples/test-lib/test-lib.c' || echo './'`c-examples/test-lib/test-lib.c c-examples/test-lib/test-lib.c: In function 'main': c-examples/test-lib/test-lib.c:68:5: error: implicit declaration of function 'InitNibbleMem' [-Werror=implicit-function-declaration] 68 | InitNibbleMem (256, 256); | ^ [...] This is most likely caused by a change in dpkg 1.22.6, that enabled -Werror=implicit-function-declaration. For more information, see https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration Indeed a build with export DEB_BUILD_MAINT_OPTIONS=qa=-bug-implicit-func works. But better than disabling it would be to fix it of course ;) Regards, Rene
Bug#1066473: multitail: FTBFS: mt.c:707:25: error: implicit declaration of function ‘waddnwstr’; did you mean ‘waddnstr’? [-Werror=implicit-function-declaration]
tag 1066473: + pending thanks Hi, Am 13.03.24 um 12:53 schrieb Lucas Nussbaum: During a rebuild of all packages in sid, your package failed to build on amd64. Interesting. I almost wanted to tag it unreproducible since it didn't happen in my already-existing chroot... But it definitely does fail in cowbuilder build <.dsc> :/ Nope. Just works here. Yes, with dpkg-dev 1.22.6. In a manual chroot I have here and upgraded and in a cowbuilder build multitail_6.5.0-1.dsc Relevant part (hopefully): cc -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wall -Wno-unused-parameter -funsigned-char -O3 -DLinux -DVERSION=\"6.5.0\" -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -DCONFIG_FILE=\"/etc/multitail.conf\" -MMD -MP -DUTF8_SUPPORT -c -o mt.o mt.c mt.c: In function ‘do_color_print’: mt.c:707:25: error: implicit declaration of function ‘waddnwstr’; did you mean ‘waddnstr’? [-Werror=implicit-function-declaration] 707 | waddnwstr(win -> win, &wcur, 1); | ^ | waddnstr mt.c: In function ‘update_statusline’: mt.c:1467:126: warning: format ‘%lld’ expects argument of type ‘long long int’, but argument 5 has type ‘off64_t’ {aka ‘long int’} [-Wformat=] 1467 | mvwprintw(status -> win, 0, win_width - (strlen(timestamp) + cur_len), "%10lld - %s", fsize, timestamp); | ~^~ | || | |off64_t {aka long int} | long long int | %10ld cc1: some warnings being treated as errors make[2]: *** [: mt.o] Error 1 Actually upstream has #if defined(UTF8_SUPPORT) && defined(NCURSES_WIDECHAR) // FIXME warning: implicit declaration of function �~@~Xwaddnwstr�~@~Y is invalid in C99 [-Wimplicit-function-declaration] // see /usr/include/ncurses.h waddnwstr(win -> win, &wcur, 1); #else wprintw(win -> win, "%c", wcur); #endif so is aware... Actually (thanks to discussion on IRC) it seems that CPPFLAGS:=$(shell pkg-config --cflags ncurses) NCURSES_LIB:=$(shell pkg-config --libs ncurses) is empty even though it shouldn't be. So fix is to add that missing build-dep. Regards, Rene
Bug#1065893: libreoffice: Please drop dependencies on python3-distutils
Hi again, Am 10.03.24 um 19:59 schrieb Rene Engelhard: BTW, What is the replacement for it? setuptools._distutils? As in the following patch? OK, so discussion on IRC gave: 19:51 < tumbleweed> _rene_: distutils is removed in 3.12 19:51 < tumbleweed> if you need distutils, try installing setuptools, it provides a distutils shim 20:00 < _rene_> setuptools._distutils, yes 20:00 < _rene_> but yet import distutils works in 3.12 :) 20:00 < _rene_> and afaicr from debconf in kochi we didn't want to force distutils removal yet for python3.12-as-default, only after it? 20:03 < _rene_> tumbleweed: does https://www.rene-engelhard.de/~rene/d look sane? 20:04 < tumbleweed> _rene_: yes, it works because setuptools provide a shim to make it work 20:04 < _rene_> (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065893#19) 20:04 -zwiebelbot:#debian-release- Debian#1065893: libreoffice: Please drop dependencies on python3-distutils - https://bugs.debian.org/1065893 20:05 < tumbleweed> just build-depend on python3-setuptools and you don't need the rest of your patch 20:05 < _rene_> I see, ok 20:05 < tumbleweed> obviously upstream should stop using distutils, but you've got time there 20:06 < tumbleweed> the answer isn't to use setuptools._distutils, but rather sysconfig 20:06 < _rene_> should have been in the bugreport 20:07 < tumbleweed> fwiw, the bof notes say: https://salsa.debian.org/debconf-team/public/data/dc23/-/blob/main/etherpad/txt/27-python-bof.txt#L20 20:10 < _rene_> hmm, indeed. but dh-python already does that. 20:10 < tumbleweed> the problem for you was more than just a dependency 20:10 < _rene_> so if it provided a shim to make plain import distutils work one could just make it Provides: python3-disturils 20:10 < _rene_> distutils 20:11 < _rene_> aka make the real package virtual and stuff continues to work 20:11 < tumbleweed> err, what am I saying 20:11 < tumbleweed> did you try just dropping the dependency on python3-distutils? 20:11 < _rene_> I can't remove it from the disk due to everything python'ish being removed, too with it 20:12 < _rene_> The following packages will be REMOVED: dh-python python3-dev python3-distutils python3-setuptools 20:12 -!- andibmu [~a...@i5387a7d5.versanet.de] has joined #debian-release 20:12 < tumbleweed> I mean from your build-depends so you don't get in your build chroot 20:13 < _rene_> how does that help if I still need dh-python and python3-dev? (and gobject-introspection) 20:13 < tumbleweed> they don't need distutils. Nothing does in 3.12 20:13 < _rene_> just now doing it in a chroot where I can do stuff and do a manual debuild -Pnogir 20:13 < _rene_> why does dh-python and python3-dev then get removed on apt remove python3-distutils? 20:14 < _rene_> (and the gobject-introspection stuff.) 20:15 < tumbleweed> oh, right, dh-python does still depend on it 20:15 < tumbleweed> fine. As long as you drop *your* dependency, we should be OK when everyone else drops theirs 20:15 < _rene_> and apt -t experimental install python3-dev also does 20:15 < _rene_> The following NEW packages will be installed: python3-dev python3-distutils 20:16 < tumbleweed> that's OK so just exchanging the build-dep would be fine. You could have just said so in the report for people who are not that into python stuff. Will be fixed in next experimental upload. Regards, Rene
Bug#1065893: libreoffice: Please drop dependencies on python3-distutils
Hi, Am 10.03.24 um 19:44 schrieb Rene Engelhard: and similar stuff in upstreams configure. python_include=`$PYTHON -c "import distutils.sysconfig; print(distutils.sysconfig.get_config_var('INCLUDEPY'));"` python_version=`$PYTHON -c "import distutils.sysconfig; print(distutils.sysconfig.get_config_var('VERSION'));"` python_libs=`$PYTHON -c "import distutils.sysconfig; print(distutils.sysconfig.get_config_var('LIBS'));"` python_libdir=`$PYTHON -c "import distutils.sysconfig; print(distutils.sysconfig.get_config_var('LIBDIR'));"` to be precise. BTW, What is the replacement for it? setuptools._distutils? As in the following patch? diff --git a/changelog b/changelog index 968af9a3b..9d16707d6 100644 --- a/changelog +++ b/changelog @@ -1,3 +1,10 @@ +libreoffice (4:24.2.2~rc1-3) UNRELEASED; urgency=medium + + * debian/patches/distutils-is-obsolete.diff, debian/rules: use + setuptools._distutils instead of distutils (closes: #1065893) + + -- Rene Engelhard Sun, 10 Mar 2024 19:57:14 +0100 + libreoffice (4:24.2.2~rc1-2) experimental; urgency=medium * debian/patches/fix-32bit-build.diff: as name says; from upstream diff --git a/patches/series b/patches/series index 75a4f68d2..47b80676f 100644 --- a/patches/series +++ b/patches/series @@ -50,3 +50,4 @@ fix-system-abseil-build.diff fix-riscv64-bridge.diff pdfium-ports.diff fix-32bit-build.diff +distutils-is-obsolete.diff diff --git a/rules b/rules index aa981c5b1..a47940395 100755 --- a/rules +++ b/rules @@ -1086,7 +1086,7 @@ ifeq "$(ENABLE_PYTHON)" "y" PYMAJOR:=$(shell $(PYTHON) -c "import sys; print (sys.version_info[0])") PYMINOR:=$(shell $(PYTHON) -c "import sys; print (sys.version_info[1])") PYMINORPLUS1:=$(shell $(PYTHON) -c "import sys; print (sys.version_info[1]+1)") -PYTHON_SITE:=debian/python3-uno/$(shell $(PYTHON) -c 'from distutils import sysconfig; print(sysconfig.get_python_lib())') +PYTHON_SITE:=$(shell $(PYTHON) -c 'from setuptools._distutils import sysconfig; print(sysconfig.get_python_lib())') endif BUILD_DEPS += , $(PYTHON) @@ -2953,9 +2953,9 @@ else endif ifeq "$(PACKAGE_BASE)" "y" - mkdir -p debian/python3-access2base/$(shell $(PYTHON) -c 'from distutils import sysconfig; print(sysconfig.get_python_lib())') + mkdir -p debian/python3-access2base/$(PYTHON_SITE) } mv $(PKGDIR)-common/$(OODIR)/program/access2base.py \ - debian/python3-access2base/$(shell $(PYTHON) -c 'from distutils import sysconfig; print(sysconfig.get_python_lib())') + debian/python3-access2base/$(PYTHON_SITE) else rm -rf $(PKGDIR)-common/$(OODIR)/share/basic/Access2Base t=`mktemp -q`; grep -v Access2Base $(PKGDIR)-common/$(OODIR)/share/basic/dialog.xlc > \ @@ -2966,9 +2966,9 @@ else endif # ScriptForge - mkdir -p debian/python3-scriptforge/$(shell $(PYTHON) -c 'from distutils import sysconfig; print(sysconfig.get_python_lib())') + mkdir -p debian/python3-scriptforge/$(PYTHON_SITE) \ mv $(PKGDIR)-common/$(OODIR)/program/scriptforge.py \ - debian/python3-scriptforge/$(shell $(PYTHON) -c 'from distutils import sysconfig; print(sysconfig.get_python_lib())') + debian/python3-scriptforge/$(PYTHON_SITE) ifeq "$(PACKAGE_SDK)" "y" # move gengal stuff into -dev-gui @@ -3354,16 +3354,16 @@ endif ifeq "$(ENABLE_PYTHON)" "y" # PyUNO packaging - install -d $(PYTHON_SITE) + install -d debian/python3-uno/$(PYTHON_SITE) # prepend stuff so that it works when the module is not in LOs # directories but in $(PYTHON_SITE). Can't be a patch (anymore) # as otherwise the python-based unittests fail miserably. - echo "import sys, os" > $(PYTHON_SITE)/uno.py - echo "sys.path.append('/$(OODIR)/program')" >> $(PYTHON_SITE)/uno.py - echo "os.putenv('URE_BOOTSTRAP', 'vnd.sun.star.pathname:/$(OODIR)/program/fundamentalrc')" >> $(PYTHON_SITE)/uno.py - cat debian/python3-uno/$(OODIR)/program/uno.py >> $(PYTHON_SITE)/uno.py + echo "import sys, os" > debian/python3-uno/$(PYTHON_SITE)/uno.py + echo "sys.path.append('/$(OODIR)/program')" >> debian/python3-uno/$(PYTHON_SITE)/uno.py + echo "os.putenv('URE_BOOTSTRAP', 'vnd.sun.star.pathname:/$(OODIR)/program/fundamentalrc')" >> debian/python3-uno/$(PYTHON_SITE)/uno.py + cat debian/python3-uno/$(OODIR)/program/uno.py >> debian/python3-uno/$(PYTHON_SITE)/uno.py rm -f debian/python3-uno/$(OODIR)/program/uno.py - mv debian/python3-uno/$(OODIR)/program/unohelper.py $(PYTHON_SITE) + mv debian/python3-uno/$(OODIR)/program/unohelper.py d
Bug#1065893: libreoffice: Please drop dependencies on python3-distutils
tag 1065893 - ftbfs tag 1065893 + moreinfo thanks Hi, Am 10.03.24 um 18:49 schrieb Graham Inggs: Severity: important Tags: ftbfs Nope. As demonstrated below it does NOT FTBFS if I ran it to the end. Actually did once. This package has dependencies, build-dependencies and/or autopkgtest dependencies on python3-distutils. The python3-distutils binary package will soon be dropped from python3-stdlib-extensions. # apt remove python3-distutils Reading package lists... Done Building dependency tree... Done Reading state information... Done The following packages were automatically installed and are no longer required: gir1.2-girepository-2.0 gir1.2-girepository-2.0-dev libgirepository-1.0-1 libjs-jquery libjs-sphinxdoc libjs-underscore libpython3-dev libpython3.11-dev python3-lib2to3 python3-mako python3-markdown python3-markupsafe python3-pkg-resources python3.11-dev Use 'sudo apt autoremove' to remove them. The following packages will be REMOVED: dh-python gobject-introspection gobject-introspection-bin libgirepository-1.0-dev libgirepository1.0-dev python3-dev python3-distutils python3-setuptools 0 upgraded, 0 newly installed, 8 to remove and 0 not upgraded. After this operation, 5736 kB disk space will be freed. Do you want to continue? [Y/n] and dh-python gobject-introspection libgirepository1.0-dev python3-dev are definitely needed as build -dependencies- In fact, there is no module for Python 3.12 in python3-distutils, so these dependencies may already be unnecessary. Wrong. both debian/rules and LibreOffices configure use distutils to figure out the module install directory path for example. e.g. PYTHON_SITE:=debian/python3-uno/$(shell $(PYTHON) -c 'from distutils import sysconfig; print(sysconfig.get_python_lib())') and similar stuff in upstreams configure. And that one is not done on 3.12 yet since LibreOffice (for reasons!) only builds for default python. Which is 3.11. After install python3 python3-dev from experimental (so 3.12): $ python3 Python 3.12.2 (main, Feb 25 2024, 17:51:42) [GCC 13.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import distutils; >>> from distutils import sysconfig; print(sysconfig.get_python_lib()) /usr/lib/python3/dist-packages >>> print(distutils) (/usr/lib/python3/dist-packages/setuptools/_distutils/__init__.py)> >>> and doing a libreoffice build with debuild -Pnogir (since we need gobject-introspection etc. which isn't yet built for default 3.12 either): $ debuild -Pnogir [...] checking for a Python interpreter with version >= 3.3... python3 checking for python3... /usr/bin/python3 checking for python3 version... 3.12 checking for python3 platform... linux checking for GNU default python3 prefix... ${prefix} checking for GNU default python3 exec_prefix... ${exec_prefix} checking for python3 script directory (pythondir)... ${PYTHON_PREFIX}/lib/python3.12/site-packages checking for python3 extension module directory (pyexecdir)... ${PYTHON_EXEC_PREFIX}/lib/python3.12/site-packages [...] in upstreams configure. I think this bugreport is too early. Regards, Rene
Bug#1065461: libreoffice-common: disabling libreoffice-evolution has moved evolocal.odb to libreoffice-common
Hi, Am 05.03.24 um 00:47 schrieb Andreas Beckmann: Preparing to unpack .../libreoffice-common_4%3a24.2.1-3_all.deb ... Unpacking libreoffice-common (4:24.2.1-3) over (4:24.2.0-1) ... dpkg: error processing archive /var/cache/apt/archives/libreoffice-common_4%3a24.2.1-3_all.deb (--unpack): trying to overwrite '/usr/lib/libreoffice/presets/database/evolocal.odb', which is also in package libreoffice-evolution 4:24.2.0-1 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) rmdir: failed to remove '/var/lib/libreoffice/share/prereg/': No such file or directory rmdir: failed to remove '/var/lib/libreoffice/share/': No such file or directory rmdir: failed to remove '/var/lib/libreoffice/program/': No such file or directory rmdir: failed to remove '/var/lib/libreoffice': No such file or directory rmdir: failed to remove '/var/lib/libreoffice': No such file or directory Errors were encountered while processing: /var/cache/apt/archives/libreoffice-common_4%3a24.2.1-3_all.deb I'm not sure whether Breaks+Replaces are the correct solution here, or whether -common should rather not ship the file regardless of (not) building -evolution ... The latter, imho. ifeq "$(ENABLE_EVO2)" "y" mkdir -p $(PKGDIR)-evolution/$(OODIR)/presets/database mkdir -p $(PKGDIR)-evolution/$(OODIR)/share/registry mv $(PKGDIR)-common/$(OODIR)/presets/database/evolocal.odb \ $(PKGDIR)-evolution/$(OODIR)/presets/database else rm -f $(PKGDIR)-common/$(OODIR)/presets/database/evolocal.odb endif Added the else part just now. If you add B+R now, you will also need to add them in the opposite direction once -evolutions gets reenabled. libphonenumber is fixed now, so I can re-enable it now and not have it blocking builds. But I need to do the Replaces: libreoffice-common in -evolution anyways now? Regards, Rene
Bug#1065447: unneeded libreoffice Build-Depends (libreoffice, ure-java, default-jre), -writer and -calc are enough
Source: winff Severity: normal Hi, I just noticed winff - thanks to your bug report :): I see winff (1.6.2+dfsg-2) unstable; urgency=medium * Temporary home directory to run soffice (Closes: #759980) * Build dependencies (for javaldx) * Escape Dollar signs in file names (Closes: #1053373) -- Peter Blackman Thu, 05 Oct 2023 10:00:00 +0100 in the changelog and chekced. Because that looked extremely fishy. It is. Build-Depends-Indep: libreoffice, ure-java, default-jre, What for? a) The javaldx warning is harmless unless you do run Java stuff. Which you don't if you convert stuff to pdf. You can just ignore this and you don't need to depend on Java stuff (which is not available on all archs)[1] b) I don't believe you need libreoffice-base etc which gets pulled in by the libreoffice *metapackage*. rene@frodo:~/winff-1.6.3+dfsg/winff/docs$ ls *.od? WinFF.ca.odt WinFF.es_AR.odg WinFF.nl.odt WinFF.en.odt WinFF.fr.odt WinFF.pt_BR.odt So you just need libreoffice-writer and libreoffice-draw. Tried in a local build with libreoffice-writer and -draw 4:24.2.1-3. (Actually libreoffice-writer-nogui and libreoffice-draw-nogui would suffice but the fix for #1058653 is blocked by t64 transition. So let's ignore that for now.) Patch: diff -Nru winff-1.6.3+dfsg/debian/changelog winff-1.6.3+dfsg/debian/changelog --- winff-1.6.3+dfsg/debian/changelog 2024-02-19 14:00:00.0 +0100 +++ winff-1.6.3+dfsg/debian/changelog 2024-03-04 21:50:28.0 +0100 @@ -1,3 +1,10 @@ +winff (1.6.3+dfsg-1.1) UNRELEASED; urgency=medium + + * only build-depend on needed libreoffice-draw, libreoffice-writer; +remove extraneous libreoffice, ure-java, default-jre + + -- Rene Engelhard Mon, 04 Mar 2024 20:50:28 + + winff (1.6.3+dfsg-1) unstable; urgency=medium * New Upstream release (Closes: #1053373) (Closes: #1061586) diff -Nru winff-1.6.3+dfsg/debian/control winff-1.6.3+dfsg/debian/control --- winff-1.6.3+dfsg/debian/control 2023-10-04 22:29:34.0 +0200 +++ winff-1.6.3+dfsg/debian/control 2024-03-04 21:50:28.0 +0100 @@ -10,9 +10,8 @@ lcl, lcl-qt5, Build-Depends-Indep: - libreoffice, - ure-java, - default-jre, + libreoffice-draw, + libreoffice-writer, Standards-Version: 4.6.2 Rules-Requires-Root: no Vcs-Browser: https://salsa.debian.org/pascal-team/winff Regards, Rene [1] _all is Built on amd64 anyways, but still.
Bug#1065448: libreoffice-common: soffice builds of pdf files are unreproducible
forwarded 1065448 https://bugs.documentfoundation.org/show_bug.cgi?id=160033 thanks Hi, Am 04.03.24 um 21:58 schrieb Rene Engelhard: Package: libreoffice-common Version: 4:24.2.0-1 Severity: normal Tags: upstream Then you should have filed it upstream :). Didn't write the reportbug text for no reason :) Did now: https://bugs.documentfoundation.org/show_bug.cgi?id=160033 When creating pdf files from odt files, soffice writes a CreationDate field which contains the actual build date/time. This varies with every build. For an example, see the bottom of https://tests.reproducible-builds.org/debian/rb-pkg/trixie/amd64/diffoscope-results/winff.html soffice could use the creation date of the input odt file, or even SOURCE_DATE_EPOCH instead of the current system date. I think there wven was an option to actually not export this at all (or I misremember) but it's probably not exposed to --convert-to etc. unless extra configuration. Anyway, forwarded. Regards, Rene
Bug#1065448: libreoffice-common: soffice builds of pdf files are unreproducible
Package: libreoffice-common Version: 4:24.2.0-1 Severity: normal Tags: upstream X-Debbugs-Cc: pe...@pblackman.plus.com Dear Maintainer, When creating pdf files from odt files, soffice writes a CreationDate field which contains the actual build date/time. This varies with every build. For an example, see the bottom of https://tests.reproducible-builds.org/debian/rb-pkg/trixie/amd64/diffoscope-results/winff.html soffice could use the creation date of the input odt file, or even SOURCE_DATE_EPOCH instead of the current system date. Regards, Peter -- Package-specific info: Configuration file Package Exists Changed /etc/libreoffice/registry/Langpack-en-US.xcd libreoffice-common Yes No /etc/libreoffice/registry/lingucomponent.xcd libreoffice-common Yes No /etc/libreoffice/registry/main.xcd libreoffice-common Yes No /etc/libreoffice/registry/pdfimport.xcd libreoffice-common Yes No /etc/libreoffice/registry/res/fcfg_langpack_e libreoffice-common Yes No /etc/libreoffice/registry/xsltfilter.xcd libreoffice-common Yes No -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.15-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libreoffice-common depends on: ii libnumbertext-data 1.0.11-4 ii libreoffice-style-colibre 4:24.2.0-1 ii libreoffice-uiconfig-common 4:24.2.0-1 ii ucf 3.0043+nmu1 ii ure 4:24.2.0-1 Versions of packages libreoffice-common recommends: ii apparmor 3.0.12-1+b2 ii fonts-liberation 1:2.1.5-3 ii libexttextcat-data 3.4.7-1 ii poppler-data 0.4.12-1 ii python3-uno 4:24.2.0-1 ii xdg-utils 1.1.3-4.1 Versions of packages libreoffice-common suggests: ii libreoffice-style-colibre [libreoffice-style] 4:24.2.0-1 pn python3-scriptforge -- no debconf information
Bug#1065321: lasso: unfullfillable Build-Depends (unneeded explicit Build-Depends on libxmlsec1-openssl)
Hi, Am 02.03.24 um 18:42 schrieb Rene Engelhard: So as this library is now libxmlsec1t64-openssl this Build-Depends: is now unfullfillable. At least for 32bit archs like armel/armhf (which don't have Provides: libxmlsec1-openssl) or a future package-named package due to ABI changes (like when we ever updated to 1.3.x) Regards, Rene
Bug#1065321: lasso: unfullfillable Build-Depends (unneeded explicit Build-Depends on libxmlsec1-openssl)
Source: lasso Severity: serious Version: 2.8.2-1 Tags: patch User: debian-...@lists.debian.org Usertags: time-t Hi, I just saw lasso has libxmlsec1-dev, libxmlsec1-openssl, in Build-Depends. What for? If this was versioned this could be understandable, but it isn't. And given libxmlsec1-dev pulls in all the variants since xmlsec1 (1.2.9-2) unstable; urgency=low * Add engine libraries to depends of dev package * Switch to mozilla libs provided by xulrunner package (Closes: #364382) * Confirm Debian standards 3.7.2 -- John V. Belmonte Thu, 08 Jun 2006 21:52:55 -0400 - so for anything relevant - this is not needed. So as this library is now libxmlsec1t64-openssl this Build-Depends: is now unfullfillable. Patch is trivial: remove that line :) Regards, Rene
Bug#1064890: [xml/sgml-pkgs] Bug#1064890: libxmlsec1-dev, libxmlsec1-doc: both ship /usr/share/doc/libxmlsec1-dev/examples/*
Hi, Am 27.02.24 um 11:43 schrieb Andreas Beckmann via debian-xml-sgml-pkgs: Package: libxmlsec1-dev,libxmlsec1-doc Version: 1.2.39-2 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package failed to install because it tries to overwrite other packages files. From the attached log (scroll to the bottom...): Preparing to unpack .../libxmlsec1-doc_1.2.39-2_all.deb ... Unpacking libxmlsec1-doc (1.2.39-2) ... dpkg: error processing archive /var/cache/apt/archives/libxmlsec1-doc_1.2.39-2_all.deb (--unpack): trying to overwrite '/usr/share/doc/libxmlsec1-dev/examples/Makefile', which is also in package libxmlsec1-dev 1.2.39-2 Errors were encountered while processing: /var/cache/apt/archives/libxmlsec1-doc_1.2.39-2_all.deb These files are in conflict: usr/share/doc/libxmlsec1-dev/examples/Makefile *sigh*. debuild -A installs into -doc debuild -B installs into -dev -> boom Compared to sid: rene@frodo:~$ dpkg -L libxmlsec1-dev | grep examples > dev rene@frodo:~$ dpkg -L libxmlsec1-doc | grep examples > doc rene@frodo:~$ diff -u dev doc --- dev 2024-02-27 20:20:01.410212432 + +++ doc 2024-02-27 20:20:06.382271127 + @@ -1,42 +1,46 @@ -/usr/share/doc/libxmlsec1-dev/examples -/usr/share/doc/libxmlsec1-dev/examples/Makefile -/usr/share/doc/libxmlsec1-dev/examples/Makefile.w32 -/usr/share/doc/libxmlsec1-dev/examples/README.md -/usr/share/doc/libxmlsec1-dev/examples/binary.dat -/usr/share/doc/libxmlsec1-dev/examples/ca2cert.pem -/usr/share/doc/libxmlsec1-dev/examples/cacert.pem -/usr/share/doc/libxmlsec1-dev/examples/decrypt1.c -/usr/share/doc/libxmlsec1-dev/examples/decrypt2.c -/usr/share/doc/libxmlsec1-dev/examples/decrypt3.c -/usr/share/doc/libxmlsec1-dev/examples/deskey.bin -/usr/share/doc/libxmlsec1-dev/examples/encrypt1-res.xml -/usr/share/doc/libxmlsec1-dev/examples/encrypt1-tmpl.xml -/usr/share/doc/libxmlsec1-dev/examples/encrypt1.c -/usr/share/doc/libxmlsec1-dev/examples/encrypt2-doc.xml -/usr/share/doc/libxmlsec1-dev/examples/encrypt2-res.xml -/usr/share/doc/libxmlsec1-dev/examples/encrypt2.c -/usr/share/doc/libxmlsec1-dev/examples/encrypt3-doc.xml -/usr/share/doc/libxmlsec1-dev/examples/encrypt3-res.xml -/usr/share/doc/libxmlsec1-dev/examples/encrypt3.c -/usr/share/doc/libxmlsec1-dev/examples/mywin32make.bat -/usr/share/doc/libxmlsec1-dev/examples/rsacert.pem -/usr/share/doc/libxmlsec1-dev/examples/rsakey.pem -/usr/share/doc/libxmlsec1-dev/examples/rsapub.pem -/usr/share/doc/libxmlsec1-dev/examples/sign1-res.xml -/usr/share/doc/libxmlsec1-dev/examples/sign1-tmpl.xml -/usr/share/doc/libxmlsec1-dev/examples/sign1.c -/usr/share/doc/libxmlsec1-dev/examples/sign2-doc.xml -/usr/share/doc/libxmlsec1-dev/examples/sign2-res.xml -/usr/share/doc/libxmlsec1-dev/examples/sign2.c -/usr/share/doc/libxmlsec1-dev/examples/sign3-doc.xml -/usr/share/doc/libxmlsec1-dev/examples/sign3-res.xml -/usr/share/doc/libxmlsec1-dev/examples/sign3.c -/usr/share/doc/libxmlsec1-dev/examples/verify1.c -/usr/share/doc/libxmlsec1-dev/examples/verify2.c -/usr/share/doc/libxmlsec1-dev/examples/verify3.c -/usr/share/doc/libxmlsec1-dev/examples/verify4-bad-res.xml -/usr/share/doc/libxmlsec1-dev/examples/verify4-bad-tmpl.xml -/usr/share/doc/libxmlsec1-dev/examples/verify4-res.xml -/usr/share/doc/libxmlsec1-dev/examples/verify4-tmpl.xml -/usr/share/doc/libxmlsec1-dev/examples/verify4.c -/usr/share/doc/libxmlsec1-dev/examples/xmldsigverify.c +/usr/share/doc/libxmlsec1/examples +/usr/share/doc/libxmlsec1/examples/Makefile +/usr/share/doc/libxmlsec1/examples/Makefile.w32 +/usr/share/doc/libxmlsec1/examples/README.md +/usr/share/doc/libxmlsec1/examples/binary.dat +/usr/share/doc/libxmlsec1/examples/ca2cert.pem +/usr/share/doc/libxmlsec1/examples/cacert.pem +/usr/share/doc/libxmlsec1/examples/decrypt1.c +/usr/share/doc/libxmlsec1/examples/decrypt2.c +/usr/share/doc/libxmlsec1/examples/decrypt3.c +/usr/share/doc/libxmlsec1/examples/deskey.bin +/usr/share/doc/libxmlsec1/examples/encrypt1-res.xml +/usr/share/doc/libxmlsec1/examples/encrypt1-tmpl.xml +/usr/share/doc/libxmlsec1/examples/encrypt1.c +/usr/share/doc/libxmlsec1/examples/encrypt2-doc.xml +/usr/share/doc/libxmlsec1/examples/encrypt2-res.xml +/usr/share/doc/libxmlsec1/examples/encrypt2.c +/usr/share/doc/libxmlsec1/examples/encrypt3-doc.xml +/usr/share/doc/libxmlsec1/examples/encrypt3-res.xml +/usr/share/doc/libxmlsec1/examples/encrypt3.c +/usr/share/doc/libxmlsec1/examples/mywin32make.bat +/usr/share/doc/libxmlsec1/examples/rsacert.pem +/usr/share/doc/libxmlsec1/examples/rsakey.pem +/usr/share/doc/libxmlsec1/examples/rsapub.pem +/usr/share/doc/libxmlsec1/examples/sign1-res.xml +/usr/share/doc/libxmlsec1/examples/sign1-tmpl.xml +/usr/share/doc/libxmlsec1/examples/sign1.c +/usr/share/doc/libxmlsec1/examples/sign2-doc.xml +/usr/share/doc/libxmlsec1/examples/sign2-res.xml +/usr/share/doc/libxmlsec1/examples/sign2.c +/usr/share/doc/libxmlsec1/examples/sign3-doc.
Bug#1064776: bogusly redirects Bugs to debian-openoff...@lists.debian.org instead of the BTS
Source: libreoffice Version: 4:24.2.0-1 Severity: serious Control: close -1 4:24.2.0-3 Am 23.02.24 um 17:14 schrieb Rene Engelhard: Hi, Am 23.02.24 um 08:02 schrieb HIGUCHI Daisuke (VDR dai): Sorry, resending to BTS, not to debian-openoffice. No problem, that -1 redirects the bug reports to debian-openoffice is a bug. (Fixed in later versions but those are stuck after the t64 transition.) Making a (RC) bug out of this. Regards, Rene
Bug#1064494: libreoffice-calc: forcing "Wrap text automatically" when moving cells
Hi, Am 23.02.24 um 08:02 schrieb HIGUCHI Daisuke (VDR dai): Sorry, resending to BTS, not to debian-openoffice. No problem, that -1 redirects the bug reports to debian-openoffice is a bug. (Fixed in later versions but those are stuck after the t64 transition.) Regards, Rene
Bug#1063733: no -D_TIME_BITS=64 on builds where t64 support is supposed to be done
Hi, Am 11.02.24 um 22:10 schrieb Rene Engelhard: I just tried a rebuild of libreoffice with DEB_HOST_MAINT_OPTIONS="abi=+time64" to actually see what happens. DEB_BUILD_MAINT_OPTIONS of course. I set the correct one (and libreoffice and xmlsec1 did pick it up) but just "thinkoed" it when reporting the bug. Regards, Rene
Bug#1063733: no -D_TIME_BITS=64 on builds where t64 support is supposed to be done
Source: gpgme1.0 Version: 1.18.0-4.1~exp1 Severity: important [ let's no get into a discussion on the sense of this transition. I actually believe this isn't needed and we can leave 32 bit die in 2038 but anyways... The transition is ongoing now in experimental. So be it ] Hi, I just tried a rebuild of libreoffice with DEB_HOST_MAINT_OPTIONS="abi=+time64" to actually see what happens. It failed in a certificate unit tests so I tried to rebuild the "certificate" related (build-)dependencies also with DEB_HOST_MAINT_OPTIONS="abi=+time64" While doing so I noticed that gpgme1.0 doesn't define -D_TIME_BITS=64 even when built for t64 (as in the experimental NMU renaming to t64) on the affected architectures (anything 32-bit except i386). This is probably because it doesn't honout dpkg-buildflags. But even if you don't like dpkg-buildflags that define has to be done. Regards, Rene P.S:: Thankfully libreoffice is fine without a rebuilt gpgme1.0 somehow
Bug#1063734: no -D_TIME_BITS=64 on builds where t64 support is supposed to be done
Source: gnutls28 Version: 3.8.3-1.1~exp1 Severity: important [ let's no get into a discussion on the sense of this transition. I actually believe this isn't needed and we can leave 32 bit die in 2038 but anyways... The transition is ongoing now in experimental. So be it ] Hi, I just tried a rebuild of libreoffice with DEB_HOST_MAINT_OPTIONS="abi=+time64" to actually see what happens. It failed in a certificate unit tests so I tried to rebuild the "certificate" related (build-)dependencies also with DEB_HOST_MAINT_OPTIONS="abi=+time64" While doing so I noticed that gnutls28 doesn't define -D_TIME_BITS=64 even when built for t64 (as in the experimental NMU renaming to t64) on the affected architectures (anything 32-bit except i386). This is probably because it doesn't honout dpkg-buildflags. But even if you don't like dpkg-buildflags that define has to be done. Regards, Rene P.S:: Thankfully libreoffice is fine with just xmlsec1 being rebuilt. But it uses the nss flabour, so stuff using gnutls might break, no idea
Bug#1063732: hurd-i386 twice in java_unsupported_architectures
Package: java-common Version: 0.75 Severity: minor Hi, $ grep java_unsupported_architectures /usr/share/java/java_defaults.mk java_unsupported_architectures = hppa hurd-i386 kfreebsd-amd64 kfreebsd-i386 hurd-i386 powerpcspe s390 sparc [...] hurd-i386 is here twice. Regards, Rene
Bug#1020482: libreoffice-dictionaries: Package the Qt WebEngine binary dictionary files from your Hunspell source
tag 1020482 + pending thanks Am 24.01.24 um 23:44 schrieb Soren Stoutner: Control: tags -1 + patch I submitted an MR at: https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice-dictionaries/-/merge_requests/6 <https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice-dictionaries/-/merge_requests/6> Merged (and uploaded after fixing the changelog) Regards, Rene
Bug#1061242: libreoffice-impress: impress cannot start. Its display an error loading a dll that is installed
Hi, oops. Am 21.01.24 um 15:35 schrieb Rene Engelhard: Here the new libxml2 removes functions and symbol versions used by gazillions of packages over the whole of the Debian archive. And no, the exact point of Debian library package names is that they HAVE to change on ABI changes. Especially on a library like this which is used by virtually anything. See https://www.debian.org/doc/debian-policy/ch-sharedlibs.h https://www.debian.org/doc/debian-policy/ch-sharedlibs.html , obviously :) Regards, Rene
Bug#1061242: libreoffice-impress: impress cannot start. Its display an error loading a dll that is installed
Hi, Am 21.01.24 um 15:27 schrieb Eric Valette: On 21/01/2024 14:49, Rene Engelhard wrote: Exactly that is the point of #1059040. The binary packages have to be renamed. (Then rebuild against libxml2-WHATEVERNEW). Then a rebuild LO will have a proper dependency on libxml2-WHATEVERNEW. I agree that package with different APIs should bump their major .so version, but not obviously change their name. At least, that has not always been like that (more than 20 years...). API != ABI. (New) API is different. Here the new libxml2 removes functions and symbol versions used by gazillions of packages over the whole of the Debian archive. And no, the exact point of Debian library package names is that they HAVE to change on ABI changes. Especially on a library like this which is used by virtually anything. See https://www.debian.org/doc/debian-policy/ch-sharedlibs.h No. The bug is in libxml2. I disagree on this. Many ddl did not change their name when they have API breakage only bump major so that symbolic links does not get resolved. Again API != ABI. That is a bug in libxml2 regardless. See the discussion there, especially the comment about "partial updates", which this is. libxml2 has to restore ABI compatibility or rename the package. (I would also argue as you if it was some minor thing or stuff removed noone really uses but that is not the case here, as said in the libxml2 bug it breaks stuff at runtime all over the place) Regards, Rene
Bug#1061242: libreoffice-impress: impress cannot start. Its display an error loading a dll that is installed
Hi, Am 21.01.24 um 14:44 schrieb Eric Valette: ii libxml2 2.12.3+dfsg-0exp1 And this one *from experimental* changed ABI (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059040). Don't install it on systems you don't want breakage in. Bingo you got it. However this means that dependencies are wrong somewhere. As soon as it enter unstable, the problem will be there if dependencies/rebuild are not managed correctly Exactly that is the point of #1059040. The binary packages have to be renamed. (Then rebuild against libxml2-WHATEVERNEW). Then a rebuild LO will have a proper dependency on libxml2-WHATEVERNEW. The libxml2 package as of now must not install unstable at current state. Indeed the current package name of libxml2 is a problem and fullfills unstables depends, but see below. It is expected that stuff built with 2.9.x doesn't necessarily work with 2.12. And here libsdlo.so *does* link against libxml: Missing dependency < dependency at least. Yeah. But for that you need a palantir. For an unknown amount of packages in the archive? No. The bug is in libxml2. Regards, Rene
Bug#1059040: [xml/sgml-pkgs] Bug#1059040: libxml2: ABI change? (undefined references)
Hi, Am 12.01.24 um 17:56 schrieb Thorsten Glaser: On Fri, 12 Jan 2024, Rafael Laboissière wrote: experimental, the configure script does detect the absence of the xmlNanoFTPNewCtxt function in the libxml2 library (version 2.12.3+dfsg-0exp1) and disables the call to the xmlNanoFTP* functions. However, this rebuilt will not be automatically triggered without a bump in the SONAME version of libxml2. In summary, the introduction of version 2.12 of libxml2 in unstable will need a proper and coordinated transition. No, this will still break partial upgrades. Indeed. First runtime error bug report I got: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061242 Regards, Rene
Bug#1020482: libreoffice-dictionaries: Package the Qt WebEngine binary dictionary files from your Hunspell source
Am Sat, Oct 14, 2023 at 11:50:25AM -0700 schrieb Soren Stoutner: > Would you be interested in a patch to implement this functionality? You can do that, for sure. (Actually during debconf last year I did a quick and dirty solution to this - excluding the special-case-needed ones, but dropped the ball on it. Can resurrect it, though) Regards, Rene
Bug#1060255: Instead of certain text, squares are displayed in the interface
all icons made for smaller graphic ii fonts-lato 2.0-2.1 all sans-serif typeface family font ii fonts-liberation 1:1.07.4-11 all Fonts with the same metrics as Times, Arial and Courier ii fonts-liberation2 2.1.5-1 all Fonts with the same metrics as Times, Arial and Courier (v2) ii fonts-lmodern 2.005-1 all OpenType fonts based on Computer Modern ii fonts-noto-color-emoji 2.042-0+deb12u1 all color emoji font from Google ii fonts-noto-mono 20201225-1 all "No Tofu" monospaced font family with large Unicode coverage ii fonts-open-sans 1.11-2 all humanist sans serif typeface by Steve Matteson ii fonts-opensymbol 4:102.12+LibO7.4.7-1+deb12u1 all OpenSymbol TrueType font ii fonts-quicksand 0.2016-2.1 all sans-serif font with round attributes ii fonts-symbola 2.60-1.1 all symbolic font providing emoji characters from Unicode 9.0 ii fonts-texgyre 20180621-6 all OpenType fonts based on URW Fonts ii fonts-texgyre-math 20180621-6 all OpenType math fonts based on URW Fonts ii fonts-urw-base35 20200910-7 all font set metric-compatible with the 35 PostScript Level 2 Base Fonts ii fonts-wine 8.0~repack-4 all Windows API implementation - fonts ii gsfonts 2:20200910-7 all transitional dummy package (gsfonts -> fonts-urw-base35) rc gsfonts-x11 2:20200910-7 all transitional dummy package (gsfonts-x11 -> fonts-urw-base35) ii libfonts-java 1.1.6.dfsg2-1 all Java fonts layouting library ii libwoff1:amd64 1.0.2-2 amd64 library for converting fonts to WOFF 2.0 ii lmodern 2.005-1 all scalable PostScript and OpenType fonts based on Computer Modern ii tex-gyre 20180621-6 all scalable PostScript and OpenType fonts based on URW Fonts ii texlive-fonts-recommended 2022.20230122-3 all TeX Live: Recommended fonts ii xfonts-100dpi 1:1.0.5 all 100 dpi fonts for X ii xfonts-75dpi 1:1.0.5 all 75 dpi fonts for X ii xfonts-base 1:1.0.5+nmu1 all standard fonts for X ii xfonts-encodings 1:1.0.4-2.2 all Encodings for X.Org fonts ii xfonts-scalable 1:1.0.3-1.3 all scalable fonts for X ii xfonts-utils 1:7.7+6 amd64 Regards, Rene
Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
Hi, Am 07.01.24 um 04:38 schrieb Steve Langasek: The ordering here would be: - dpkg will be uploaded to experimental with 64-bit time_t in the default flags - the source packages which need an ABI change ("source-packages"+"lfs-and-depends-time_t") and do not already have versions in experimental, will have sourceful NMUs to experimental with the new binary package names in order to clear binary NEW, in coordination - once these packages have all cleared binary NEW, the new dpkg defaults will be uploaded to unstable And in the meanwhile in experimental it will be built with the old time_t on other architectures. Since the new dpkg won't be picked up. Not in the experimental builders unstable+experimental chroots which only install experimental packages when Build-Depends: need them. (For an undefined time given how much the packages later in the chain wait in NEW) Especially on armhf which is affected. Or will you do the source NMUs on armhf/i386? (For some packages where some features are disabled on 32bit this is probably not a good idea) Regards, Rene
Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
Hi, Am 07.01.24 um 02:01 schrieb Steve Langasek: If you say you are going to fix eventual breakage (and not ignoring the test results!) and if that means fixing asm on all affected archs, then it's OK :) Well, yes; though I hope we would see some help from e.g. arm porters if there were actually breakage of this nature. Hope doesn't help when it got to the actual problem and this doesn't happen. Alternatively, maybe it would be better to stop shipping libreoffice on 32-bit archs, in that case? I'm I'd like to avoid this. Getting rid of i386 is fine, noone needs it, armhf is a bit different. (rpis etc - even though they could run arm64, but..) not sure how usable libreoffice is these days on such archs. popcon.debian.org doesn't appear to have the granularity to tell us if there actually *are* users; and with only 615 armhf popcon reports (vs 215,562 on amd64) we don't exactly have a statistically significant sample there. Only recently I got https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059158. Maybe UI is not used much, but I can imagine people using it in paperless-ngx or other stuff. I don't really want to bastardize those uses. - the source packages which need an ABI change ("source-packages"+"lfs-and-depends-time_t" will have sourceful NMUs to I get that you probably want NMUs for not needing to ping every maintainer, but this is bad. That e.g. would cause me to upload libreoffice 24.2 rc2 to sid immediately when tagged end of next week to not have this caught in the transition. (see also below for the comment about new upstream versions in experimental.) What about the suggestion to not push changes to experimental for packages that already have new versions in experimental, and do the binary package renames in unstable instead, leaving the package in experimental alone? If at all - *both*. At the same time. Most of these packages that are staged in experimental are going to be there because of library transitions... And ignore those who use experimental as a testbed of major new upstreams? Doesn't sound good. experimental with the new binary package names in order to clear binary NEW, in coordination And what about skipped ones? When will those be tried? What do you mean here by "skipped ones"? https://adrien.dcln.fr/misc/armhf-time_t/2023-12-18/results_skipped.txt (which incidentially contains libreoffice) Ah! These are packages that have been omitted from the analysis because they've been manually identified as packages that don't have C or C++-compatible header files related to a shared library, and therefore even if they do need updated for 64-bit time_t, they are not affected by CPPFLAGS and are not part of this transition. (I am not 100% sure this is accurate for ObjC; in any case ObjC headers are impossible to analyze using abi-compliance-checker so if ObjC libraries are possibly affected, someone would have to figure out what to do with them.) I have no idea on how you indentified it In the libreoffice case that is not true. libreoffice-dev-(common) *does* contain C/C++ header files. And most of them *do* correspond to the libuno* shared packages. Just that they are not split per library because that wouldn't really make sense since you need any of them anyway. And I definitely see e.g. /usr/include/libreoffice/osl/time.h (libuno-sal3) No idea whether it actually will be broken by the change, but... I'm not sure precisely why Adrien found it necessary/useful to add libreoffice-dev to this exclude list, Probably because he didn't look at the whole but just at the package but I can confirm that it's reasonable, as this particular package contains only a single header file with #define's and no function prototypes; so in effect it has been manually analyzed and determined to be unaffected. But libreoffice-dev-common not (on which libreoffice-dev depends) which contains all the arch-indep headers. Just libreoffice-dev contains one header diferent between archs. Regards, Rene
Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
Hi, Am 06.01.24 um 06:51 schrieb Steve Langasek: - dpkg will be uploaded to experimental with 64-bit time_t in the default flags [...] What about the suggestion to not push changes to experimental for packages that already have new versions in experimental, and do the binary package renames in unstable instead, leaving the package in experimental alone? How does that play together with the needed dpkg only in experimental? You can't build stuff for unstable involving experimental packages (except manually with binary upload, which would block testing migration) Regards, Rene
Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
Hi Steve, Am 06.01.24 um 06:51 schrieb Steve Langasek: - dpkg will be uploaded to experimental with 64-bit time_t in the default flags I think at that point in time one should know what breaks and whatnot. Archive rebuild? (Probably in stages) What kind of breakage are you looking to avoid here? As mentioned in other build failures/test failures. points in the thread, regressions as a result of this change should be rare and easy to fix. I do not think it's a good use of time / CPU power to do test rebuilds for this instead of just landing the transition. Here especially LibreOffices bridge code worries me. That one is tied to ABI and calling conventions. I don't see time_t mentioned there but "just" in the public libraries (sal), but I am not sure what making a type bigger will cause. (And since already - i386 needs gcc-12 to build since otherwise the test fails - armhf (and other archs like ppc64el and s390x) need Java disabled[1] - without any help from any porter to prevent this - I *do* want to avoid breakage here. If you say you are going to fix eventual breakage (and not ignoring the test results!) and if that means fixing asm on all affected archs, then it's OK :) - the source packages which need an ABI change ("source-packages"+"lfs-and-depends-time_t" will have sourceful NMUs to I get that you probably want NMUs for not needing to ping every maintainer, but this is bad. That e.g. would cause me to upload libreoffice 24.2 rc2 to sid immediately when tagged end of next week to not have this caught in the transition. (see also below for the comment about new upstream versions in experimental.) What about the suggestion to not push changes to experimental for packages that already have new versions in experimental, and do the binary package renames in unstable instead, leaving the package in experimental alone? If at all - *both*. At the same time. But yes, that could work. (In this specific case I an worrying that the transition will take some time, and that I am stuck with 7.6.x instead of uploading 24.2 when it is released.) libreoffice libs only have one reverse-dep, zemberek-ooo; so the risk of entanglement here is small anyway. Except in poppler etc. transitions.. But yeah, nothing really uses the C++ libs nowadays. I think the above proposal, to skip packages already in experimental from the set of uploads to experimental, would address your concern. It's not as if there is going to be any time that it's ok to tell maintainers they can't use experimental at all because we're doing this transition. experimental with the new binary package names in order to clear binary NEW, in coordination And what about skipped ones? When will those be tried? What do you mean here by "skipped ones"? https://adrien.dcln.fr/misc/armhf-time_t/2023-12-18/results_skipped.txt (which incidentially contains libreoffice) Regards, Rene [1] Ubuntu just ignores the test failures. No, not an option.
Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
Hi, Am 05.01.24 um 09:17 schrieb Steve Langasek: - Packages that could not be analyzed for whatever reason are still assumed to have an ABI that's sensitive to time_t and have to be included in the transition. Happily, due to improvements in this run of the number of packages that could successfully be analyzed, the number of libraries in this category has dropped from 1541 to 929, of which 69 have no reverse-dependencies at all. The final list of these header packages that could not be analyzed is attached, in case anyone still wants to identify that a library on this list whose ABI is not affected by time_t and should therefore be excluded from the transition. Note, however, that no effort has been made to filter out dev packages from this list that come from source packages containing OTHER dev packages that are known to have ABI breakage; for a number of the packages listed, further analysis would not change the outcome. (e.g. qt5-qmake failed to be analyzed, but qtbase-opensource-src also ships qtbase5-private-dev which shows time_t ABI sensitivity.) [...] My strawman proposal is to give this thread 2 weeks from today for feedback and further refinement, and also to further reduce the number of false-positives included in the transition. Then, starting on Jan 18: - dpkg will be uploaded to experimental with 64-bit time_t in the default flags I think at that point in time one should know what breaks and whatnot. Archive rebuild? (Probably in stages) - the source packages which need an ABI change ("source-packages"+"lfs-and-depends-time_t" will have sourceful NMUs to I get that you probably want NMUs for not needing to ping every maintainer, but this is bad. That e.g. would cause me to upload libreoffice 24.2 rc2 to sid immediately when tagged end of next week to not have this caught in the transition. (see also below for the comment about new upstream versions in experimental.) experimental with the new binary package names in order to clear binary NEW, in coordination And what about skipped ones? When will those be tried? Those also will need clear NEW if needed. (And they might even FTBFS because the ABI did change and ABI-assuming test break? Though I don't assume so for time_t, but if time is passed around... I don't assume so, but... At least that would be the case for libreoffice (and libreoffice-dev-common is in the affected set, which means some stuff relies on it...)) (Maybe even needing asm fixes) - once these packages have all cleared binary NEW, the new dpkg defaults will be uploaded to unstable - the sourceful NMUs of the libraries will be reuploaded to unstable (without binaries, so that they can be promoted to testing without additional uploads). Please let me know of any problems with this plan. Also a problem is that experimental also might already contain totally unrelated updates like new upstream versions... Regards, Rene
Bug#974220: libreoffice-writer: Double paste in Writer
forwarded 974220 https://bugs.documentfoundation.org/show_bug.cgi?id=140652 tag 974220 + upstream thanks Am 05.01.24 um 15:01 schrieb Claudio Ferreira: Yes. I have this software. Is common in the Brazilian market. I tried now to past a text and it works as expected. For me, this bug can be closed. Thanks for confirming. Let's keep it open and mark it as forwarded to the bug James mentioned. Regards, Rene
Bug#1059805: clucene-core: please apply LibreOffice patch to alllow not writing random timestamps into generated files, making them unreproducible
Hi, Am 03.01.24 um 16:47 schrieb James Addison: Source: clucene-core Followup-For: Bug #1059805 X-Debbugs-Cc: r...@debian.org, thorsten.behr...@allotropia.de On Mon, 1 Jan 2024 18:24:19 +0100, Rene wrote: LibreOffice created a patch to clucene to make their help pages reproducible. Maybe we should include it here? (libreoffice in Debian uses the system library instead of the embedded copy.) A possible obstacle with that approach: the libreoffice code invokes the additional API function to implements this when _not_ configured[1] to use the system-provided clucene. I know. :) That is not really a reason, though. I am happy to patch it to make it work (and build-depend on a matching clucene-core). AFAICS this doesn't require a runtime dependency here since it writes some other value to a field at generation time, which is read anyway in the unpatched version even. Actually back then when Thorsten proposed it first I said "please make it a configure check"... Regards, Rene
Bug#1059805: clucene-core: please apply LibreOffice patch to alllow not writing random timestamps into generated files, making them unreproducible
Source: clucene-core Version: 2.3.3.4+dfsg-1.1 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps randomness Affects: libreoffice-help-en-us libreoffice-help-ca libreoffice-help-cs libreoffice-help-da libreoffice-help-de libreoffice-help-dz libreoffice-help-el libreoffice-help-en-gb libreoffice-help-es libreoffice-help-et libreoffice-help-eu libreoffice-help-fi libreoffice-help-fr libreoffice-help-gl libreoffice-help-hi libreoffice-help-hu libreoffice-help-id libreoffice-help-it libreoffice-help-ja libreoffice-help-km libreoffice-help-ko libreoffice-help-nl libreoffice-help-om libreoffice-help-pl libreoffice-help-pt libreoffice-help-pt-br libreoffice-help-ru libreoffice-help-sk libreoffice-help-sl libreoffice-help-sv libreoffice-help-tr libreoffice-help-vi libreoffice-help-zh-cn libreoffice-help-zh-tw Dear Maintainer, LibreOffice created a patch to clucene to make their help pages reproducible. Maybe we should include it here? (libreoffice in Debian uses the system library instead of the embedded copy.) See https://cgit.freedesktop.org/libreoffice/core/patch/?id=ff071078ee5f13f0e9d430d6783444a631d232a0 (clucene-reprobuild.patch.1) which adds a new method setting the "start position" (which then is used in libreoffice to consistently set it 0) Regards, Rene
Bug#1059535: transition: abseil
Hi, Am 27.12.23 um 19:15 schrieb Benjamin Barenblat: Although doing a transition now will break some packages in sid, I believe waiting is likely to cause more issues. Upstreams (LibreOffice in particular) are starting to use features from the new version of Abseil, Actually it's not LibreOffice but LibreOffice indirectly via pdfium (which makes chromium also be affected if it did build without using the embedded copy of abseil). That said libreoffice builds (both sids and experimentals version). Tested on amd64 only, but Regards, Rene