Re: x32: mariadb: if defined __ILP32__ and __x86_64__ ?

Thanks for the advice. Potential fix posted now at https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/90 for team review.

Re: x32: mariadb: if defined __ILP32__ and __x86_64__ ?

Unsubscribe On Wed., Jul. 3, 2024, 00:21 Otto Kekäläinen, wrote: > Hi! > > MariaDB has this piece of code that is failing on x32 as reported in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063738 > > tests/mysql_client_fw.c > @@ -1442 > > #if defined __x86_64__ >

Re: x32: mariadb: if defined __ILP32__ and __x86_64__ ?

Hi! On Tue, Jul 02, 2024 at 09:05:14PM -0700, Otto Kekäläinen wrote: > tests/mysql_client_fw.c > @@ -1442 > > #if defined __x86_64__ > compile_time_assert(sizeof(MYSQL) == 1272); > #elif defined __i386__ > compile_time_assert(sizeof(MYSQL) == 964); > #endif > > How should I fix this for

Re: x32: mariadb: if defined __ILP32__ and __x86_64__ ?

Hi all! On 03/07/2024 06:05, Otto Kekäläinen wrote: [...] MariaDB has this piece of code that is failing on x32 as reported in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063738 tests/mysql_client_fw.c @@ -1442 #if defined __x86_64__ #if defined(__x86_64__) && !defined(__ILP32__)

Re: x32: mariadb: if defined __ILP32__ and __x86_64__ ?

Hi all! sent too fast: On 03/07/2024 12:31, Bernd Petrovitsch wrote: [...] On 03/07/2024 06:05, Otto Kekäläinen wrote: [...] MariaDB has this piece of code that is failing on x32 as reported in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063738 tests/mysql_client_fw.c @@ -1442 #if

x32: mariadb: if defined __ILP32__ and __x86_64__ ?

Hi! MariaDB has this piece of code that is failing on x32 as reported in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063738 tests/mysql_client_fw.c @@ -1442 #if defined __x86_64__ compile_time_assert(sizeof(MYSQL) == 1272); #elif defined __i386__ compile_time_assert(sizeof(MYSQL) ==

Bug#1071428: mariadb: FTBFS on x32: size of array compile_time_assert is negative

Source: mariadb Version: 1:10.11.8-1 Forwarded: https://jira.mariadb.org/browse/MDEV-34195 Tags: confirmed, help, ftbfs User: debian-...@lists.debian.org Usertags: x32 X-Debbugs-CC: debian-amd64@lists.debian.org After importing 10.11.8 in Debian, dropped the temporary patch and uploaded with the

dowload

Enviado desde Correo para Windows 10

, How can I find a tooling maker with a proven track record of reliability?

Dear Mr./Ms.   Hi, Have a nice day. Our company is interested in discussing collaboration with in   The process of finding a mold/prototype manufacturer that fits your budget can be challenging. Our factory in Guangzhou is staffed with highly skilled professionals dedicated to producing

Re: Bug#1057050 closed by Debian FTP Masters (reply to Patrick Franz ) (Bug#1057050: fixed in qt6-multimedia 6.6.1-1)

Control: reopen -1 Hi, looks like this didn't work: > https://buildd.debian.org/status/fetch.php?pkg=qt6-multimedia=powerpc=6.4.2-11=1705003199=0 Reopening the bug therefore. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0

Bug#1067026: graphviz: please build without librsvg except on rust platforms

Source: graphviz Version: 2.42.2-9 X-Debbugs-Cc: t...@mirbsd.de, debian-po...@lists.debian.org librsvg has become extremely unportable, and so only a subset of architectures have it: amd64 arm64 armel armhf i386 mips64el ppc64el riscv64 s390x loong64 powerpc ppc64 sparc64 Please whitelist the

Re: python-cryptography vs. stainless steel ports

On 3/14/24 06:53, Thorsten Glaser wrote: Dixi quod… Is there a chance your team could fork the old python-cryptography source package (3.4.8-2) and do something like: Apparently, pyopenssl needs to also be forked as it wraps the above and, between 21.0.0-1 and 22.1.0-1, it began requiring

Re: python-cryptography vs. stainless steel ports

Dixi quod… >Is there a chance your team could fork the old python-cryptography >source package (3.4.8-2) and do something like: Apparently, pyopenssl needs to also be forked as it wraps the above and, between 21.0.0-1 and 22.1.0-1, it began requiring the rust version of python-cryptography ☹

Bug#1066832: fsverity-utils: hard Build-Depends on unportable package pandoc

