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__ > compile_time_assert(sizeof(MYSQL) == 1272); > #elif defined __i386__ > compile_time_assert(sizeof(MYSQL) == 964); > #endif > > How should I fix this for x32? What is the preprocessor if clause and > can I safely assume the size is 964? > > Previous x32 builds passed before upstream introduced this change. > References: > - https://wiki.debian.org/X32Port > - https://buildd.debian.org/status/logs.php?pkg=mariadb=x32 > - https://salsa.debian.org/mariadb-team/mariadb-server > >
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 x32? What is the preprocessor if clause and > can I safely assume the size is 964? The comment before this reads /* this limited check is enough, if sizeof(MYSQL) changes, it changes everywhere */ so this looks like an ABI stability check, validating not that MYSQL should be Some Specific Size, but that it's The Size It Was Last Time. IMO turn the first line into #if defined(__x86_64__) && !defined(__ILP32__) since they did actually just want to check if the size is the same they measured on amd64 and i386. And if it were to change on either of these two, it would change everywhere (apparently). Best, signature.asc Description: PGP signature
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__) compile_time_assert(sizeof(MYSQL) == 1272); #elif defined __i386__ compile_time_assert(sizeof(MYSQL) == 964); #endif How should I fix this for x32? What is the preprocessor if clause and can I safely assume the size is 964? Kind regards, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at There is NO CLOUD, just other people's computers. - FSFE LUGA : http://www.luga.at
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 defined __x86_64__ #if defined(__x86_64__) && !defined(__ILP32__) Of course you need more but the __ILP32__ symbol is typically used to distinguish x32 from amd64. To illustrate it it, e.g. snip --- #if defined __x86_64__ #if defined __ILP32__ compile_time_assert(sizeof(MYSQL) == 964); // x32 #else compile_time_assert(sizeof(MYSQL) == 1272); // amd64 #endif #elif defined __i386__ compile_time_assert(sizeof(MYSQL) == 964); // ix86 #endif snip --- compile_time_assert(sizeof(MYSQL) == 1272); #elif defined __i386__ compile_time_assert(sizeof(MYSQL) == 964); #endif How should I fix this for x32? What is the preprocessor if clause and can I safely assume the size is 964? Kind regards, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at There is NO CLOUD, just other people's computers. - FSFE LUGA : http://www.luga.at
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 2956 9546 0006 7426 3B37 F5B5 F913
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 the rust version of python-cryptography ☹ And gstreamer1.0 seems to depend on rust as well, which blocks glade and as such some gnome apps: https://buildd.debian.org/status/package.php?p=gstreamer1.0=sid Helge
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 ☹ bye, //mirabilos -- exceptions: a truly awful implementation of quite a nice idea. just about the worst way you could do something like that, afaic. it's like anti-design. that too… may I quote you on that? sure, tho i doubt anyone will listen ;)
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 meine *wirklich* schmutzige Tricks, wie bei einer doppelt verketteten Liste beide Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r
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: > >https://github.com/pyca/cryptography/issues/5771#issuecomment-775990406 > > Ouch. > > cbmuser also has hopes for rustc_codegen_gcc, but I believe that > quite a way off for regular use in Debian yet and won’t hold my > breath. > > So, perhaps at least do palliative care for the 3.8-based package > in the meantime? Porters can help, but we don’t know the python ecosystem well. Anyone had experience with the version 3.3 to 38.0 migration ? Maybe the API didn't change that much.
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 Ouch. cbmuser also has hopes for rustc_codegen_gcc, but I believe that quite a way off for regular use in Debian yet and won’t hold my breath. So, perhaps at least do palliative care for the 3.8-based package in the meantime? Porters can help, but we don’t know the python ecosystem well. bye, //mirabilos -- Gast: „Ein Bier, bitte!“ Wirt: „Geht auch alkoholfrei?“ Gast: „Geht auch Spielgeld?“
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 ports are unlikely to meet the dependencies soon > • new ports won’t meet them at first even if they may meet > them later (riscv64 and loong64 now meet them) > > For the t64 transition, I *think* I can just binNMU the last > version that worked and porter-upload that, but that’s not a > workable long-term solution, especially when python transitions > come, etc. > > Is there a chance your team could fork the old python-cryptography > source package (3.4.8-2) and do something like: > > • rename its python3-cryptography binary package to > python3-cryptography-rustless or something > • let that Provide python3-cryptography in the same version > > Making python3-cryptography-rustless available on all arches > has the benefit that people can test that their code will work > on ports arches without having to bother installing one of them. > > I’m not entirely sure that having python3-cryptography-rustless > Provides python3-cryptography, then other packages B-D/Depends > python3-cryptography will work; IIRC, there was something about > the first alternative must not be virtual and buildds won’t use > second+ alternatives. In that case, we’ll instead need the > python3-cryptography-rustless source package to build a second > binary package python3-cryptography either as arch:all but in a > lower version than the python-cryptography’s (if that’s okay), > or as arch:any on just the affected architectures (which will > end up being an annoying to maintain whitelist) that Depends > python3-cryptography-rustless, to keep things installable on > the buildds. > > With this in unstable proper, debian-ports will have a much > easier job, and maintainers (both of the python3-cryptography > ecosystem/packages and of software using it) can more easily > test things work, and your team can apply whatever new policy > changes, dh-* helpers, etc. to the 3.4.8-based package, and > backport bugfixes, etc. (and perhaps there’s even an upstream > fork?). > > The arches currently split as: > > • alpha 3.4.8-2 > • hppa 3.4.8-2 > • hurd-amd643.4.8-2 > • hurd-arm64unknown, probably 3.x > • hurd-i386 3.4.8-2 > • ia64 3.4.8-2 > • loong64 41.0.7-5 > • m68k 3.4.8-2 > • powerpc 41.0.7-3 > • ppc64 41.0.7-5 > • sh4 3.4.8-2 > • sparc64 41.0.7-5 > • x32 38.0.4-4 > > (x32 seems to be lagging in the rust department, too…) > > Since this exists mostly to help d-ports, it would be fine to > open an RC bug against it early to prevent it from showing up > in releases, if desired. > > Thanks for considering, > //mirabilos, helping out m68k for the time_t transition again > -- > When he found out that the m68k port was in a pretty bad shape, he did > not, like many before him, shrug and move on; instead, he took it upon > himself to start compiling things, just so he could compile his shell. > How's that for dedication. -- Wouter, about my Debian/m68k revival > 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: 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 much to bother, I think leaving it as is looks > > fine by me. But if this is causing problems as well and the x32 porters > > (if there's any remaining :), want to mask it alongside the other ports, > > let me know and I can also flip the switch for that one. > > If the porters would also like to see x32 masked, let me know and I > can also include it, otherwise I'll leave it as it is now. AFAIK for all ports architectures except Hurd and hppa the other Adrian is a porter, so should be able to ACK it. As I already wrote in [1] there is architecture other than alpha/ia64/x32 where the pie specs did actually enable PIE. On m68k and sh4 the specs might still be passed and cause FTBFS in packages like gluegen2 that pass LDFLAGS to ld, but there is no PIE enabling effect. > Thanks, > Guillem cu Adrian [1] https://lists.debian.org/debian-alpha/2023/10/msg2.html
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, I'm inclined to completely mask PIE > in dpkg-buildflags for alpha and ia64 in around a couple of weeks, > if I don't hear anything. I've now queued locally a commit masking this for alpha and ia64 and will be including it in dpkg 1.22.2, probably by the end of the weekend. To the porters, please let me know if you'd prefer these not to be masked. > If PIE (via specs files) appears to work on x32, and changing the > defaults in gcc is too much to bother, I think leaving it as is looks > fine by me. But if this is causing problems as well and the x32 porters > (if there's any remaining :), want to mask it alongside the other ports, > let me know and I can also flip the switch for that one. If the porters would also like to see x32 masked, let me know and I can also include it, otherwise I'll leave it as it is now. Thanks, Guillem
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
> > >
> > > I suspect x32 might be able to default to PIE without problems
> > > (there might just not be enough interest left to change the default).
> > >
> > > On alpha the toolchain has already become quite brittle
> > > with frequent issues like (reproducible) linker segfaults,
> > > any variations that affects the toolchain are bad.
> > >
> > > It is for the port maintainers to decide whether or not PIE
> > > is considered stable on a port, and accordingly either make
> > > it default (which also avoids the other issues below) or not.
> > >
> > > It is clear that a non-PIE architecture would no longer be
> > > considered suitable as release architecture.
> >
> > In general the way this is handled in dpkg, is that if the flags
> > supposedly work on that arch they are allowed, but if they are not
> > supported or are broken then they are masked.
I recalled this report before the 1.22.1 release, but didn't feel it
appropriate to push a last minute change for it, before giving some
advance notice, and because I was also expecting some word from the
relevant arch porters.
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, I'm inclined to completely mask PIE
in dpkg-buildflags for alpha and ia64 in around a couple of weeks,
if I don't hear anything.
> > > Please drop pie-{compile,link}.spec, on the architectures
> > > where it has any effect it is doing more harm than good.
> >
> > For example hppa has pie masked for build flags. If the porters for
> > alpha and/or ia64 consider that they should also get pie masked for
> > those arches, I'm fine doing the changes. Although that means on those
> > ports it will not be possible to enable pie at all, even if asked for
> > explicitly, as in «hardening=+pie».
>
> Semi-PIE non-release architectures shouldn't exist, PIE on an·
> architecture should be a binary option decided by the porters
> for this architecture.
>
> If there are any porters left on an architecture and they consider PIE·
> stable, they can always ask the gcc maintainer to change the default.[1]
>
> >...
> > > The lowest effort fix would be to patch debian/rules of affected
> > > packages to disable hardening=+pie on affected architectures,
> > > but that would still be spending time on working around a problem
> > > that shouldn't exist.
> >
> > Yeah, that does not look like the right thing to be spending time on.
> >...
>
> As long as we have at least one semi-PIE architecture, this is the only·
> realistic option for porters. If the porters for alpha and/or ia64 want·
> to have pie masked, such changes will still be required for x32.
If PIE (via specs files) appears to work on x32, and changing the
defaults in gcc is too much to bother, I think leaving it as is looks
fine by me. But if this is causing problems as well and the x32 porters
(if there's any remaining :), want to mask it alongside the other ports,
let me know and I can also flip the switch for that one.
Thanks,
Guillem
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 > >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? 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 spec + related files anywhere? >> See Overview: >> >> https://build.opensuse.org/package/show/openSUSE:Factory:RISCV/libreoffice > > Thanks. > > > I don't see anyone obvious there (except not running *any* test) there > offhand, though. I tried to enable the smoketest, but it fails even on x86-64: https://build.opensuse.org/project/show/home:Andreas_Schwab:riscv:libreoffice Since I don't know much about the libreoffice sources, I have just copied the %check section from an old revision of our libreoffice package. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
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 these days. > > I think the value of filesystem code is not just a question of how often > it gets executed -- it's also about retaining access to the data collected > in archives, museums, galleries etc. that is inevitably held in old > formats. t the very least, keep enough system around that the files in obsolete file-systems can be read and converted to current file-systems. -- hendrik
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 > >> other architectures there is the mail now. riscv64 is different because > >> the failures are even more big than any other down below and it's actually > >> a new architecture anyway. > > Libreoffice is actually basically working on riscv64. > > Yes. _basically_. (Only with -O0 or maybe -Os as upstreams makefile > says, though) Be careful of -Os. I test one of my C++ libraries with it in the library's test suite. Based on unexplained crashes with -Os, I believe GCC produces bad code with -Os on occasion. I do not recommend using -Os in production based on my experience. Jeff
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? 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 spec + related files anywhere? See Overview: https://build.opensuse.org/package/show/openSUSE:Factory:RISCV/libreoffice Thanks. I don't see anyone obvious there (except not running *any* test) there offhand, though. Even many system-libraries - as I do. Except maybe gcc 12 vs. gcc 13 which might affect the optimization breakage... Will have look some more, though. (And retry with gcc 13 which is default in Debian now, too) Regards, Rene
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... > > But maybe I am too blind. > > I don't see the actual spec + related files anywhere? See Overview: https://build.opensuse.org/package/show/openSUSE:Factory:RISCV/libreoffice -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
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 you tried java 19 or 20? -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
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 spec + related files anywhere? Repositories isn't it either, it just gives me (src)rpms. I could look there, but... (Though I would more bet of some system evironment thingy) Perhaps it is a matter of using a good java. Have you tried java 19 or 20? No, 17 only. The test extension in the smoketest indeed is Java, but given this also affects python extensions (lightproof) I'd bet it 's a general, non-Java issue. Even if Java was broken lightproof should have worked. Regards, Rene
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 other files needed which are not ending up in the installation. You build it and run make subsequentcheck in smoketest (or a general make check). But you might need to build prereqs first, see https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/blob/master/rules#L2340 ff. Regards, Rene
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
All deployed bundled extensions:
Identifier: org.openoffice.en.hunspell.dictionaries
Version: 2022.05.01
URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/lightproof-en
is registered: yes
Media-Type: application/vnd.sun.star.package-bundle
Description:
bundled Packages: {
URL:
vnd.sun.star.expand:$BUNDLED_EXTENSIONS/lightproof-en/Lightproof.components
is registered: yes
Media-Type: application/vnd.sun.star.uno-components
Description:
URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/lightproof-en/Linguistic.xcu
is registered: yes
Media-Type: application/vnd.sun.star.configuration-data
Description:
}
Interesting.
Now the question is what is different between openSUSEs libreoffice
package and Debians...
Does opensuse have some public git/$VCS?
(Though I would more bet of some system evironment thingy)
Regards,
Rene
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 flags, >> wich includes full optimisation and hardening. > > 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? -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
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: org.openoffice.en.hunspell.dictionaries
Version: 2022.05.01
URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/lightproof-en
is registered: yes
Media-Type: application/vnd.sun.star.package-bundle
Description:
bundled Packages: {
URL:
vnd.sun.star.expand:$BUNDLED_EXTENSIONS/lightproof-en/Lightproof.components
is registered: yes
Media-Type: application/vnd.sun.star.uno-components
Description:
URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/lightproof-en/Linguistic.xcu
is registered: yes
Media-Type: application/vnd.sun.star.configuration-data
Description:
}
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
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 which neither register when > registering manually nor when being installed as bundled extensions (see > the discussion in this thread, not going to reiterate) How can I test that? I have never used libreoffice before, so I don't know what to look for. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
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 fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
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 something completely different."
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. And those are extensions written in python which neither register when registering manually nor when being installed as bundled extensions (see the discussion in this thread, not going to reiterate) How can I test that? I have never used libreoffice before, so I don't know what to look for. https://lists.debian.org/debian-riscv/2023/07/msg00010.html https://lists.debian.org/debian-riscv/2023/07/msg00014.html (some of them says mips64el, but as said in my other replies, the smoketest failure is the same symptom there, just on riscv64 actual unopkg add does nothing effectively.) Regards, Rene
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. Which gives the smoketest test failure here I pointed out (again) in my other mail. Regards. Rene
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 exactly a thread which (later) talks about extensions being broken. So I wonder why you didn' t take the previous mails into account? 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. https://lists.debian.org/debian-riscv/2023/07/msg1.html is for the smoketest (that one's mips64el, but same symptom on riscv64) Regards, Rene
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, hyphenation and grammer checking. Or turkish spellchecing. And those are extensions written in python which neither register when registering manually nor when being installed as bundled extensions (see the discussion in this thread, not going to reiterate) (Whether one needs the NLPSolver or Wiki Publisher or so can definitely be discussed, though) Regards, Rene
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 other down below and it's actually > a new architecture anyway. Libreoffice is actually basically working on riscv64. I have tested it with openSUSE Tumbleweed on BeagleV Beta and Hifive Unmatched (with an AMD graphics card). -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
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 because the failures are even more big than any other down below and it's actually a new architecture anyway. Libreoffice is actually basically working on riscv64. Yes. _basically_. (Only with -O0 or maybe -Os as upstreams makefile says, though) Which can be enough, but also can be not. I have tested it with openSUSE Tumbleweed on BeagleV Beta and Hifive Unmatched (with an AMD graphics card). Just not registering or unregistering *any* extension. Neither manually nor if installing any bundled extension. At least here. And that included packaged extensions so if they install but don't work that's a grave bug. Regards, Rene
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 incorrect. The HFS file system has gotten zero development attention and the bugs were not the result of the API changes. The main issue here is that the HFS file system does not have maintainer, and decreasing the workload will not magically make someone appear with deep knowledge of that particular part of the code base. It's also the case that the actual amount of work on the "overloaded maintainers" caused by API changes is minimal --- it's dwarfed by syzbot noise (complaints from syzbot that aren't really bugs, or for really outré threat models). API changes within the kernel are the responsibility of the people making the change. For example, consider all of the folio changes that have been landing in the kernel; the amount of extra work on the part of most file system maintainers is minimal, because it's the people making the API changes who update the file system. I won't say that it's _zero_ work, because file system maintainers review the changes, and we run regression tests, and we sometimes need to point out when a bug has been introduced --- at which point the person making the API change has the responsibility of fixing or reverting the change. An unstable API are much painful for out-of-tree kernel code. But upstream kernel developers aren't really concerned with out-of-tree kernel code, except to point out that the work of the people who are promulgated out-of-tree modules would be much less if they actually got them cleaned up and made acceptable for upstream inclusion. - Ted
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 back out. There's no API change to blame. > It's always been buggy and it's never mattered before. > 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.
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 these days. > > I think the value of filesystem code is not just a question of how often > it gets executed -- it's also about retaining access to the data collected > in archives, museums, galleries etc. that is inevitably held in old > formats. That's an argument for adding support to tar, not for maintaining read/write support. > > We need to much more proactive about dropping support for unmaintained > > filesystems that nobody is ever fixing despite the constant stream of > > corruption- and deadlock- related bugs reported against them. > > IMO, a stream of bug reports is not a reason to remove code (it's a reason > to revert some commits). > > Anyway, that stream of bugs presumably flows from the unstable kernel API, > which is inherently high-maintenance. It seems that a stable API could be > more appropriate for any filesystem for which the on-disk format is fixed > (by old media, by unmaintained FLOSS implementations or abandoned > proprietary implementations). 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 back out. There's no API change to blame. It's always been buggy and it's never mattered before. It wouldn't be so bad if Google had also decided to fund people to fix those bugs, but no, they've decided to dump them on public mailing lists and berate developers into fixing 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 of how often it gets executed -- it's also about retaining access to the data collected in archives, museums, galleries etc. that is inevitably held in old formats. > > We need to much more proactive about dropping support for unmaintained > filesystems that nobody is ever fixing despite the constant stream of > corruption- and deadlock- related bugs reported against them. > IMO, a stream of bug reports is not a reason to remove code (it's a reason to revert some commits). Anyway, that stream of bugs presumably flows from the unstable kernel API, which is inherently high-maintenance. It seems that a stable API could be more appropriate for any filesystem for which the on-disk format is fixed (by old media, by unmaintained FLOSS implementations or abandoned proprietary implementations). Being in userspace, I suppose FUSE could be a stable API though I imagine it's not ideal in the sense that migrating kernel code there would be difficult. Maybe userspace NFS 4 would be a better fit? (I've no idea, I'm out of my depth in /fs...) Ideally, kernel-to-userspace code migration would be done with automatic program transformation -- otherwise it would become another stream of bugs.
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 presented to them on a USB key. Nobody is being paid to fix > these bugs. Nobody is volunteering to fix these bugs out of the kindness > of their heart. What choice do we have but to remove the filesystem, > regardless of how many happy users it has? You're being silly. We have tons of sane options. The obvious one is "just don't mount untrusted media". Now, the kernel doesn't know which media is trusted or not, since the kernel doesn't actually see things like /etc/mtab and friends. So we in the kernel can't do that, but distros should have a very easy time just fixing their crazy models. Saying that the kernel should remove a completely fine filesystem just because some crazy use-cases that nobody cares about are broken, now *that* just crazy. Now, would it be good to have a maintainer for hgs? Obviously. But no, we don't remove filesystems just because they don't have maintainers. And no, we have not suddenly started saying "users don't matter". Linus
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 > > > > 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 distributions or users are > > > so > > > sensitive about security, it's up to them to blacklist individual features > > > in the kernel. > > > > > > Both HFS and HFS+ have been the default filesystem on MacOS for 30 years > > > and I don't think it's justified to introduce such a hard compatibility > > > breakage just because some people are worried about theoretical evil > > > maid attacks. > > > > > > HFS/HFS+ mandatory if you want to boot Linux on a classic Mac or PowerMac > > > and I don't think it's okay to break all these systems running Linux. > > > > If they're so popular, then it should be no trouble to find somebody > > to volunteer to maintain those filesystems. Except they've been > > marked as orphaned since 2011 and effectively were orphaned several > > years before that (the last contribution I see from Roman Zippel is > > in 2008, and his last contribution to hfs was in 2006). > > One data point may help.. I've been running Linux on an old PowerMac > and an old Intel MacBook since about 2014 or 2015 or so. I have needed > the HFS/HFS+ filesystem support for about 9 years now (including that > "blessed" support for the Apple Boot partition). > > There's never been a problem with Linux and the Apple filesystems. > Maybe it speaks to the maturity/stability of the code that already > exists. The code does not need a lot of attention nowadays. > > Maybe the orphaned status is the wrong metric to use to determine > removal. Maybe a better metric would be installation base. I.e., how > many users use the filesystem. 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 presented to them on a USB key. Nobody is being paid to fix these bugs. Nobody is volunteering to fix these bugs out of the kindness of their heart. What choice do we have but to remove the filesystem, regardless of how many happy users it has?
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 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 distributions or users are > > > so > > > sensitive about security, it's up to them to blacklist individual features > > > in the kernel. > > > > > > Both HFS and HFS+ have been the default filesystem on MacOS for 30 years > > > and I don't think it's justified to introduce such a hard compatibility > > > breakage just because some people are worried about theoretical evil > > > maid attacks. > > > > > > HFS/HFS+ mandatory if you want to boot Linux on a classic Mac or PowerMac > > > and I don't think it's okay to break all these systems running Linux. > > > > If they're so popular, then it should be no trouble to find somebody > > to volunteer to maintain those filesystems. Except they've been > > marked as orphaned since 2011 and effectively were orphaned several > > years before that (the last contribution I see from Roman Zippel is > > in 2008, and his last contribution to hfs was in 2006). > > 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. > > Is "staging" still a thing? Maybe we should move these drivers into the > staging directory and pick a release where we'll sunset it, and then see > who comes out of the woodwork? No, the train wreck of filesystems in staging proved that it wasn't a viable process. We should just follow the same process as we are using for reiser - mark it as deprecated in place, pick a date that we are going to remove it, then add a warning (both runtime, in kconfig and probably in the kernel filesystem documentation) that it is deprecated and support is going to be removed at a certain date. We should be applying the same criteria and process for all the other filesystems that are orphaned, too. We need to much more proactive about dropping support for unmaintained filesystems that nobody is ever fixing despite the constant stream of corruption- and deadlock- related bugs reported against them. -Dave. -- Dave Chinner da...@fromorbit.com
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 must stop them. > > > > Both HFS and HFS+ work perfectly fine. And if distributions or users are so > > sensitive about security, it's up to them to blacklist individual features > > in the kernel. > > > > Both HFS and HFS+ have been the default filesystem on MacOS for 30 years > > and I don't think it's justified to introduce such a hard compatibility > > breakage just because some people are worried about theoretical evil > > maid attacks. > > > > HFS/HFS+ mandatory if you want to boot Linux on a classic Mac or PowerMac > > and I don't think it's okay to break all these systems running Linux. > > If they're so popular, then it should be no trouble to find somebody > to volunteer to maintain those filesystems. Except they've been > marked as orphaned since 2011 and effectively were orphaned several > years before that (the last contribution I see from Roman Zippel is > in 2008, and his last contribution to hfs was in 2006). One data point may help.. I've been running Linux on an old PowerMac and an old Intel MacBook since about 2014 or 2015 or so. I have needed the HFS/HFS+ filesystem support for about 9 years now (including that "blessed" support for the Apple Boot partition). There's never been a problem with Linux and the Apple filesystems. Maybe it speaks to the maturity/stability of the code that already exists. The code does not need a lot of attention nowadays. Maybe the orphaned status is the wrong metric to use to determine removal. Maybe a better metric would be installation base. I.e., how many users use the filesystem. Jeff
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 must stop them. > > > > Both HFS and HFS+ work perfectly fine. And if distributions or users are so > > sensitive about security, it's up to them to blacklist individual features > > in the kernel. > > > > Both HFS and HFS+ have been the default filesystem on MacOS for 30 years > > and I don't think it's justified to introduce such a hard compatibility > > breakage just because some people are worried about theoretical evil > > maid attacks. > > > > HFS/HFS+ mandatory if you want to boot Linux on a classic Mac or PowerMac > > and I don't think it's okay to break all these systems running Linux. > > If they're so popular, then it should be no trouble to find somebody > to volunteer to maintain those filesystems. Except they've been > marked as orphaned since 2011 and effectively were orphaned several > years before that (the last contribution I see from Roman Zippel is > in 2008, and his last contribution to hfs was in 2006). 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. Is "staging" still a thing? Maybe we should move these drivers into the staging directory and pick a release where we'll sunset it, and then see who comes out of the woodwork? Cheers, -- Jeff Layton
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 distributions or users are so > sensitive about security, it's up to them to blacklist individual features > in the kernel. > > Both HFS and HFS+ have been the default filesystem on MacOS for 30 years > and I don't think it's justified to introduce such a hard compatibility > breakage just because some people are worried about theoretical evil > maid attacks. > > HFS/HFS+ mandatory if you want to boot Linux on a classic Mac or PowerMac > and I don't think it's okay to break all these systems running Linux. If they're so popular, then it should be no trouble to find somebody to volunteer to maintain those filesystems. Except they've been marked as orphaned since 2011 and effectively were orphaned several years before that (the last contribution I see from Roman Zippel is in 2008, and his last contribution to hfs was in 2006).
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 (including ports) > > That was implemented (+ two more important tests) in experimental. See > https://buildd.debian.org/status/package.php?p=libreoffice > > It does > - bridgetest > - smoketest > - pyuno > > What fails for release archs astonishingly is only mips(64)el. It also failed on riscv64 (and powerpc), so that seems to be a criteria that catches the known-broken builds. >... > This test extension to be installed is a Java extension. > So I am running a nojava build on eller now... I don't really like disabling > Java since this opens Pandoras box but for mips64el we probably could do > that. It would also hint at a MIPS problem in LibreOffice, which might or might not be specific to Java. AFAIK OpenJDK on MIPS does not have any known major issues. The Zero build of OpenJDK on MIPS is of course slow, but that's also true on armel where the build succeeded. > Regards, > > Rene cu Adrian BTW: The MIPS-specific discussion should continue on debian-mips instead of debian-ports.
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 more important tests) in experimental. See https://buildd.debian.org/status/package.php?p=libreoffice https://buildd.debian.org/status/package.php?p=libreoffice=experimental of course. Regards, Rene
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
https://buildd.debian.org/status/package.php?p=libreoffice
It does
- bridgetest
- smoketest
- pyuno
What fails for release archs astonishingly is only mips(64)el. Let's
continue on -mips...
For that matter mipsel seems to be even more broken. A --without-java
builds also breaks at the smoketest with a segfault (tried on eller):
That said even the most important test fails. The bridgetest:
[build BIN] testtools
S=/PKGBUILDDIR I=$S/instdir
W=$S/workdir mkdir -p $W/Module/nonl10n/ touch
$W/Module/nonl10n/testtools
S=/PKGBUILDDIR I=$S/instdir
W=$S/workdir
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}$I/program:$I/program
$I/program/uno.bin -s com.sun.star.test.bridge.BridgeTest --
com.sun.star.test.bridge.CppTestObject
-env:LO_BUILD_LIB_DIR=file://$W/LinkTarget/Library
-env:URE_MORE_SERVICES=file://$W/Rdb/uno_services.rdb
-env:URE_MORE_TYPES=file://$W/UnoApiTarget/bridgetest.rdb
[build MOD] testtools
S=/PKGBUILDDIR I=$S/instdir
W=$S/workdir mkdir -p $W/Module/
touch $W/Module/testtools
### bool does not match! failed
### char does not match! failed
### byte does not match! failed
### short does not match! failed
### unsigned short does not match! failed
### long does not match! failed
### unsigned long does not match! failed
### hyper does not match! failed
### unsigned hyper does not match! failed
### enum does not match! failed
### byte2 does not match! failed
### short2 does not match! failed
struct comparison test failed
ppc-style alignment test failed
ppc64-style alignment test failed
### bool does not match! failed
### char does not match! failed
### byte does not match! failed
### short does not match! failed
### unsigned short does not match! failed
### long does not match! failed
### unsigned long does not match! failed
### hyper does not match! failed
### unsigned hyper does not match! failed
### enum does not match! failed
### byte2 does not match! failed
### short2 does not match! failed
recursive test results failed
remote multi failed: 11 != -1715038976
local multi failed: 11 != -1715038976
standard test failed
exception occurred: error: test failed! at
./testtools/source/bridgetest/bridgetest.cxx:1271
error: error: test failed! at
./testtools/source/bridgetest/bridgetest.cxx:1271
dying...make[3]: ***
[/PKGBUILDDIR/testtools/CustomTarget_uno_test.mk:25:
/PKGBUILDDIR/workdir/CustomTarget/testtools/uno_test.done]
Error 1
So the smoketest isn't even ran.
-> mipsel is fundamentally broken and libreoffice probably be removed
from it.
For mips64el I do have some hope as the failure is
[build CUT] smoketest
S=/PKGBUILDDIR I=$S/instdir
W=$S/workdir mkdir -p $W/CppunitTest/ rm -fr
$W/CppunitTest/smoketest.test.user cp -r $W/unittest
$W/CppunitTest/smoketest.test.user
rm -fr $W/CppunitTest/smoketest.test.core mkdir
$W/CppunitTest/smoketest.test.core cd
$W/CppunitTest/smoketest.test.core ( MAX_CONCURRENCY=4
MOZILLA_CERTIFICATE_FOLDER=dbm: SAL_DISABLE_SYNCHRONOU
S_PRINTER_DETECTION=1 SAL_USE_VCLPLUGIN=svp LIBO_LANG=C
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}$I/program:$I/program:$W/UnpackedTarball/cppunit/src/cppunit/.libs
$W/LinkTarget/Executable/cppunittester $W
/LinkTarget/CppunitTest/libtest_smoketest.so --headless
-env:BRAND_BASE_DIR=file://$S/instdir
-env:BRAND_SHARE_SUBDIR=share
-env:BRAND_SHARE_RESOURCE_SUBDIR=program/resource
-env:UserInstallation=
file://$W/CppunitTest/smoketest.test.user
-env:UNO_TYPES=file://$I/program/types.rdb
file://$I/program/types/offapi.rdb
-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb
-env:URE_BIN_DIR=file://$I/program
-env:URE_INTERNAL_LIB_DIR=file://$I/program
-env:LO_LIB_DIR=file://$I/program
-env:LO_JAVA_DIR=file://$I/program/classes --protector
$W/LinkTarget/Library/unoexceptionprotector.so unoexceptionprotector
--protector $W/LinkTarget/Library/un
obootstrapprotector.so unobootstrapprotector
-env:arg-soffice=path:$I/program/soffice
-env:arg-user=$W/CustomTarget/smoketest
-env:arg-env=LD_LIBRARY_PATH${LD_LIBRARY_PATH+=$LD_LIBRARY_PATH}
-env:arg-testarg.smoketest.doc=$W
/Zip/smoketestdoc.sxw
-env:CPPUNITTESTTARGET=$W/CppunitTest/smoketest.test )
21
[_RUN_] (anonymous namespace)::Test::test
(process:2108170): dconf-CRITICAL **: 05:13:49.716: unable to create
directory '/run/user/2952/dconf': Permission denied. dconf will not
work properly.
Fontconfig error: No writable cache directories
Fontconfig error: No writable cache directories
(process:2108244): dconf-CRITICAL **: 05:13:50.371: unable to create
directory '/run/user/2952/dconf': Permission denied. dconf will not
work properly.
Fontconfig error: No writable cache directories
Fontconfig
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 Format->Character in Impress crash with Bus error like on
mipsel? That doesn't sound too good for basic quality.
There is a "smoketest" but it does just basic start. open, close stuff.
Not even basic usage.
That said, that is the smoketest on mipsel:
...
Assuming the smoketest currently also fails on riscv64,
It thankfully does, because it fails the smoketest (:-)) because its
"does a (Java) extension install?" test fails.
(Which autopkgtest disables and makes an own test out of this anyway.)
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)
Sounds OKish, but that won't help the architectures even failing the
smoketest.
For that matter mipsel seems to be even more broken. A --without-java
builds also breaks at the smoketest with a segfault (tried on eller):
m -rf /home/rene/libreoffice-7.5.4/workdir/CustomTarget/smoketest
mkdir -p /home/rene/libreoffice-7.5.4/workdir/CustomTarget/smoketest/user
cp /home/rene/libreoffice-7.5.4/qadevOOo/qa/registrymodifications.xcu
/home/rene/libreoffice-7.5.4/workdir/CustomTarget/smoketest/user
[build CUT] smoketest
S=/home/rene/libreoffice-7.5.4 && I=$S/instdir && W=$S/workdir && mkdir
-p $W/CppunitTest/ && rm -fr $W/CppunitTest/smoketest.test.user && cp -r
$W/unittest $W/CppunitTest/smoketest.test.user && rm -fr
$W/CppunitTest/smoketest.test.core && mkdir
$W/CppunitTest/smoketest.test.core && cd
$W/CppunitTest/smoketest.test.core && ( MAX_CONCURRENCY=4
MOZILLA_CERTIFICATE_FOLDER=dbm:
SAL_DISABLE_SYNCHRONOUS_PRINTER_DETECTION=1 SAL_USE_VCLPLUGIN=svp
LIBO_LANG=C
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program":$W/UnpackedTarball/cppunit/src/cppunit/.libs
$W/LinkTarget/Executable/cppunittester $W/L
inkTarget/CppunitTest/libtest_smoketest.so --headless
"-env:BRAND_BASE_DIR=file://$S/instdir" "-env:BRAND_SHARE_SUBDIR=share"
"-env:BRAND_SHARE_RESOURCE_SUBDIR=program/resource"
"-env:UserInstallation=file://$W/CppunitTest/smoketest.test.user"
"-env:UNO_TYPES=file://$I/program/types.rdb
file://$I/program/types/offapi.rdb"
"-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb"
-env:URE_BIN_DIR=file://$I/program
-env:URE_INTERNAL_LIB_DIR=file://$I/program
-env:LO_LIB_DIR=file://$I/program
-env:LO_JAVA_DIR=file://$I/program/classes --protector
$W/LinkTarget/Library/unoexceptionprotector.so unoexceptionprotector
--protector $W/Lin
kTarget/Library/unobootstrapprotector.so unobootstrapprotector
-env:arg-soffice=path:$I/program/soffice
-env:arg-user=$W/CustomTarget/smoketest
-env:arg-env=LD_LIBRARY_PATH"${LD_LIBRARY_PATH+=$LD_LIBRARY_PATH}"
-env:arg-testarg.smoketest.doc=$W/Zip/smoketestdoc.sxw
"-env:CPPUNITTESTTARGET=$W/CppunitTest/smoketest.test" ) 2>&1
[_RUN_] (anonymous namespace)::Test::test
Fatal exception: Signal 11
Stack:
/home/rene/libreoffice-7.5.4/instdir/program/libuno_sal.so.3(+0x49b08)[0x77ec9b08]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_sal.so.3(+0x49d38)[0x77ec9d38]
linux-vdso.so.1(+0x550)[0x7ff4e550]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_cppu.so.3(+0x15d94)[0x772d5d94]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_cppu.so.3(+0x1d1fc)[0x772dd1fc]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_cppu.so.3(uno_copyAndConvertData+0x30)[0x772da974]
/home/rene/libreoffice-7.5.4/instdir/program/libgcc3_uno.so(+0xbf8c)[0x6ca0bf8c]
/home/rene/libreoffice-7.5.4/instdir/program/libgcc3_uno.so(+0xcbc4)[0x6ca0cbc4]
/home/rene/libreoffice-7.5.4/instdir/program/libreflectionlo.so(+0x2942c)[0x63fc942c]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x94ca0)[0x76794ca0]
/home/rene/libreoffice-7.5.4/instdir/program/libsvllo.so(_ZN14SfxBroadcaster9BroadcastERK7SfxHint+0x6c)[0x75f93a3c]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN11SbxVariable9BroadcastE9SfxHintId+0x16c)[0x768986e8]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN8SbxValueC2ERKS_+0xb0)[0x768906c8]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN11SbxVariableC2ERKS_+0x44)[0x76898874]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN9SbxMethodC1ERKS_+0x50)[0x768881f4]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x13d69c)[0x7683d69c]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x13e3cc)[0x7683e3cc]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x131008)[0x76831008]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0xb4534)[0x767b4534]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0xb5378)[0x767b5378]
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, please also set the BTS usertags and XCC the ports lists for the architectures effected. https://wiki.debian.org/Teams/Debbugs/ArchitectureTags -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
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 Format->Character in Impress crash with Bus error like on mipsel? That doesn't sound too good for basic quality. There is a "smoketest" but it does just basic start. open, close stuff. Not even basic usage. That said, that is the smoketest on mipsel: The problem with a mail like this is that it really doesn't help anybody in understanding the problem. As porter, it will probably take a lot of time to get to the point where you can start looking at what the problem might be. It contains lots of information, but it's not clear what the problem is and what needs to be looked at. Except by just starting to build and run into an issue (process:8700): dconf-CRITICAL **: 02:36:13.575: unable to create directory '/run/user/2952/dconf': Permission denied. dconf will not work properly. (process:8708): dconf-CRITICAL **: 02:36:19.328: unable to create directory '/run/user/2952/dconf': Permission denied. dconf will not work properly. (process:8815): dconf-CRITICAL **: 02:36:52.467: unable to create directory '/run/user/2952/dconf': Permission denied. dconf will not work properly. Is this something the porter should look at? Is is relevant? No. That also happens everywhere, also on amd64/arm64. Fatal exception: Signal 11 It's a segfault, I know :) this should normally be trivial for you to debug, but is probably complicated for a porter to find out how to do things like attaching a debugger to the relevant process. Well, the command line is there, but I see the point. Still one could talk about this... I yet have to hear from any porter talking about actual issues (and the buildlogs *are* there). Stack: /<>/instdir/program/libuno_sal.so.3(+0x49b18)[0x77d69b18] /<>/instdir/program/libuno_sal.so.3(+0x49d48)[0x77d69d48] /usr/lib/jvm/java-17-openjdk-mipsel/lib/server/libjvm.so(+0x537b8c)[0x62417b8c] Is this some openjdk problem, not a problem in libreoffice problem? In this specific case probably openjdk. I was juat answering Adrian on the smoketest. Actually I run a --disable-java build on eller right now. ./smoketest/smoketest.cxx:187:(anonymous namespace)::Test::test assertion failed - Expression: connection_.isStillAlive() So the (TCP?) connection is not alive? Why not? That doesn't seem to be platform specific. Is that a problem in the test suite, and not libreoffice itself? Because libreoffice crashed, "obviously", so there of course is no connection anymore. The point here is that it even crashes at startup so probably being completely broken. (and I am not surprised) unknown:0:(anonymous namespace)::Test::test tearDown() failed - An uncaught exception of type com.sun.star.lang.DisposedException - Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048 (anonymous namespace)::Test::test finished in: 76764ms smoketest.cxx:187:Assertion Test name: (anonymous namespace)::Test::test assertion failed - Expression: connection_.isStillAlive() ##Failure Location unknown## : Error Test name: (anonymous namespace)::Test::test tearDown() failed - An uncaught exception of type com.sun.star.lang.DisposedException And then the test suite crashes because it can't actually deal with the previous the assertion failure, and the segfault above is not relevant at all? It crashes because libreoffice crashed, the connection is not there and therefore not alive. Yes, I can read that. As said, I was just pointing at a smoketest example. The most likely thing is that this is not a platform specific issue, but a either a general issue that just shows up on some platforms for whatever reason, or some problem in an other piece of software that libreoffice is using that does have a pratform specific issue. This specific one might be, yes. That's probably not true for the other architectures' failures. (E.g. the Bus error I mentioned earlier or the powerpcs having "Trace/breakpoint trap (core dumped)" or s390x or armel crashing in loading tiff files. And that is all only the first failure on earch archs, there's more, there's gazillions of failures in the architectures' build logs. Regards, Rene
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 with Bus error like on > > mipsel? That doesn't sound too good for basic quality. > > > > There is a "smoketest" but it does just basic start. open, close stuff. > > Not even basic usage. > > That said, that is the smoketest on mipsel: The problem with a mail like this is that it really doesn't help anybody in understanding the problem. As porter, it will probably take a lot of time to get to the point where you can start looking at what the problem might be. It contains lots of information, but it's not clear what the problem is and what needs to be looked at. > (process:8700): dconf-CRITICAL **: 02:36:13.575: unable to create directory > '/run/user/2952/dconf': Permission denied. dconf will not work properly. > > (process:8708): dconf-CRITICAL **: 02:36:19.328: unable to create directory > '/run/user/2952/dconf': Permission denied. dconf will not work properly. > > (process:8815): dconf-CRITICAL **: 02:36:52.467: unable to create directory > '/run/user/2952/dconf': Permission denied. dconf will not work properly. Is this something the porter should look at? Is is relevant? > Fatal exception: Signal 11 It's a segfault, this should normally be trivial for you to debug, but is probably complicated for a porter to find out how to do things like attaching a debugger to the relevant process. > Stack: > /<>/instdir/program/libuno_sal.so.3(+0x49b18)[0x77d69b18] > /<>/instdir/program/libuno_sal.so.3(+0x49d48)[0x77d69d48] > /usr/lib/jvm/java-17-openjdk-mipsel/lib/server/libjvm.so(+0x537b8c)[0x62417b8c] Is this some openjdk problem, not a problem in libreoffice problem? > ./smoketest/smoketest.cxx:187:(anonymous namespace)::Test::test > assertion failed > - Expression: connection_.isStillAlive() So the (TCP?) connection is not alive? Why not? That doesn't seem to be platform specific. Is that a problem in the test suite, and not libreoffice itself? > unknown:0:(anonymous namespace)::Test::test > tearDown() failed > - An uncaught exception of type com.sun.star.lang.DisposedException > - Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048 > > (anonymous namespace)::Test::test finished in: 76764ms > smoketest.cxx:187:Assertion > Test name: (anonymous namespace)::Test::test > assertion failed > - Expression: connection_.isStillAlive() > > ##Failure Location unknown## : Error > Test name: (anonymous namespace)::Test::test > tearDown() failed > - An uncaught exception of type com.sun.star.lang.DisposedException And then the test suite crashes because it can't actually deal with the previous the assertion failure, and the segfault above is not relevant at all? The most likely thing is that this is not a platform specific issue, but a either a general issue that just shows up on some platforms for whatever reason, or some problem in an other piece of software that libreoffice is using that does have a pratform specific issue. Kurt
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 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 is a "smoketest" but it does just basic start. open, close stuff. >>> Not even basic usage. >> >> That said, that is the smoketest on mipsel: >> ... > > Assuming the smoketest currently also fails on riscv64, 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) > >> Regards, >> >> Rene > > cu > Adrian >
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 with Bus error like on > > mipsel? That doesn't sound too good for basic quality. > > > > There is a "smoketest" but it does just basic start. open, close stuff. > > Not even basic usage. > > That said, that is the smoketest on mipsel: >... Assuming the smoketest currently also fails on riscv64, 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) > Regards, > > Rene cu Adrian
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 real data. There are no false > > positives. > > I'd personally assume this isn't UB since upstream builds with UBsan for > testing (admittedly not on mipsel, though). But once can investigate here... Yeah, there's a caveat: you have to have complete self tests. If the project lacks complete self tests, then you may not uncover the bug. You can run the program in production with a sanitizer build. It may uncover cases that were lacking in the test cases. And it's unfortunate some arches lack Asan and UBsan support. They are such powerful tools. Sometimes you can tease-out the UB on a different arch. Sometimes you can't. Jeff
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 is a "smoketest" but it does just basic start. open, close stuff.
Not even basic usage.
That said, that is the smoketest on mipsel:
[build CUT] smoketest
S=/<> && I=$S/instdir && W=$S/workdir && mkdir -p
$W/CppunitTest/ && rm -fr $W/CppunitTest/smoketest.test.user && cp -r
$W/unittest $W/CppunitTest/smoketest.test.user &&rm -fr
$W/CppunitTest/smoketest.test.core && mkdir
$W/CppunitTest/smoketest.test.core && cd
$W/CppunitTest/smoketest.test.core && ( MAX_CONCURRENCY=4
MOZILLA_CERTIFICATE_FOLDER=dbm:
SAL_DISABLE_SYNCHRONOUS_PRINTER_DETECTION=1 SAL_USE_VCLPLUGIN=svp
LIBO_LANG=C
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program":$W/UnpackedTarball/cppunit/src/cppunit/.libs
$W/LinkTarget/Executable/cppunittester
$W/LinkTarget/CppunitTest/libtest_smoketest.so --headless
"-env:BRAND_BASE_DIR=file://$S/instdir" "-env:BRAND_SHARE_SUBDIR=share"
"-env:BRAND_SHARE_RESOURCE_SUBDIR=program/resource"
"-env:UserInstallation=file://$W/CppunitTest/smoketest.test.user"
"-env:UNO_TYPES=file://$I/program/types.rdb
file://$I/program/types/offapi.rdb"
"-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb"
-env:URE_BIN_DIR=file://$I/program
-env:URE_INTERNAL_LIB_DIR=file://$I/program
-env:LO_LIB_DIR=file://$I/program
-env:LO_JAVA_DIR=file://$I/program/classes --protector
$W/LinkTarget/Library/unoexceptionprotector.so unoexceptionprotector
--protector $W/LinkTarget/Library/unobootstrapprotector.so
unobootstrapprotector -env:arg-soffice=path:$I/program/soffice
-env:arg-user=$W/CustomTarget/smoketest
-env:arg-env=LD_LIBRARY_PATH"${LD_LIBRARY_PATH+=$LD_LIBRARY_PATH}"
-env:arg-testarg.smoketest.doc=$W/Zip/smoketestdoc.sxw
"-env:CPPUNITTESTTARGET=$W/CppunitTest/smoketest.test" ) 2>&1
[_RUN_] (anonymous namespace)::Test::test
(process:8700): dconf-CRITICAL **: 02:36:13.575: unable to create
directory '/run/user/2952/dconf': Permission denied. dconf will not
work properly.
(process:8708): dconf-CRITICAL **: 02:36:19.328: unable to create
directory '/run/user/2952/dconf': Permission denied. dconf will not
work properly.
(process:8815): dconf-CRITICAL **: 02:36:52.467: unable to create
directory '/run/user/2952/dconf': Permission denied. dconf will not
work properly.
Fatal exception: Signal 11
Stack:
/<>/instdir/program/libuno_sal.so.3(+0x49b18)[0x77d69b18]
/<>/instdir/program/libuno_sal.so.3(+0x49d48)[0x77d69d48]
/usr/lib/jvm/java-17-openjdk-mipsel/lib/server/libjvm.so(+0x537b8c)[0x62417b8c]
./smoketest/smoketest.cxx:187:(anonymous namespace)::Test::test
assertion failed
- Expression: connection_.isStillAlive()
unknown:0:(anonymous namespace)::Test::test
tearDown() failed
- An uncaught exception of type com.sun.star.lang.DisposedException
- Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048
(anonymous namespace)::Test::test finished in: 76764ms
smoketest.cxx:187:Assertion
Test name: (anonymous namespace)::Test::test
assertion failed
- Expression: connection_.isStillAlive()
##Failure Location unknown## : Error
Test name: (anonymous namespace)::Test::test
tearDown() failed
- An uncaught exception of type com.sun.star.lang.DisposedException
- Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048
Failures !!!
Run: 1 Failure total: 2 Failures: 1 Errors: 1
make[3]: *** [/<>/solenv/gbuild/CppunitTest.mk:121:
/<>/workdir/CppunitTest/smoketest.test] Error 1
Regards,
Rene
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 this isn't UB since upstream builds with UBsan for testing (admittedly not on mipsel, though). But once can investigate here... Regards, Rene
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 fixing them if I > report them. > > 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 is a "smoketest" but it does just basic start. open, close stuff. Not > even basic usage. Let's be realistic regarding the available options, because the one you want is not available. You want every !a*64 architecture to have a porter spending time on fixing libreoffice. And thinking this through, since regressions in new upstream versions are expected to be frequent you want new upstream versions of libreoffice blocked from testing migration by any regression on one architecture until a porter for this architecture has fixed the regression. A new architecture like riscv64 might have enough porters for fixing issues once or for some limited duration. That's it. For each architecture you have the options: 1. declare libreoffice good enough on this architecture, or 2. don't build libreoffice on this architecture There is no third option that architectures will provide porters fixing your package all the time. There are several other packages of comparable complexity, size and testsuite (e.g. mozjs* or rustc). For a successful build they are using either just a smoketest, or a maximum number of tolerable testsuite failures. > Regards, > > Rene cu Adrian
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 porterboxes > >> ... > > You are the only one who could realistically debug many of these. > > > > E.g. on armel it says: > >Fatal exception: Signal 6 > >Stack: > >/<>/instdir/program/libuno_sal.so.3(+0x3c2e4)[0xb6ec32e4] > >/<>/instdir/program/libuno_sal.so.3(+0x3c534)[0xb6ec3534] > > > > /lib/arm-linux-gnueabi/libc.so.6(__default_rt_sa_restorer+0x0)[0xb6ad58f0] > >/lib/arm-linux-gnueabi/libc.so.6(+0x7f47c)[0xb6b1e47c] > >/lib/arm-linux-gnueabi/libc.so.6(gsignal+0x14)[0xb6ad4360] > >Aborted (core dumped) > > > > Fixing something like this would involve generating a backtrace, > > and then you are likely the only person in Debian who could tell > > what is actually going on there. > > Not really. > > > There are likely also build or debug tricks you know that a porter would > > not know. > > True, I can help with those if needed. > > (As I already pointed out for zelenka, though it's basically setting > some variables in rules) > > > Debugging something like this is only feasible with reasonable effort if > > a porter who knows the port with its caveats debugs it together with a > > package maintainer who knows the internals of the package. > > I didn't say I was not helping, I said I am of no help if it comes to > actually fix it if it involves architecture knowledge. > > [...] > > > 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 fixing them > if I report them. > > 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 is a "smoketest" but it does just basic start. open, close stuff. > Not even basic usage. Related, bus errors are usually due to unaligned data accesses. Programmers casting from one type to another when when they shouldn't, like: typedef unsigned char byte; ... byte buffer[32]; readBuffer(buffer); double d = *(double *)buffer; That is undefined behavior because a byte buffer is a byte buffer, and it is not a double. That can result in a bus error on some platforms. You may get lucky and the byte buffer may be aligned for double. Or it may not be. In contrast, this would be Ok because the byte buffer is really a double object: typedef unsigned char byte; ... double d; byte* buffer = (bytes*) readBuffer(buffer); double dd = *(double *)buffer; 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. You don't need to be a porter to build and run with sanitizers. However, you do need an arch-specific machine. Or possibly a Debian chroot. Jeff
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: Signal 6 Stack: /<>/instdir/program/libuno_sal.so.3(+0x3c2e4)[0xb6ec32e4] /<>/instdir/program/libuno_sal.so.3(+0x3c534)[0xb6ec3534] /lib/arm-linux-gnueabi/libc.so.6(__default_rt_sa_restorer+0x0)[0xb6ad58f0] /lib/arm-linux-gnueabi/libc.so.6(+0x7f47c)[0xb6b1e47c] /lib/arm-linux-gnueabi/libc.so.6(gsignal+0x14)[0xb6ad4360] Aborted (core dumped) Fixing something like this would involve generating a backtrace, and then you are likely the only person in Debian who could tell what is actually going on there. There are likely also build or debug tricks you know that a porter would not know. Debugging something like this is only feasible with reasonable effort if a porter who knows the port with its caveats debugs it together with a package maintainer who knows the internals of the package. On Mon, Jun 19, 2023 at 12:04:45AM +0200, Kurt Roeckx wrote: >... > Do you think Debian doesn't have any developers/porters anymore? >... For porters that's actually close to being true. There were times when porter numbers for a release architecture were numbers like 6 or 9. No release architecture in bookworm had more than 2 porters. No porters were required on amd64, the number of distinct people who are listed as porter for one or more of the 8 other bookworm release architecture is 5 DDs and 2 non-DDs. On Sun, Jun 18, 2023 at 09:31:05AM +0200, 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 other down below and it's actually a > new architecture anyway. > > 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. > > Right now, the only architectures where the test actually work (ignoring the > occassional breakage on arm64 which is fixed upstream since they do > aarch64 flatpak builds) is amd64 and arm64. > > With various different 32-bit, endian and whatever else breakage > ppopping up the other architectures constantly were moved in the set > where the testsuite was run but the results were ignored. For s390x, > where the macros tests hangs it even was in the set where the tests even > were not ran, since a hang then also ends up in > "E: Build killed with signal TERM after 150 minutes of inactivity". > > This was sweeping under the carpet for sure, but this was needed due to > it being a release architecture :( >... For such a complex package I would expect 32bit breakage in every release if upstream no longer tests on 32bit. The pragmatic option would be to run only a smoketest for build success on architectures not tested by upstream. cu Adrian
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. E.g. on armel it says: Fatal exception: Signal 6 Stack: /<>/instdir/program/libuno_sal.so.3(+0x3c2e4)[0xb6ec32e4] /<>/instdir/program/libuno_sal.so.3(+0x3c534)[0xb6ec3534] /lib/arm-linux-gnueabi/libc.so.6(__default_rt_sa_restorer+0x0)[0xb6ad58f0] /lib/arm-linux-gnueabi/libc.so.6(+0x7f47c)[0xb6b1e47c] /lib/arm-linux-gnueabi/libc.so.6(gsignal+0x14)[0xb6ad4360] Aborted (core dumped) Fixing something like this would involve generating a backtrace, and then you are likely the only person in Debian who could tell what is actually going on there. Not really. There are likely also build or debug tricks you know that a porter would not know. True, I can help with those if needed. (As I already pointed out for zelenka, though it's basically setting some variables in rules) Debugging something like this is only feasible with reasonable effort if a porter who knows the port with its caveats debugs it together with a package maintainer who knows the internals of the package. I didn't say I was not helping, I said I am of no help if it comes to actually fix it if it involves architecture knowledge. [...] 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 fixing them if I report them. 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 is a "smoketest" but it does just basic start. open, close stuff. Not even basic usage. Regards, Rene
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 damage it had done to the project, >>> https://archive.org/details/copyleftconf2020-allison >> >> Can we please talk about the actual issue at and - that is not the license. > >The issue is the number of developers engaging with this package have declined >to the point problems have gone unnoticed and unfixed for a long time. That may be a general problem not specific to Libreoffice, or any one particular project. As software grows to accomodate more features, it reaches a size where it is "good enough" for users that they no longer feel a need to invest time anymore as their needs are already satisfied, while at the same time, it has become so large for others to not want to touch it anymore. Chromium sucks to touch. On the other hand, the Linux kernel has evermore developers each round, and Linux distros have more packages than ever before. So not all seems to be bad? Modularization seems key, and that may just be what separates projects.
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 said in my other reply, even if it was GPLv3 it wouldn't be > relevant at all. > > LibreOffice is not GPLv3 though and never was. I paid close attention to the project's launch back in the day. Back when LibreOffice forked away Oratroll's acquisition of Sun in 2010, they used (L)GPLv3 to prevent OpenOffice from merging their changes. Then OpenOffice got unloaded on apache.org after the fact, and it all got weirdly political. Then Google bought Writely and did google docs which could edit and save a word file which scooped up most of the userbase, and LibreOffice decided it should also run in a web browser... https://lwn.net/Articles/637830/ I know they regretted their GPLv3 stance early on, and were talking about NEW code being in a different license: https://lwn.net/Articles/498898/ But last I'd heard, while Apache's version had audited to relicense LibreOffice had not yet done a full audit: https://lwn.net/Articles/927096/ *shrug* I acknowledge I'm out of date here. If you say they're not v3 anymore, good for them. Seems I'm not the only one who hadn't heard about it, though. The last couple cubicle farms I consulted at still had LibreOffice on their "not allowed" lists, but the most recent of those was 2021 so that's old news. I only spoke up on the perception you were advocating for the removal of architectures I care about. Glad to hear that's not the case. Back to lurking... Rob
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 move and the damage it had done to the project, >>> https://archive.org/details/copyleftconf2020-allison >> >> Can we please talk about the actual issue at and - that is not the license. > >The issue is the number of developers engaging with this package have declined >to the point problems have gone unnoticed and unfixed for a long time. > >>> How long has the problem you're treating as a crisis been brewing? >> >> Far too long, as I said it was swept under I have a hard time understanding what you're trying to say. Do you think Debian doesn't have any developers/porters anymore? Or maybe that they're not actually using it for a desktop, and so the package isn't actually useful to anybody? Kurt
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, >> https://archive.org/details/copyleftconf2020-allison > > Can we please talk about the actual issue at and - that is not the license. The issue is the number of developers engaging with this package have declined to the point problems have gone unnoticed and unfixed for a long time. >> How long has the problem you're treating as a crisis been brewing? > > Far too long, as I said it was swept under the carpet for too long. Because the developers went away. Rob
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 generally about Debian. I might have written architectures, but from the context it should have been clear. Anyway, I corrected it. Of course I mean "getting those architectures removed from unstable" *for libreoffice*. here. Besides that it would also have been clear from actually reading the IRC log which incidentially also says "17:24 < elbrus> if I were you, I'd make them fatal everywhere and ask for removal from architectures where reasonable tests fail 17:25 < elbrus> extreme case you only ship on amd64 and arm64" (libreoffice) *removal from architectures* This is the same GPLv3 package that Red Hat just dropped support for? As I said in my other reply, even if it was GPLv3 it wouldn't be relevant at all. LibreOffice is not GPLv3 though and never was. How long has the problem you're treating as a crisis been brewing? Basically ever since people ported, the tests back then pass and then new tests broke and noone seriously cared until me as not-porter needed to sweep it under the carpet eo get it "ready" for release (because it otherwise was supposed to be removed). Or since people added a new arch in LibreOffice but didn't dare of finishing it so that even the important tests pass. Even if it works now, who says that with ignored tests something fundamental breaks (like python thingies in riscv64, which is a integral part of many LO things). Or some basic functionality? Causing a RC bug which is unfixable for me. Replying with something completely unrelated doesn't help here. No idea why you bring up GPLv3 or RH stopping support for it (which is bad for this case, though, since at least they did fix some tests on s390x etc., but we actually do have porters, too) here on a mail which just aims at porting LibreOffice / making it actually pass its tests to improve quality. Regards, Rene
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/ Indeed. When gcc switched to GPLv3 llvm appeared. When Samba switched to GPLv3 Apple wrote their own and Linux grew the ksmbd in-kernel server. 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, https://archive.org/details/copyleftconf2020-allison Can we please talk about the actual issue at and - that is not the license. That is the tests being broken on anything except amd64 and arm64. How long has the problem you're treating as a crisis been brewing? Far too long, as I said it was swept under the carpet for too long. Regards, Rene
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 release team... >>> You want Debian to drop support for all architectures except amd64 and >>> arm64 >>> because a single package doesn't pass its testsuite on the other >>> architectures? >> >> If the "porters" of those architectures don't care about the tests, yes, >> this would be the ultimate result. >> >> And as the release team agrees with me... > > Well, actually I was too tired still. But the tone from my initial mail > was quite clear. I know you WANT to misread that and I fell into that trap No, that's how I read it too. You said getting the _architectures_ removed, not getting libreoffice removed from those architectures. > 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? https://lwn.net/Articles/933525/ When gcc switched to GPLv3 llvm appeared. When Samba switched to GPLv3 Apple wrote their own and Linux grew the ksmbd in-kernel server. 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, https://archive.org/details/copyleftconf2020-allison How long has the problem you're treating as a crisis been brewing? Rob
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 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? >> >> I (obviously) wrongly assumed that this was the magic address which >> duplicates to every port. >> >> Must have misremembered. > > It still does - I got this copy via the debian-arm list... > > -- > Steve McIntyre, Cambridge, UK.st...@einval.com > "This dress doesn't reverse." -- Alden Spiess > Same for me, I received it through the Debian-ppc list -someone
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 problems making them stay into "testsuite ran but >> > results ignored" set. >> Why did you send this mail exclusively to debian-ports then? > >I (obviously) wrongly assumed that this was the magic address which >duplicates to every port. > >Must have misremembered. It still does - I got this copy via the debian-arm list... -- Steve McIntyre, Cambridge, UK.st...@einval.com "This dress doesn't reverse." -- Alden Spiess
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 support for all architectures except amd64 and arm64 because a single package doesn't pass its testsuite on the other architectures? If the "porters" of those architectures don't care about the tests, yes, this would be the ultimate result. And as the release team agrees with me... Well, actually I was too tired still. But the tone from my initial mail was quite clear. I know you WANT to misread that and I fell into that trap Of course I mean "getting those architectures removed from unstable" *for libreoffice*. (which again should be obvious), not removing those architectures from unstable alltogether. Regards, Rene
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 you send this mail exclusively to debian-ports then? I (obviously) wrongly assumed that this was the magic address which duplicates to every port. Must have misremembered. Right now, the only architectures where the test actually work (ignoring the occassional breakage on arm64 which is fixed upstream since they do aarch64 flatpak builds) is amd64 and arm64. (...) 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 support for all architectures except amd64 and arm64 because a single package doesn't pass its testsuite on the other architectures? If the "porters" of those architectures don't care about the tests, yes, this would be the ultimate result. And as the release team agrees with me... Regards, Rene
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? > Right now, the only architectures where the test actually work (ignoring > the occassional breakage on arm64 which is fixed upstream since they do > aarch64 flatpak builds) is amd64 and arm64. > (...) > 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 support for all architectures except amd64 and arm64 because a single package doesn't pass its testsuite on the other architectures? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
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 build-depends on: > - python3-scipy:x32 > python3-scipy depends on missing: > - python3:x32 (< 3.11) > (...) > Can something be done about this? I just built and uploaded numpy for x32 manually, I will do that for ia64 later, as the porterbox is currently offline (should be back up shortly). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
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 rebuilds, there were 373 packages (dd-list in the wiki page) found not to build with link time optimizations for various reasons. These range from easily fixable issues in symbols files to some upstream issues. The idea is to fix as many of these as possible, and then change the packaging for the others to just turn off LTO in the package build. In one of my packages, turning on LTO did not fail the build, but exposed a dormant static initialization bug, as LTO apparently messes with the initialization order [1]. I'd expect more bugs of this kind to come up once LTO is enabled by default. Cheers Timo [1] https://github.com/isl-org/Open3D/issues/4747 -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
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, and twice the registers still matters. -- Len Sorensen
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. > > -- hendrik >
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 application. Encryption and decryption > requiring the simulation of very larger integers shall be faster > when being based on 64bit integers. However these are rather > special purposes. > CPU and memory intense applications like the SAT-solver I am > developing on the other hand will be faster on i386 since a > memory reference/ pointer only requires 4 byte instead of 8 > byte. Smaller size will yield less memory access cycles and more > cache hits and that can make an application considerably faster. > It is the cache that is effectively more important than the > register layout. Some SAT-solvers like f.i. the DNNF-c2d are > only available for Linux/i386, not for amd64. > Concerning general purpose applications normal integers keep > to be 32bit even on amd64. Note the sizeof(int). This is also > for the rationale described above. x86_32 programs can even be > smaller on disk and in memory. I personally don´t think that > there is much reason to use amd64 with 2GB ram or less, except > for bigint calculations. > Note however that with a 64bit kernel you can execute programs > in a 64bit and 32bit chroot while this is impossible with a > 32bit kernel. This is a reason why many people boot with a 64bit > kernel but use a 32bit installation. As for certain CPU and > memory intense programs you can run them as i386 binary even on > an x86_64 root given that i386 system libararies are installed > which is possible with dpkg --add-architecture i386. > 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. -- hendrik
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 integers shall be faster when being based on 64bit integers. However these are rather special purposes. CPU and memory intense applications like the SAT-solver I am developing on the other hand will be faster on i386 since a memory reference/ pointer only requires 4 byte instead of 8 byte. Smaller size will yield less memory access cycles and more cache hits and that can make an application considerably faster. It is the cache that is effectively more important than the register layout. Some SAT-solvers like f.i. the DNNF-c2d are only available for Linux/i386, not for amd64. Concerning general purpose applications normal integers keep to be 32bit even on amd64. Note the sizeof(int). This is also for the rationale described above. x86_32 programs can even be smaller on disk and in memory. I personally don´t think that there is much reason to use amd64 with 2GB ram or less, except for bigint calculations. Note however that with a 64bit kernel you can execute programs in a 64bit and 32bit chroot while this is impossible with a 32bit kernel. This is a reason why many people boot with a 64bit kernel but use a 32bit installation. As for certain CPU and memory intense programs you can run them as i386 binary even on an x86_64 root given that i386 system libararies are installed which is possible with dpkg --add-architecture i386.
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 instructions for fpu rather than x87? 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
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 Sorensen
Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA 5113-1] firefox-esr security update)
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? Am Do., 14. Apr. 2022 um 10:38 Uhr schrieb Paul Wise : > On Tue, 2022-04-12 at 05:59 +0200, Friedhelm Waitzmann wrote: > > > And if it is indeed possible, how can I switch from i386 to > > amd64? Can this be done with the apt tools? Then during the > > migrating some packages will be from amd64 already while others > > will be still i386. How does that go right? > > If your hardware supports it, you can either reinstall from scratch or > cross-grade an existing install from i386 to amd64, either using the > crossgrader tool or more manual methods of doing the same thing. > > https://packages.debian.org/crossgrader > https://wiki.debian.org/CrossGrading > > -- > bye, > pabs > > https://wiki.debian.org/PaulWise >
Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA 5113-1] firefox-esr security update)
On 14.04.22 10:37, Paul Wise wrote: On Tue, 2022-04-12 at 05:59 +0200, Friedhelm Waitzmann wrote: And if it is indeed possible, how can I switch from i386 to amd64? Can this be done with the apt tools? Then during the migrating some packages will be from amd64 already while others will be still i386. How does that go right? If your hardware supports it, you can either reinstall from scratch or cross-grade an existing install from i386 to amd64, either using the crossgrader tool or more manual methods of doing the same thing. https://packages.debian.org/crossgrader https://wiki.debian.org/CrossGrading If I had to do it, I would just upgrade to Debian 11. It is most easy to do and you do not need things like a crossgrader tool. Though the procedure seems somewhat difficult to me, it is interesting to know that something like crossgrading exists and where you find documentation about it.
Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA 5113-1] firefox-esr security update)
On Tue, 2022-04-12 at 05:59 +0200, Friedhelm Waitzmann wrote: > And if it is indeed possible, how can I switch from i386 to > amd64? Can this be done with the apt tools? Then during the > migrating some packages will be from amd64 already while others > will be still i386. How does that go right? If your hardware supports it, you can either reinstall from scratch or cross-grade an existing install from i386 to amd64, either using the crossgrader tool or more manual methods of doing the same thing. https://packages.debian.org/crossgrader https://wiki.debian.org/CrossGrading -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA 5113-1] firefox-esr security update)
On Wed, Apr 13, 2022 at 1:22 PM Marianne Bayoy wrote: > > Unsubscribe https://www.debian.org/MailingLists/unsubscribe
Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA 5113-1] firefox-esr security update)
Unsubscribe Le mar. 12 avr. 2022, 12 h 27 a.m., Friedhelm Waitzmann < fach220408.fw...@xoxy.net> a écrit : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Dear Moritz! > > Moritz Mühlenhoff: > >Friedhelm Waitzmann wrote: > >>> For the oldstable distribution (buster), these problems have > >>> been fixed in version 91.8.0esr-1~deb10u1. > >> > >> Where can I get this from for buster and architecture i386? > >> < > http://security.debian.org/debian-security/dists/buster/updates/main/binary-i386/Packages.xz > > > >> does not have it. > > >The Firefox ESR91 series triggers an internal compiler error > >with the GCC version included in Debian 10, so there's no build > >available currently. > > Thank you for defining this. > > > >There's one for Debian 11 (where GCC builds it correctly), > > > > In the near future I will migrate to Debian 11. > > > >but I'd instead suggest to switch to amd64 instead. > > > > You mean, that it is possible to run amd64 on my old hardware > > > 1# > > vendor_id : GenuineIntel > cpu family : 6 > model : 22 > model name : Intel(R) Celeron(R) CPU 440 @ 2.00GHz > stepping: 1 > microcode : 0x43 > cpu MHz : 1229.629 > cache size : 512 KB > > and > > 2# > > vendor_id : GenuineIntel > cpu family : 15 > model : 2 > model name : Intel(R) Pentium(R) 4 CPU 2.00GHz > stepping: 4 > cpu MHz : 1993.656 > cache size : 512 KB > > ? > > And if it is indeed possible, how can I switch from i386 to > amd64? Can this be done with the apt tools? Then during the > migrating some packages will be from amd64 already while others > will be still i386. How does that go right? > > > > I suggest, that further discussing should take place in > debian-amd64@lists.debian.org. > > > > Kind regards, > Friedhelm > > > My OpenPGP‐Key: > > - -BEGIN PGP PUBLIC KEY BLOCK- > > mQENBFoCvhgBCADnymmMgAzxsUqP9GPSK+QJATL4w/C8KS7ghUdu7TT4mdEfMfgI > BteRnqWJvLzlBFlQRBEXQphxfgtAdTAZDdAlcyXkcA19Sb0Z09/oQgPe4vp99Cnp > kq2GPOxSk6YQrfs4FF6p4lsQUz0TKONSztZGo4VSyT1G+LpsSxm7Q1YUzpO4j5fy > XfPMB/TdhpJbKlE4yVldwVdt4+Gc8oTeohVkZZtVx9bplmaVLaj35HrRTupj75IS > tooF5dTVLQVhQYKqDCd2DKiZiUuKt6K9ZtrpmjnWaWRayKmJdJ14R8/Q7VfSyXOx > fLb4DNDz4FNUPOvHdXYjhsTz1U6v1kaddMXdABEBAAG0E0ZyaWVkaGVsbSBXYWl0 > em1hbm6JAWAEEwEKAEoCGwECHgECF4ALCw0JCgwICwcEAwIIFQoJCAsDAgEFFgMC > AQACGQEFCQuP3SgWIQRGyPH+W3hgUPhyflPQtV81ksAM7QUCYbLp7wAKCRDQtV81 > ksAM7cr5B/wO1khGTl3dAh46DY2jxe3jTfPvicbQgZQVwOhhP2FPKIFC8dYVCEHk > oYQapW47YXufw/Qw71GILfMtZemiUJpHwa/thCPtP3clE53ZqsEdArHDX2ZYm3Ol > qDTxMuilQCDfGuatg6MVQ8SlUbhcGIGyr4O4cPeDe0kmUOQhp8wKTXkmhq3Yml5+ > 2XRu69TZUNsQh3TPi50hR+RB0YjI+KTBKYSanAYM44Bj6mti6+06UkRVMaFxLVzS > BAEyTf/SBaKkJq4cKe+gCzcc/Gg8jrxKVcQRPdUxOlvWUiYT5FYRaFuklgDW4B+g > 23FdO6RkE0Z+g/oLeAYSqj/JMfjv77bFtBlmYWNoMjIwNDA4LmZ3bnNwQHhveHku > bmV0iQFdBBMBCgBHFiEERsjx/lt4YFD4cn5T0LVfNZLADO0FAmJQFg8CGwEFCQuP > 3SgLCw0JCgwICwcEAwIIFQoJCAsDAgEFFgMCAQACHgECF4AACgkQ0LVfNZLADO2V > ygf9HQWjolhnGRNWG5845lh2uTrm/5q19+hKwnQHx7HApZia09kXp7QpxTCmSmnq > skWto08U/iT1sPqFTOojOZAM6e4zr7kz/VJksJx8lswUkTRyGXqGEQoQ7bZvd6XR > Yu0ZKfNNZhvjfPzzwyp+85lWWIaNA0cQyIa6BRzlNhgCbyLhksy4GDkzoBPxhNOp > mboohSVOnLjrUbQpfKCDJtAaNps95+4gv2t8JPtyFcZW9qKWFRIdJJvamc3lp4Il > JwzXRElB1htSHQb4SA2VN9M6ALdnfZXXT+H8UKKek+joE8Xm15FX83E5pmrE/8lp > imVg0s0BAUd0DxVj6zj4SI9yhrkBDQRaAsK/AQgAyBEE1hjgZ6F33GPSkfxsFqsN > L5lQrRTQtx5GKPt5UnIKK00TAevGoI8VDftuP6Fpp9kFJ+HSAiW3M+8S70H3UnbW > 8AFofSd28AUvnnhP4ATwRcVm35+HYUge4lKiy5bEvDS9bALJqlW9sHBUF+gebrmh > 0CgvD0sQSUE4PLAuHFUJG8/fezReXGB2MSVAbu8NXHdlJ6vPr5ERlg7A0JFR9Knx > s8PoI/1hd73mwGld9/Xo3xByDbJ7Uejjt3HpNZf9eOq3XPp02dpKsOQEB2QxxPHI > TcBH8IBZY78BJHq9UD4g3fD904oIvs38BzvX/WAMO9W0k1ZLfF1zyR0+QXQweQAR > AQABiQJEBBgBAgAPAhsCBQJcRWq9BQkU+H0OASnAXSAEGQECAAYFAloCwr8ACgkQ > gEIvCiHZTet1zwf/TUmPpwnBgoA6AXILI5R/NvZit30mbExa6byBOK9vEbGS8pSu > L/GN5tzTmyJoGbLNc24h8w6FwcoxE0xJSUJKp7nO95NWD/kO5n8alJZN9ph8I2yt > Cl3dhzZKw8+j+WBwTrKLdDP5lfarI0gz6+N1UtFH4U+tUCq56DQqu46xyTS5ASeM > iO/8Ykej9LiObZv9QYwnKkhM8y+Dw9dkPfIsqt47uE4j4czpJ4qv8236oV/luR44 > 8cCud5G7ZGxBj6DSnitZM2lbq5yTlIZ3EEvu/I9dE/vsPaWQmGeo6S03FJ8+S6Xn > eP8mgYWl9YGJTjDvUg3FU9fXfHzCuFtZ/1YZvAkQ0LVfNZLADO2zEggAi3myJcVA > yiftlZSkTrId9LNeQtXCw7tkJcuaGIC/FWJQhVofcp2CuEAm26w9xRN39Tp7pi2r > fta/xykj0iYNjmqgi7MWK6pZOY/LCTEOMfYiWX4LCJ89f51y2TTmWwgfWXxFVe8y > lyRMC1N2CXEd5xsEKA1ZI5vF3ikjVkMBAtLGiSxcyBi8YbcDFG4/fTBNpeEvXZ6n > CusDDYCArwFiQi4mRtDbZXBZIBVE+jwYlzw0bz3EeqkPFMJ/pvuWeQ5R9LSuVYhh > aVieqoLXmK6uwQLoJOFx67KX+BoEPpkVa/FmDhfpguQrKz5/Eq1Lhy8P28EAhLSG > Ar1XuxedRos/pLkBDQRaAsFpAQgAm4sZiVbFI6YpR3yDFpe7qOkkWmlk+7MT8cAa > j5Ltm+mXqf7ZHDNeX9mzMNBZeoUBCztp0n/N0Iu5T7MmEJV/rrJa0N8ezjY9kDTX > xUmLRmXTM/AM7Jg6dsIOf/lrd2TAagUkf/nYS9Sxx7/MvWESis3uYw8aqpuXjS0t > FgaG3umvTfvgI2SamuZTkdt9KmoqKCFcf5qjNk7PeY0REVYUp0/mfyPDo7s33yOm > P0x9wy6zeZ4OKAsSETvARj8WafUT7vikVuZEtfiLolT741y2VtvyBICooLsVZ6Pf > MMle4newVhbZeJAjUTdxoE4T+B1vMICsbNw2/zsYtM/9KKvWpwARAQABiQElBBgB >
Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA 5113-1] firefox-esr security update)
unsubscribe On Tue, Apr 12, 2022 at 12:27 AM Friedhelm Waitzmann < fach220408.fw...@xoxy.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Dear Moritz! > > Moritz Mühlenhoff: > >Friedhelm Waitzmann wrote: > >>> For the oldstable distribution (buster), these problems have > >>> been fixed in version 91.8.0esr-1~deb10u1. > >> > >> Where can I get this from for buster and architecture i386? > >> < > http://security.debian.org/debian-security/dists/buster/updates/main/binary-i386/Packages.xz > > > >> does not have it. > > >The Firefox ESR91 series triggers an internal compiler error > >with the GCC version included in Debian 10, so there's no build > >available currently. > > Thank you for defining this. > > > >There's one for Debian 11 (where GCC builds it correctly), > > > > In the near future I will migrate to Debian 11. > > > >but I'd instead suggest to switch to amd64 instead. > > > > You mean, that it is possible to run amd64 on my old hardware > > > 1# > > vendor_id : GenuineIntel > cpu family : 6 > model : 22 > model name : Intel(R) Celeron(R) CPU 440 @ 2.00GHz > stepping: 1 > microcode : 0x43 > cpu MHz : 1229.629 > cache size : 512 KB > > and > > 2# > > vendor_id : GenuineIntel > cpu family : 15 > model : 2 > model name : Intel(R) Pentium(R) 4 CPU 2.00GHz > stepping: 4 > cpu MHz : 1993.656 > cache size : 512 KB > > ? > > And if it is indeed possible, how can I switch from i386 to > amd64? Can this be done with the apt tools? Then during the > migrating some packages will be from amd64 already while others > will be still i386. How does that go right? > > > > I suggest, that further discussing should take place in > debian-amd64@lists.debian.org. > > > > Kind regards, > Friedhelm > > > My OpenPGP‐Key: > > - -BEGIN PGP PUBLIC KEY BLOCK- > > mQENBFoCvhgBCADnymmMgAzxsUqP9GPSK+QJATL4w/C8KS7ghUdu7TT4mdEfMfgI > BteRnqWJvLzlBFlQRBEXQphxfgtAdTAZDdAlcyXkcA19Sb0Z09/oQgPe4vp99Cnp > kq2GPOxSk6YQrfs4FF6p4lsQUz0TKONSztZGo4VSyT1G+LpsSxm7Q1YUzpO4j5fy > XfPMB/TdhpJbKlE4yVldwVdt4+Gc8oTeohVkZZtVx9bplmaVLaj35HrRTupj75IS > tooF5dTVLQVhQYKqDCd2DKiZiUuKt6K9ZtrpmjnWaWRayKmJdJ14R8/Q7VfSyXOx > fLb4DNDz4FNUPOvHdXYjhsTz1U6v1kaddMXdABEBAAG0E0ZyaWVkaGVsbSBXYWl0 > em1hbm6JAWAEEwEKAEoCGwECHgECF4ALCw0JCgwICwcEAwIIFQoJCAsDAgEFFgMC > AQACGQEFCQuP3SgWIQRGyPH+W3hgUPhyflPQtV81ksAM7QUCYbLp7wAKCRDQtV81 > ksAM7cr5B/wO1khGTl3dAh46DY2jxe3jTfPvicbQgZQVwOhhP2FPKIFC8dYVCEHk > oYQapW47YXufw/Qw71GILfMtZemiUJpHwa/thCPtP3clE53ZqsEdArHDX2ZYm3Ol > qDTxMuilQCDfGuatg6MVQ8SlUbhcGIGyr4O4cPeDe0kmUOQhp8wKTXkmhq3Yml5+ > 2XRu69TZUNsQh3TPi50hR+RB0YjI+KTBKYSanAYM44Bj6mti6+06UkRVMaFxLVzS > BAEyTf/SBaKkJq4cKe+gCzcc/Gg8jrxKVcQRPdUxOlvWUiYT5FYRaFuklgDW4B+g > 23FdO6RkE0Z+g/oLeAYSqj/JMfjv77bFtBlmYWNoMjIwNDA4LmZ3bnNwQHhveHku > bmV0iQFdBBMBCgBHFiEERsjx/lt4YFD4cn5T0LVfNZLADO0FAmJQFg8CGwEFCQuP > 3SgLCw0JCgwICwcEAwIIFQoJCAsDAgEFFgMCAQACHgECF4AACgkQ0LVfNZLADO2V > ygf9HQWjolhnGRNWG5845lh2uTrm/5q19+hKwnQHx7HApZia09kXp7QpxTCmSmnq > skWto08U/iT1sPqFTOojOZAM6e4zr7kz/VJksJx8lswUkTRyGXqGEQoQ7bZvd6XR > Yu0ZKfNNZhvjfPzzwyp+85lWWIaNA0cQyIa6BRzlNhgCbyLhksy4GDkzoBPxhNOp > mboohSVOnLjrUbQpfKCDJtAaNps95+4gv2t8JPtyFcZW9qKWFRIdJJvamc3lp4Il > JwzXRElB1htSHQb4SA2VN9M6ALdnfZXXT+H8UKKek+joE8Xm15FX83E5pmrE/8lp > imVg0s0BAUd0DxVj6zj4SI9yhrkBDQRaAsK/AQgAyBEE1hjgZ6F33GPSkfxsFqsN > L5lQrRTQtx5GKPt5UnIKK00TAevGoI8VDftuP6Fpp9kFJ+HSAiW3M+8S70H3UnbW > 8AFofSd28AUvnnhP4ATwRcVm35+HYUge4lKiy5bEvDS9bALJqlW9sHBUF+gebrmh > 0CgvD0sQSUE4PLAuHFUJG8/fezReXGB2MSVAbu8NXHdlJ6vPr5ERlg7A0JFR9Knx > s8PoI/1hd73mwGld9/Xo3xByDbJ7Uejjt3HpNZf9eOq3XPp02dpKsOQEB2QxxPHI > TcBH8IBZY78BJHq9UD4g3fD904oIvs38BzvX/WAMO9W0k1ZLfF1zyR0+QXQweQAR > AQABiQJEBBgBAgAPAhsCBQJcRWq9BQkU+H0OASnAXSAEGQECAAYFAloCwr8ACgkQ > gEIvCiHZTet1zwf/TUmPpwnBgoA6AXILI5R/NvZit30mbExa6byBOK9vEbGS8pSu > L/GN5tzTmyJoGbLNc24h8w6FwcoxE0xJSUJKp7nO95NWD/kO5n8alJZN9ph8I2yt > Cl3dhzZKw8+j+WBwTrKLdDP5lfarI0gz6+N1UtFH4U+tUCq56DQqu46xyTS5ASeM > iO/8Ykej9LiObZv9QYwnKkhM8y+Dw9dkPfIsqt47uE4j4czpJ4qv8236oV/luR44 > 8cCud5G7ZGxBj6DSnitZM2lbq5yTlIZ3EEvu/I9dE/vsPaWQmGeo6S03FJ8+S6Xn > eP8mgYWl9YGJTjDvUg3FU9fXfHzCuFtZ/1YZvAkQ0LVfNZLADO2zEggAi3myJcVA > yiftlZSkTrId9LNeQtXCw7tkJcuaGIC/FWJQhVofcp2CuEAm26w9xRN39Tp7pi2r > fta/xykj0iYNjmqgi7MWK6pZOY/LCTEOMfYiWX4LCJ89f51y2TTmWwgfWXxFVe8y > lyRMC1N2CXEd5xsEKA1ZI5vF3ikjVkMBAtLGiSxcyBi8YbcDFG4/fTBNpeEvXZ6n > CusDDYCArwFiQi4mRtDbZXBZIBVE+jwYlzw0bz3EeqkPFMJ/pvuWeQ5R9LSuVYhh > aVieqoLXmK6uwQLoJOFx67KX+BoEPpkVa/FmDhfpguQrKz5/Eq1Lhy8P28EAhLSG > Ar1XuxedRos/pLkBDQRaAsFpAQgAm4sZiVbFI6YpR3yDFpe7qOkkWmlk+7MT8cAa > j5Ltm+mXqf7ZHDNeX9mzMNBZeoUBCztp0n/N0Iu5T7MmEJV/rrJa0N8ezjY9kDTX > xUmLRmXTM/AM7Jg6dsIOf/lrd2TAagUkf/nYS9Sxx7/MvWESis3uYw8aqpuXjS0t > FgaG3umvTfvgI2SamuZTkdt9KmoqKCFcf5qjNk7PeY0REVYUp0/mfyPDo7s33yOm > P0x9wy6zeZ4OKAsSETvARj8WafUT7vikVuZEtfiLolT741y2VtvyBICooLsVZ6Pf > MMle4newVhbZeJAjUTdxoE4T+B1vMICsbNw2/zsYtM/9KKvWpwARAQABiQElBBgB > AgAPAhsMBQJcRWqNBQkU+H5mAAoJENC1XzWSwAztix8IAN+/SZI+fr6AkLuC0X+0 >
Re: KHADIJAH send 3 kisses
porn spam :( On Tue, Jan 18, 2022 at 12:27 PM pooran silve wrote: > website url https://vznsmsn.page.link/H3Ed > >
Re: Porter roll call for Debian Bookworm
Sandro Tosi 于2022年1月14日周五 13:54写道： > > YunQiang, > > On Tue, Jan 4, 2022 at 9:48 AM PICCA Frederic-emmanuel > wrote: > > > > > > > > In case #1000435 (matplotlib crashes on mips64el) is not already on > > > > your radar, would you please take a look? > > > > > > > > > > Thank you. I will work on it right now. > > > > Hello, I just added some information about this problem on this bug > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001168#72 > > > > it seems to me that this is something related to gcc-11. If I build > > matplotlib with gcc-10 there is no more crash. > > did you have a chance to look at it yet? there's quite a substantial > number of packages depending on matplotlib that cant migrate to OK. I will have a look at this now. > testing until this issue is fixed, so we'd greatly appreciate it if > you can investigate it soon. > > Thanks, > -- > Sandro "morph" Tosi > My website: http://sandrotosi.me/ > Me at Debian: http://wiki.debian.org/SandroTosi > Twitter: https://twitter.com/sandrotosi -- YunQiang Su
Re: Porter roll call for Debian Bookworm
YunQiang, On Tue, Jan 4, 2022 at 9:48 AM PICCA Frederic-emmanuel wrote: > > > > > In case #1000435 (matplotlib crashes on mips64el) is not already on > > > your radar, would you please take a look? > > > > > > > Thank you. I will work on it right now. > > Hello, I just added some information about this problem on this bug > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001168#72 > > it seems to me that this is something related to gcc-11. If I build > matplotlib with gcc-10 there is no more crash. did you have a chance to look at it yet? there's quite a substantial number of packages depending on matplotlib that cant migrate to testing until this issue is fixed, so we'd greatly appreciate it if you can investigate it soon. Thanks, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Porter roll call for Debian Bookworm
> > In case #1000435 (matplotlib crashes on mips64el) is not already on > > your radar, would you please take a look? > > > > Thank you. I will work on it right now. Hello, I just added some information about this problem on this bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001168#72 it seems to me that this is something related to gcc-11. If I build matplotlib with gcc-10 there is no more crash. I think that I reach my peter principe with this last effort :)) Cheers Frederic
Re: Porter roll call for Debian Bookworm
Hello, 2021-10-02 11:57 Graham Inggs: Hi We are doing a roll call for porters of all prospective release architectures. If you are an active porter behind one of these architectures [1] and intend to continue for the development cycle of Debian Bookworm (est. release mid-2023), please respond with a signed email containing the following before Saturday, January 1, 2022: * Which architectures are you committing to be an active porter for? * Please describe recent relevant porter contributions. * Are you running/using Debian testing or sid on said port(s)? * Are you testing/patching d-i for the port(s)? Please note that no response is required for amd64 because our toolchain maintainers are happy to support amd64 as-is. Feel free to use the following template as your reply: [...] I have been working on the riscv64 port since 2015 or so, even if the successful and definitive initial bootstrap only happened in 2018. Some people joined from the start and more people joined lately, but I have a keen interest in pushing this port further :) Thus, I am an active porter for riscv64 and I intend to continue for the development cycle of Debian Bookworm (est. release mid-2023). In the last year or two the contributions were a bit diminished for a variety of issues (especially in the realm of attending bugs and looking at specific issues of packages and submitting patches), and will continue to be this way for a while, but I hope to pick-up pace again during this development cycle. For riscv64, I plan to: - maintain buildds --- I have set-up or was involved in getting hardware and necessary resources and setting up most of the buildds of the architecture so far, and I plan to continue doing this in the foreseeable future - maintain/provide hardware for (or assist with) automated tests on ci.d.n, jenkins.d.n (etc.) --- I though about doing do this in the past, I think that it's a good idea to do this if new suitable hardware becomes available, but there's been scarcity until now. - run a Debian testing or unstable system on port that I use regularly - test (most|all) packages on this architecture --- not sure if saying (most|all) is realistic with the current size of the archive, but I hope to use regularly the most important packages by using them on real systems. The following I will try to do as more time becomes available, and paying more attention if this port is considered to be supported for bookworm and becoming a more official architecture (but other people with interest in riscv64 are also working on these areas): - fix toolchain issues - triage arch-specific bugs - fix arch-related bugs - triage d-i bugs - test d-i regularly - fix d-i bugs/issues I am a DD. -- Manuel A. Fernandez Montecelo signature.asc Description: PGP signature
Re: Porter roll call for Debian Bookworm
Graham Inggs 于2021年12月26日周日 21:58写道： > > Hi YunQiang Su > > On Sun, 26 Dec 2021 at 11:17, YunQiang Su wrote: > > > > For mipsel and mips64el, I > > - test most packages on this architecture > > - run a Debian testing or unstable system on port that I use regularly > > - fix toolchain issues > > - triage arch-specific bugs > > - fix arch-related bugs > > - triage d-i bugs > > - test d-i regularly > > - fix d-i bugs/issues > > - maintain buildds > > - maintain/provide hardware for (or assist with) automated tests on > > ci.d.n, > > jenkins.d.n (etc.) > > > > I am a DD. > > Thanks for your response! > > In case #1000435 (matplotlib crashes on mips64el) is not already on > your radar, would you please take a look? > Thank you. I will work on it right now. > Regards > Graham -- YunQiang Su
Re: Porter roll call for Debian Bookworm
On 2021-10-02, Graham Inggs wrote: > * Which architectures are you committing to be an active porter for? armhf, arm64 > * Please describe recent relevant porter contributions. Maintaining u-boot (bootloader used on many arm64 and armhf plaforms), arm-trusted-firmware (arm64 firmware), and occasional debian-installer, linux and initramfs-tools contributions for specific hardware. > I am an active porter for the following architectures and I intend to > continue for the development cycle of Debian Bookworm > (est. release mid-2023): > For armhf and arm64, I: > - test (most|all) packages on this architecture I maintain the armhf build machines for tests.reproducible-builds.org which currently runs package builds for the whole archive in sid, experimental, bookworm and bullseye chroots. The build machines are a mix of arm64 and armhf capable machines. > - run a Debian testing or unstable system on port that I use regularly I run mobian on arm64, which is currently bookworm based, working towards complete inclusion in debian. I may start using an arm64 laptop (pinebook pro) regularly, probably running bookworm. > - triage arch-specific bugs > - fix arch-related bugs > - triage d-i bugs > - test d-i regularly > - fix d-i bugs/issues Not systematically or regularly, but occasionally as the need arises. I am a DD. live well, vagrant signature.asc Description: PGP signature
Re: Porter roll call for Debian Bookworm
Hi YunQiang Su On Sun, 26 Dec 2021 at 11:17, YunQiang Su wrote: > > For mipsel and mips64el, I > - test most packages on this architecture > - run a Debian testing or unstable system on port that I use regularly > - fix toolchain issues > - triage arch-specific bugs > - fix arch-related bugs > - triage d-i bugs > - test d-i regularly > - fix d-i bugs/issues > - maintain buildds > - maintain/provide hardware for (or assist with) automated tests on ci.d.n, > jenkins.d.n (etc.) > > I am a DD. Thanks for your response! In case #1000435 (matplotlib crashes on mips64el) is not already on your radar, would you please take a look? Regards Graham
Re: Porter roll call for Debian Bookworm
For mipsel and mips64el, I - test most packages on this architecture - run a Debian testing or unstable system on port that I use regularly - fix toolchain issues - triage arch-specific bugs - fix arch-related bugs - triage d-i bugs - test d-i regularly - fix d-i bugs/issues - maintain buildds - maintain/provide hardware for (or assist with) automated tests on ci.d.n, jenkins.d.n (etc.) I am a DD. -- YunQiang Su