Source: fsverity-utils Version: 1.5-1.1 Severity: important Justification: RC for Debian-Ports X-Debbugs-Cc: t...@mirbsd.de, debian-po...@lists.debian.org Recent versions of fsverity-utils (larger than 1.4-1~exp1 anyway) have a Build-Depends-Arch on pandoc; however, pandoc is an extremely

Re: python-cryptography vs. stainless steel ports

Jérémy Lal dixit: >Anyone had experience with the version 3.3 to 38.0 migration ? >Maybe the API didn't change that much. We cannot go past 3.4 because newer versions (starting at 38) have a hard dependency on rust stuff. bye, //mirabilos -- Solange man keine schmutzigen Tricks macht, und ich

Re: python-cryptography vs. stainless steel ports

Le lun. 11 mars 2024 à 21:53, Thorsten Glaser a écrit : > Jérémy Lal dixit: > > >While I'm very much concerned about architectures and compatibility, > >it seems that for python-cryptography, it's a sinking boat: > >The end of a very discussion dates from february, 2021 - 3 years ago: >

Re: python-cryptography vs. stainless steel ports

Jérémy Lal dixit: >While I'm very much concerned about architectures and compatibility, >it seems that for python-cryptography, it's a sinking boat: >The end of a very discussion dates from february, 2021 - 3 years ago: >https://github.com/pyca/cryptography/issues/5771#issuecomment-775990406

Re: python-cryptography vs. stainless steel ports

Le lun. 11 mars 2024 à 20:17, Thorsten Glaser a écrit : > Hi, > > we have still the situation that the current python-cryptography, > having rather heavy rust ecosystem dependencies, cannot be built > on some debian-ports architectures. > > This situation is not likely to go away: > > • some

python-cryptography vs. stainless steel ports

Hi, we have still the situation that the current python-cryptography, having rather heavy rust ecosystem dependencies, cannot be built on some debian-ports architectures. This situation is not likely to go away: • some ports are unlikely to meet the dependencies soon • new ports won’t meet them

Bug#1058740: gtk4,librsvg: big-endian support is at risk of being removed

Source: gtk4,librsvg Severity: important Tags: upstream help X-Debbugs-Cc: debian-s...@lists.debian.org, debian-po...@lists.debian.org gtk4 had a recent test failure regression on s390x and other big-endian architectures like ppc64 (#1057782). I sent this upstream to

Re: Bug#1040062: dpkg-dev: Please drop pie-{compile,link}.spec

On Fri, Nov 24, 2023 at 01:53:04AM +0100, Guillem Jover wrote: > Hi! Hi Guillem! Apologies for not replying to these emails earlier. > On Tue, 2023-10-31 at 10:52:40 +0100, Guillem Jover wrote: >... > > If PIE (via specs files) appears to work on x32, and changing the > > defaults in gcc is too

Re: Bug#1040062: dpkg-dev: Please drop pie-{compile,link}.spec

Hi! On Tue, 2023-10-31 at 10:52:40 +0100, Guillem Jover wrote: > I guess I could do it the other way, and given this is apparently > causing issues as reported by Adrian, and as seen recently from > the referenced bug report which might require patching a specific > package to disable PIE there,

Re: Happy 30 Years Debian Project

> Happy Birthday 30 years of the Debian Linux Project yay ! and q2!

Re: Bug#1040062: dpkg-dev: Please drop pie-{compile,link}.spec

Hi! On Tue, 2023-07-04 at 13:12:48 +0300, Adrian Bunk wrote: > On Tue, Jul 04, 2023 at 09:23:43AM +0200, Guillem Jover wrote: > > On Sun, 2023-07-02 at 00:02:46 +0300, Adrian Bunk wrote: > > > There are some problems with this: > > > > > > 1. PIE should either be default or not be used > > > > >

Re: Kernel 6.5 from Experimental working

Also updated this to 6.5.1 today and still works Den tors 7 sep. 2023 kl 08:37 skrev Luna Jernberg : > > Hey! > > Just installed Kernel 6.5 from experimental during Debcamp 2023 on my > ThinkPad Edge 0217A16 and it works as intended on this laptop :) > > //Luna bittin Jernberg

Re: Happy 30 Years Debian Project

Happy Birthday Debian By the way, thank you all who put any amount of work on Debian. Thank you Ian. On August 16, 2023 11:31:35 AM UTC, Luna Jernberg wrote: >Happy Birthday 30 years of the Debian Linux Project >

Happy 30 Years Debian Project

Happy Birthday 30 years of the Debian Linux Project https://www.gamingonlinux.com/2023/08/happy-debian-day-going-30-years-strong/ https://wiki.debian.org/DebianDay/2023 https://wiki.debian.org/DebianHistory?action=AttachFile=get=Debian-announcement-1993-pic-by-Ian_Murdock.png

Re: unbreaking LibreOffices tests on at least release architectures

On Jul 22 2023, Rene Engelhard wrote: > Hi, > > Am 22.07.23 um 16:09 schrieb Andreas Schwab: >> On Jul 22 2023, Rene Engelhard wrote: >> >>> Am 22.07.23 um 15:53 schrieb Andreas Schwab: On Jul 22 2023, Rene Engelhard wrote: > Does opensuse have some public git/$VCS?

Re: [syzbot] [hfs?] WARNING in hfs_write_inode

On Fri, Jul 21, 2023 at 11:03:28AM +1000, Finn Thain wrote: > On Fri, 21 Jul 2023, Dave Chinner wrote: > > > > I suspect that this is one of those catch-22 situations: distros are > > > going to enable every feature under the sun. That doesn't mean that > > > anyone is actually _using_ them

Re: unbreaking LibreOffices tests on at least release architectures

On Sat, Jul 22, 2023 at 8:10 AM Rene Engelhard wrote: > > Am 22.07.23 um 14:02 schrieb Andreas Schwab: > > On Jun 18 2023, Rene Engelhard wrote: > > > >> For riscv64 I already pointed that out in the thread starting at > >> https://lists.debian.org/debian-riscv/2023/06/msg0.html, but for the

Re: unbreaking LibreOffices tests on at least release architectures

Hi, Am 22.07.23 um 16:09 schrieb Andreas Schwab: On Jul 22 2023, Rene Engelhard wrote: Am 22.07.23 um 15:53 schrieb Andreas Schwab: On Jul 22 2023, Rene Engelhard wrote: Does opensuse have some public git/$VCS?

Re: unbreaking LibreOffices tests on at least release architectures

On Jul 22 2023, Rene Engelhard wrote: > Am 22.07.23 um 15:53 schrieb Andreas Schwab: >> On Jul 22 2023, Rene Engelhard wrote: >> >>> Does opensuse have some public git/$VCS? >> https://build.opensuse.org/package/live_build_log/openSUSE:Factory:RISCV/libreoffice/standard/riscv64 > > Thanks... > >

Re: unbreaking LibreOffices tests on at least release architectures

On Jul 22 2023, Rene Engelhard wrote: > Does opensuse have some public git/$VCS? https://build.opensuse.org/package/live_build_log/openSUSE:Factory:RISCV/libreoffice/standard/riscv64 > (Though I would more bet of some system evironment thingy) Perhaps it is a matter of using a good java. Have

Re: unbreaking LibreOffices tests on at least release architectures

Am 22.07.23 um 15:53 schrieb Andreas Schwab: On Jul 22 2023, Rene Engelhard wrote: Does opensuse have some public git/$VCS? https://build.opensuse.org/package/live_build_log/openSUSE:Factory:RISCV/libreoffice/standard/riscv64 Thanks... But maybe I am too blind. I don't see the actual

Re: unbreaking LibreOffices tests on at least release architectures

Hi, Am 22.07.23 um 15:07 schrieb Andreas Schwab: Which gives the smoketest test failure here I pointed out (again) in my other mail. $ find /usr/lib64/libreoffice/ -name "*smoke*" /usr/lib64/libreoffice/program/classes/smoketest.jar How can I run that? You can't from that, ttbomk. You miss

Re: unbreaking LibreOffices tests on at least release architectures

Hi, Am 22.07.23 um 15:02 schrieb Andreas Schwab: On Jul 22 2023, Rene Engelhard wrote: https://lists.debian.org/debian-riscv/2023/07/msg00014.html is for manual thing. And the IRC log shows that even libreoffice-lightproof-en etc don't appear as bundled extensions. $ unopkg list --bundled

Re: unbreaking LibreOffices tests on at least release architectures

On Jul 22 2023, Rene Engelhard wrote: > Hi, > > Am 22.07.23 um 14:28 schrieb Andreas Schwab: >> On Jul 22 2023, Rene Engelhard wrote: >> >>> Yes. _basically_. (Only with -O0 or maybe -Os as upstreams makefile says, >>> though) >> On openSUSE Factory, libreoffice is built with the usual compiler

Re: unbreaking LibreOffices tests on at least release architectures

On Jul 22 2023, Rene Engelhard wrote: > https://lists.debian.org/debian-riscv/2023/07/msg00014.html is for manual > thing. And the IRC log shows that even libreoffice-lightproof-en etc don't > appear as bundled extensions. $ unopkg list --bundled All deployed bundled extensions: Identifier:

Re: unbreaking LibreOffices tests on at least release architectures

On Jul 22 2023, Rene Engelhard wrote: > And that includes LibreOffice-bundled extensions like the > english,hungarian,russian grammar checker for example. Ot external finnish > spellchecking, hyphenation and grammer checking. Or turkish spellchecing. > > And those are extensions written in python

Re: unbreaking LibreOffices tests on at least release architectures

On Jul 22 2023, Rene Engelhard wrote: > Yes. _basically_. (Only with -O0 or maybe -Os as upstreams makefile says, > though) On openSUSE Factory, libreoffice is built with the usual compiler flags, wich includes full optimisation and hardening. -- Andreas Schwab, sch...@linux-m68k.org GPG Key

Re: unbreaking LibreOffices tests on at least release architectures

On Jul 22 2023, Rene Engelhard wrote: > Just not registering or unregistering *any* extension. What does that mean? I haven't seen any errors about extensions. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for

Re: unbreaking LibreOffices tests on at least release architectures

Hi, Am 22.07.23 um 14:34 schrieb Andreas Schwab: On Jul 22 2023, Rene Engelhard wrote: And that includes LibreOffice-bundled extensions like the english,hungarian,russian grammar checker for example. Ot external finnish spellchecking, hyphenation and grammer checking. Or turkish spellchecing.

Re: unbreaking LibreOffices tests on at least release architectures

Hi, Am 22.07.23 um 14:28 schrieb Andreas Schwab: On Jul 22 2023, Rene Engelhard wrote: Yes. _basically_. (Only with -O0 or maybe -Os as upstreams makefile says, though) On openSUSE Factory, libreoffice is built with the usual compiler flags, wich includes full optimisation and hardening.

Re: unbreaking LibreOffices tests on at least release architectures

Hi, Am 22.07.23 um 14:25 schrieb Andreas Schwab: On Jul 22 2023, Rene Engelhard wrote: Just not registering or unregistering *any* extension. What does that mean? I haven't seen any errors about extensions. Do you run the testsuite? Especially the smoketest? And you are replying to

Re: unbreaking LibreOffices tests on at least release architectures

Hi, Am 22.07.23 um 14:09 schrieb Rene Engelhard: And that included packaged extensions so if they install but don't work that's a grave bug. And that includes LibreOffice-bundled extensions like the english,hungarian,russian grammar checker for example. Ot external finnish spellchecking,

Re: unbreaking LibreOffices tests on at least release architectures

On Jun 18 2023, Rene Engelhard wrote: > For riscv64 I already pointed that out in the thread starting at > https://lists.debian.org/debian-riscv/2023/06/msg0.html, but for the > other architectures there is the mail now. riscv64 is different because > the failures are even more big than any

Re: unbreaking LibreOffices tests on at least release architectures

Hi, Am 22.07.23 um 14:02 schrieb Andreas Schwab: On Jun 18 2023, Rene Engelhard wrote: For riscv64 I already pointed that out in the thread starting at https://lists.debian.org/debian-riscv/2023/06/msg0.html, but for the other architectures there is the mail now. riscv64 is different

Re: [syzbot] [hfs?] WARNING in hfs_write_inode

On Fri, Jul 21, 2023 at 06:14:04PM +1000, Finn Thain wrote: > > I'm not blaming the unstable API for the bugs, I'm blaming it for the > workload. A stable API (like a userspace API) decreases the likelihood > that overloaded maintainers have to orphan a filesystem implementation. You are

Re: [syzbot] [hfs?] WARNING in hfs_write_inode

On Fri, 21 Jul 2023, Matthew Wilcox wrote: > > You've misunderstood. Google have decided to subject the entire kernel > (including obsolete unmaintained filesystems) to stress tests that it's > never had before. IOW these bugs have been there since the code was > merged. There's nothing to

Re: [syzbot] [hfs?] WARNING in hfs_write_inode

On Fri, Jul 21, 2023 at 11:03:28AM +1000, Finn Thain wrote: > On Fri, 21 Jul 2023, Dave Chinner wrote: > > > > I suspect that this is one of those catch-22 situations: distros are > > > going to enable every feature under the sun. That doesn't mean that > > > anyone is actually _using_ them

Re: [syzbot] [hfs?] WARNING in hfs_write_inode

On Fri, 21 Jul 2023, Dave Chinner wrote: > > I suspect that this is one of those catch-22 situations: distros are > > going to enable every feature under the sun. That doesn't mean that > > anyone is actually _using_ them these days. I think the value of filesystem code is not just a question

Re: [syzbot] [hfs?] WARNING in hfs_write_inode

On Thu, 20 Jul 2023 at 15:37, Matthew Wilcox wrote: > > I think you're missing the context. There are bugs in how this filesystem > handles intentionally-corrupted filesystems. That's being reported as > a critical bug because apparently some distributions automount HFS/HFS+ > filesystems

Re: [syzbot] [hfs?] WARNING in hfs_write_inode

On Thu, Jul 20, 2023 at 05:38:52PM -0400, Jeffrey Walton wrote: > On Thu, Jul 20, 2023 at 2:39 PM Matthew Wilcox wrote: > > > > On Thu, Jul 20, 2023 at 07:50:47PM +0200, John Paul Adrian Glaubitz wrote: > > > > Then we should delete the HFS/HFS+ filesystems. They're orphaned in > > > >

Re: [syzbot] [hfs?] WARNING in hfs_write_inode

On Thu, Jul 20, 2023 at 02:27:50PM -0400, Jeff Layton wrote: > On Thu, 2023-07-20 at 18:59 +0100, Matthew Wilcox wrote: > > On Thu, Jul 20, 2023 at 07:50:47PM +0200, John Paul Adrian Glaubitz wrote: > > > > Then we should delete the HFS/HFS+ filesystems. They're orphaned in > > > > MAINTAINERS

Re: [syzbot] [hfs?] WARNING in hfs_write_inode

On Thu, Jul 20, 2023 at 2:39 PM Matthew Wilcox wrote: > > On Thu, Jul 20, 2023 at 07:50:47PM +0200, John Paul Adrian Glaubitz wrote: > > > Then we should delete the HFS/HFS+ filesystems. They're orphaned in > > > MAINTAINERS and if distros are going to do such a damnfool thing, > > > then we

Re: [syzbot] [hfs?] WARNING in hfs_write_inode

On Thu, 2023-07-20 at 18:59 +0100, Matthew Wilcox wrote: > On Thu, Jul 20, 2023 at 07:50:47PM +0200, John Paul Adrian Glaubitz wrote: > > > Then we should delete the HFS/HFS+ filesystems. They're orphaned in > > > MAINTAINERS and if distros are going to do such a damnfool thing, > > > then we

Re: [syzbot] [hfs?] WARNING in hfs_write_inode

On Thu, Jul 20, 2023 at 07:50:47PM +0200, John Paul Adrian Glaubitz wrote: > > Then we should delete the HFS/HFS+ filesystems. They're orphaned in > > MAINTAINERS and if distros are going to do such a damnfool thing, > > then we must stop them. > > Both HFS and HFS+ work perfectly fine. And if

Re: LibreOffice bridges/smoketest on mips(64)el (was: Re: unbreaking LibreOffices tests on at least release architectures)

On Mon, Jul 03, 2023 at 09:31:29PM +0200, Rene Engelhard wrote: > Hi, > > Am 25.06.23 um 13:37 schrieb Rene Engelhard: > > > what about the > > > following: > > > - make all test failures fatal on a*64 (since upstream tests these), and > > > - make smoketest failures fatal on all architectures

Re: LibreOffice bridges/smoketest on mips(64)el (was: Re: unbreaking LibreOffices tests on at least release architectures)

Hi, Am 03.07.23 um 21:31 schrieb Rene Engelhard: Am 25.06.23 um 13:37 schrieb Rene Engelhard: what about the following: - make all test failures fatal on a*64 (since upstream tests these), and - make smoketest failures fatal on all architectures (including ports) That was implemented (+ two

LibreOffice bridges/smoketest on mips(64)el (was: Re: unbreaking LibreOffices tests on at least release architectures)

Hi, Am 25.06.23 um 13:37 schrieb Rene Engelhard: what about the following: - make all test failures fatal on a*64 (since upstream tests these), and - make smoketest failures fatal on all architectures (including ports) That was implemented (+ two more important tests) in experimental. See

Re: unbreaking LibreOffices tests on at least release architectures

Hi, Am 20.06.23 um 10:25 schrieb Adrian Bunk: On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote: Hi, Am 19.06.23 um 23:29 schrieb Rene Engelhard: The pragmatic option would be to run only a smoketest for build success on architectures not tested by upstream. And have

Re: unbreaking LibreOffices tests on at least release architectures

On Tue, 2023-06-20 at 22:46 +0200, Kurt Roeckx wrote: > Can I suggest that if you file a few bugs and add some information in > it so that maybe someone can look at it? If it only affects one > architecture, send a mail to that list asking for help. PS: when filing architecture-specific bugs,

Re: unbreaking LibreOffices tests on at least release architectures

Can I suggest that if you file a few bugs and add some information in it so that maybe someone can look at it? If it only affects one architecture, send a mail to that list asking for help. Kurt

Re: unbreaking LibreOffices tests on at least release architectures

Hi, Am 20.06.23 um 16:52 schrieb Kurt Roeckx: On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote: Hi, Am 19.06.23 um 23:29 schrieb Rene Engelhard: The pragmatic option would be to run only a smoketest for build success on architectures not tested by upstream. And have

Re: unbreaking LibreOffices tests on at least release architectures

On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote: > Hi, > > Am 19.06.23 um 23:29 schrieb Rene Engelhard: > > > The pragmatic option would be to run only a smoketest for build success > > > on architectures not tested by upstream. > > > > And have Format->Character in Impress crash

Re: unbreaking LibreOffices tests on at least release architectures

Stop sending these emails please! Sent from my iPhone > On 20 Jun 2023, at 09:42, Adrian Bunk wrote: > > On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote: >> Hi, >> >> Am 19.06.23 um 23:29 schrieb Rene Engelhard: The pragmatic option would be to run only a smoketest for

Re: unbreaking LibreOffices tests on at least release architectures

On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote: > Hi, > > Am 19.06.23 um 23:29 schrieb Rene Engelhard: > > > The pragmatic option would be to run only a smoketest for build success > > > on architectures not tested by upstream. > > > > And have Format->Character in Impress crash

Re: unbreaking LibreOffices tests on at least release architectures

On Mon, Jun 19, 2023 at 11:50 PM Rene Engelhard wrote: > > Am 20.06.23 um 00:03 schrieb Jeffrey Walton: > > > > You can usually uncover them by building the package with CFLAGS=" ... > > -fsanitize=undefined ... " and CXXFLAGS=" ... -fsanitize=undefined ... > > ". The UBsan sanitizer operates on

Re: unbreaking LibreOffices tests on at least release architectures

Hi, Am 19.06.23 um 23:29 schrieb Rene Engelhard: The pragmatic option would be to run only a smoketest for build success on architectures not tested by upstream. And have Format->Character in Impress crash with Bus error like on mipsel? That doesn't sound too good for basic quality. There

Re: unbreaking LibreOffices tests on at least release architectures

Hi, Am 20.06.23 um 00:03 schrieb Jeffrey Walton: You can usually uncover them by building the package with CFLAGS=" ... -fsanitize=undefined ... " and CXXFLAGS=" ... -fsanitize=undefined ... ". The UBsan sanitizer operates on real data. There are no false positives. I'd personally assume

Re: unbreaking LibreOffices tests on at least release architectures

On Mon, Jun 19, 2023 at 11:29:34PM +0200, Rene Engelhard wrote: >... > Am 19.06.23 um 23:19 schrieb Adrian Bunk: >... > > For such a complex package I would expect 32bit breakage in every > > release if upstream no longer tests on 32bit. > Indeed, though at least for 32bit *build* issues they keep

Re: unbreaking LibreOffices tests on at least release architectures

On Mon, Jun 19, 2023 at 5:30 PM Rene Engelhard wrote: > > Hi, > > Am 19.06.23 um 23:19 schrieb Adrian Bunk: > > On Sun, Jun 18, 2023 at 09:31:05AM +0200, Rene Engelhard wrote: > >> ... > >> I won't be of much help here unfortunately, except > >> maybe testing patches, but then again there's

Re: unbreaking LibreOffices tests on at least release architectures

On Sun, Jun 18, 2023 at 09:31:05AM +0200, Rene Engelhard wrote: >... > I won't be of much help here unfortunately, except > maybe testing patches, but then again there's porterboxes >... You are the only one who could realistically debug many of these. E.g. on armel it says: Fatal exception:

Re: unbreaking LibreOffices tests on at least release architectures

Hi, Am 19.06.23 um 23:19 schrieb Adrian Bunk: On Sun, Jun 18, 2023 at 09:31:05AM +0200, Rene Engelhard wrote: ... I won't be of much help here unfortunately, except maybe testing patches, but then again there's porterboxes ... You are the only one who could realistically debug many of these.

Re: unbreaking LibreOffices tests on at least release architectures

On Sunday 2023-06-18 23:37, Rob Landley wrote: >On 6/18/23 14:58, Rene Engelhard wrote: >>> Three years ago Samba maintainer Jeremy Allison lamented that "Both GPLv3 >>> and >>> the AGPL have been rejected soundly by most developers" and talked about >>> how he >>> regretted the move and the

Re: unbreaking LibreOffices tests on at least release architectures

On 6/18/23 15:19, Rene Engelhard wrote: > Besides that it would also have been clear from actually reading the IRC > log which incidentially also says Good to know what the expectations for participation are. >> This is the same GPLv3 package that Red Hat just dropped support for? > > As I

Re: unbreaking LibreOffices tests on at least release architectures

On June 18, 2023 11:37:55 PM GMT+02:00, Rob Landley wrote: >On 6/18/23 14:58, Rene Engelhard wrote: >>> Three years ago Samba maintainer Jeremy Allison lamented that "Both GPLv3 >>> and >>> the AGPL have been rejected soundly by most developers" and talked about >>> how he >>> regretted the

Re: unbreaking LibreOffices tests on at least release architectures

On 6/18/23 14:58, Rene Engelhard wrote: >> Three years ago Samba maintainer Jeremy Allison lamented that "Both GPLv3 and >> the AGPL have been rejected soundly by most developers" and talked about how >> he >> regretted the move and the damage it had done to the project, >>

Re: unbreaking LibreOffices tests on at least release architectures

Hi again, some more comments. Am 18.06.23 um 21:28 schrieb Rob Landley: No, that's how I read it too. You said getting the _architectures_ removed, not getting libreoffice removed from those architectures. That is hilarious. The subject says we are talking about LibreOffice here, not

Re: unbreaking LibreOffices tests on at least release architectures

Hi, Am 18.06.23 um 21:28 schrieb Rob Landley: Of course I mean "getting those architectures removed from unstable" *for libreoffice*. This is the same GPLv3 package that Red Hat just dropped support for? GPLv3 doesn't have anything to do with this here. https://lwn.net/Articles/933525/

Re: unbreaking LibreOffices tests on at least release architectures

On 6/18/23 03:45, Rene Engelhard wrote:> Am 18.06.23 um 10:32 schrieb Rene Engelhard: I don't really like sweeping it under the carpet again and would actually pursue the "getting those architectures removed from unstable" way pointed out and (implicitely) approved/suggested by the

Re: unbreaking LibreOffices tests on at least release architectures

> Le 18 juin 2023 à 13:37, Steve McIntyre a écrit : > > On Sun, Jun 18, 2023 at 10:32:55AM +0200, Rene Engelhard wrote: >> Hi, >> >>> Am 18.06.23 um 10:19 schrieb John Paul Adrian Glaubitz: >>> On Sun, 2023-06-18 at 09:31 +0200, Rene Engelhard wrote: Also note I am not talking about

Re: unbreaking LibreOffices tests on at least release architectures

On Sun, Jun 18, 2023 at 10:32:55AM +0200, Rene Engelhard wrote: >Hi, > >Am 18.06.23 um 10:19 schrieb John Paul Adrian Glaubitz: >> On Sun, 2023-06-18 at 09:31 +0200, Rene Engelhard wrote: >> > Also note I am not talking about the debian-ports architectures. Those I >> > forgot and I have no

Re: unbreaking LibreOffices tests on at least release architectures

Hi again. Am 18.06.23 um 10:32 schrieb Rene Engelhard: I don't really like sweeping it under the carpet again and would actually pursue the "getting those architectures removed from unstable" way pointed out and (implicitely) approved/suggested by the release team... You want Debian to drop

Re: unbreaking LibreOffices tests on at least release architectures

Hi, Am 18.06.23 um 10:19 schrieb John Paul Adrian Glaubitz: On Sun, 2023-06-18 at 09:31 +0200, Rene Engelhard wrote: Also note I am not talking about the debian-ports architectures. Those I forgot and I have no problems making them stay into "testsuite ran but results ignored" set. Why did

Re: unbreaking LibreOffices tests on at least release architectures

Hello! On Sun, 2023-06-18 at 09:31 +0200, Rene Engelhard wrote: > Also note I am not talking about the debian-ports architectures. Those I > forgot and I have no problems making them stay into "testsuite ran but > results ignored" set. Why did you send this mail exclusively to debian-ports then?

unbreaking LibreOffices tests on at least release architectures

Hi, I originally wanted to send the mail after all the architectures got result but now even after 6d mips64el didn't try it so I send it now. Prompted by riscv64 supposed to be added to the archive and even as a release arch for trixie - see

Solicitud de apoyo

Buenas tardes, favor de reenviar este comunicado al responsable de Compras y Dirección de la empresa. Hola. Me comunico con usted para ofrecerle mi ayuda en cómo mejorar los ingresos disminuyendo los gastos en compras, se trata de una conferencia Online este 8 de Marzo enfocada a mitigar los

Re: numpy - scipy circular build requires makes both packages unbuildable on ia64 and x32

Hi Mattias! On Mon, 2023-01-30 at 17:21 +0100, Mattias Ellert wrote: > Dependency installability problem for numpy on ia64: > > numpy build-depends on: > - python3-scipy:ia64 > python3-scipy depends on missing: > - python3:ia64 (< 3.11) > > Dependency installability problem for numpy on x32: >

numpy - scipy circular build requires makes both packages unbuildable on ia64 and x32

(According to https://wiki.debian.org/X32Port x32 issues should be sent to the debian-amd64 list.) https://buildd.debian.org/status/package.php?p=numpy=sid Dependency installability problem for numpy on ia64: numpy build-depends on: - python3-scipy:ia64 python3-scipy depends on missing: -

LibreOffice architecture support (was: Fwd: Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*))

Hi, I am not giung to fight for this - so if you want to keep - alpha - hppa - ia64 - m68k - powerpc and powerpcspe - sparc and sparc64 (which are for many BD-Uninstallable since ages because it does not have Java (anymore), didn't do a long-ago transition, ...) speak up at upstream

Wonderful! I discovered that UniFi Cloud Key Gen 2 Plus is powered by Debian Linux 9

Subject: Wonderful! I discovered that UniFi Cloud Key Gen 2 Plus is powered by Debian Linux 9 Good day from Singapore, Here are my findings on 21 Oct 2022 Friday. UniFi OS UCK G2 Plus 2.5.11 login as: root root@192.168.90.2's password: Linux Teo-En-Ming-Corporation 3.18.44-ui-qcom #1 SMP Mon

Re: enabling link time optimizations in package builds

Hi Matthias, * Matthias Klose [2022-06-17 10:18]: The proposal is to turn on LTO by default on most 64bit release architectures. Not proposing to do this on 32bit architectures because of the limited address space at link time, and up to now nobody tested LTO on 32bit archs. In test

enabling link time optimizations in package builds

Link time optimizations are an optimization that helps with a single digit percent number optimizing both for smaller size, and better speed. These optimizations are available for some time now in GCC. Link time optimizations are also at least turned on in other distros like Fedora, OpenSuse

Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA 5113-1] firefox-esr security update)

On Fri, Apr 15, 2022 at 09:07:10AM +0200, Elmar Stellnberger wrote: > That is not correct. You can make use of SSE instructions also in > x86_32/i386 mode. > > I found f.i.: > https://gcc.gcc.gnu.narkive.com/k0KqaZF2/i386-sse-test-question Well x86_64 uses it all the time, not just optionally,

Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA 5113-1] firefox-esr security update)

On Fri, Apr 15, 2022 at 10:18:17AM -0400, Hendrik Boom wrote: ... ... > > And i you're runnin Lisp programs, you'll definitely want a 32-bit > architecture, because Lisp fills memory with addresses. But you can do that > with add-architecture i286. Typo: Of course I meant i386. > > --

Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA 5113-1] firefox-esr security update)

On Fri, Apr 15, 2022 at 10:12:23AM +0200, Elmar Stellnberger wrote: > On 14.04.22 15:45, Levis Yarema wrote: > > Is there in deed any reason to prefer amd64 over i586 if you have the > > choice and a machine with 2GB RAM or less, apart from perhaps long term > > support? > > > > Depends on the

Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA 5113-1] firefox-esr security update)

On 14.04.22 15:45, Levis Yarema wrote: Is there in deed any reason to prefer amd64 over i586 if you have the choice and a machine with 2GB RAM or less, apart from perhaps long term support? Depends on the application. Encryption and decryption requiring the simulation of very larger

Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA 5113-1] firefox-esr security update)

On 15.04.22 04:50, Lennart Sorensen wrote: On Thu, Apr 14, 2022 at 03:45:37PM +0200, Levis Yarema wrote: Is there in deed any reason to prefer amd64 over i586 if you have the choice and a machine with 2GB RAM or less, apart from perhaps long term support? Twice the registers and sse

Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA 5113-1] firefox-esr security update)

On Thu, Apr 14, 2022 at 03:45:37PM +0200, Levis Yarema wrote: > Is there in deed any reason to prefer amd64 over i586 if you have the > choice and a machine with 2GB RAM or less, apart from perhaps long term > support? Twice the registers and sse instructions for fpu rather than x87? -- Len

  1   2   3   4   5   6   7   8   9   10   >