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
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
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: Differences between the zani and zandonai build hosts?
On Fri, Dec 30, 2022 at 09:42:43AM +0200, Peter Pentchev wrote: > Hi, > > First of all, thanks a lot for all your work on porting Debian to > the IBM z* systems! > > Are there any differences in the hardware or software configuration of > the zandonai and zani Debian buildd hosts? There is a build-time test for > the libzstd package that failed the only time when a 1.5.0 version of > the package was built on the zani host, but it built successfully on > the zandonai one. There were no significant differences between > the four uploads of libzstd-1.5.0 - the changes that were made should have > prevented a full-on FTBFS if they were applicable to the compiler/libc > at all. > > https://buildd.debian.org/status/logs.php?pkg=libzstd=s390x According to: https://db.debian.org/machines.cgi?host=zandonai https://db.debian.org/machines.cgi?host=zani They both run on a z15. Kurt
Re: Porter roll call for Debian Stretch
On Wed, Aug 17, 2016 at 10:05:06PM +0200, ni...@thykier.net wrote: > * If we were to enable -fPIE/-pie by default in GCC-6, should that change >also apply to this port? [0] If -fPIE is the default will -fPIC override it? It will also default to tell the linker to use -pie, but then don't do it when you want to create a shared library? >From what I understand, depending on what the .o file is going to be used for you want different things: - shared library: -fPIC - executable: -fPIC or -fPIE both work, but prefer -fPIE - static library: Same as executables For static libraries we now have a policy to not use -fPIC, should that then get replaced by using -fPIE? Kurt
Re: Upgrading the minimum required s390x CPU to z10?
On Wed, Jun 01, 2016 at 05:51:56AM +0200, Kurt Roeckx wrote: > On Tue, May 31, 2016 at 07:23:00PM -0400, Stephen Powell wrote: > > On Tue, May 31, 2016, at 18:25, Aurelien Jarno wrote: > > > > > > That's indeed the right way to do it (and to fix the issue), but the > > > point is that developers using GCC defaulting to z10 or higher don't > > > realize they can't use the corresponding instructions, so that has to > > > be fixed later. Latest example is openssl. > > > > > > > Hmm. I see two possibilities here. > > > > (1) The source code package uses a GCC option that specifies that the > > compiled object code is to run on a z10 processor. The fix here is > > rather simple and straightforward: change the GCC option to specify a > > z800/z900, then re-build the package. The compiler will now generate > > object code that is compatible with all z/Architecture processors. > > > > (2) The so-called "C" source code bails out to assembly language in places, > > and some instructions are used which aren't supported on a z800/z900. > > (I've mainly seen this in s390-specific kernel modules.) In this case, the > > fix is more involved. You have to find the offending code, insert a > > facility check to make sure the instruction is supported first, then > > decide how to handle the case where it isn't. This is much more labor > > intensive. > > > > Which case are you talking about? (I must confess that I haven't looked > > at the source code for openssl.) > > OpenSSL has a lot of hand written assembler. It's actually the > linker that complained about it. That should obviously be the assembler, not linker. Kurt
Re: Upgrading the minimum required s390x CPU to z10?
On Tue, May 31, 2016 at 07:23:00PM -0400, Stephen Powell wrote: > On Tue, May 31, 2016, at 18:25, Aurelien Jarno wrote: > > > > That's indeed the right way to do it (and to fix the issue), but the > > point is that developers using GCC defaulting to z10 or higher don't > > realize they can't use the corresponding instructions, so that has to > > be fixed later. Latest example is openssl. > > > > Hmm. I see two possibilities here. > > (1) The source code package uses a GCC option that specifies that the > compiled object code is to run on a z10 processor. The fix here is > rather simple and straightforward: change the GCC option to specify a > z800/z900, then re-build the package. The compiler will now generate > object code that is compatible with all z/Architecture processors. > > (2) The so-called "C" source code bails out to assembly language in places, > and some instructions are used which aren't supported on a z800/z900. > (I've mainly seen this in s390-specific kernel modules.) In this case, the > fix is more involved. You have to find the offending code, insert a > facility check to make sure the instruction is supported first, then > decide how to handle the case where it isn't. This is much more labor > intensive. > > Which case are you talking about? (I must confess that I haven't looked > at the source code for openssl.) OpenSSL has a lot of hand written assembler. It's actually the linker that complained about it. On various arches we do detect on which CPU we're running, not sure we already do that, or need to, on s390x. Kurt
Re: vtk6_6.1.0+dfsg-4 on s390x
On Mon, Jun 09, 2014 at 01:01:28PM +0200, Anton Gladky wrote: Hi Kurt, thanks for information. Should I then put in BD something like: libhdf5-openmpi-dev [!s390x], libhdf5-mpich-dev [s390x]? Or you could do something like: libhdf5-openmpi-dev [!s390x] | libhdf5-mpich-dev, libhdf5-mpich-dev [s390x] | libhdf5-openmpi-dev Kurt -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140609110719.ga11...@roeckx.be
Re: DSA concerns for jessie architectures
On Sun, Jul 21, 2013 at 09:06:31PM +0200, Bernd Zeimetz wrote: On 06/22/2013 07:26 PM, Martin Zobel-Helas wrote: * sparc: no working nflog (mild concern); no stable kernels in stable (compiling clisp for instance crashes the kernel reliably on smetana). We need to run sparc with oldstable kernels to provide stable machines. That's not an option for long. I think all machines except stadler and sompek are US IIIi machines. The problem with US IIIi is, that sun never published the cpu specs - they would have done it if somebody would have paid for the lawyers to look trough them before publishing. US IIi support was implemented by a student working at SUN under NDA and US IV and later was published. So I think if dropping (official) support for US IIIi CPUs would keep the port alive, we should do that. Running Debian on the more recent machines makes more sense anyway imho. The older ones are nice, but they consume a lt of power. If you drop support for US II and IIIi, we basicly have 2 boxes left, of which one acts as sparc buildd and the other as sparc64 and sparc buildd. Those 2 boxes in their current state really can't keep up, specially since they're not stable at all when trying to use multiple cores. You would also be missing a porterbox. I thought the plan was to drop 32 bit support and move to sparc64? But that still doesn't seem to have moved to the Debian archive. Is there something holding back moving to sparc64? There is also Matthias Klose mail asking what to do with gcc. sparc is still on gcc-4.6 and I think he isn't willing to maintain that any longer. Kurt -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130808173254.ga25...@roeckx.be
Re: DSO linking changes for wheezy
On Sun, Nov 07, 2010 at 04:19:10PM +, Roger Leigh wrote: On Fri, Oct 29, 2010 at 03:43:57PM +0200, Matthias Klose wrote: For wheezy I'm planning to change the linking behaviour for DSOs (turning on --as-needed and --no-copy-dt-needed-entries. The rationale is summarized in http://wiki.debian.org/ToolChain/DSOLinking. I would like to know about issues with these changes on some of the Debian ports, and if we need to disable one of these changes on some port. While I understand the rationale for --no-copy-dt-needed-entries for preventing encapsulation violations via indirect linking, I don't agree with the use of --as-needed *at all*. If a library has been explicitly linked in, it shouldn't be removed. This is an issue for fixing in individual packages, not in the toolchain. I can understand on using it on a per-package basis, but not in the actual toolchain defaults. The compiler and linker *should not be second-guessing the user*. This can break perfectly legitimate code making use of ELF constructors and other features which won't be picked out just by looking at symbol usage. People have been claiming that constructors or init section are a possible problem. I have yet to see an example where it breaks. Kurt -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101114125148.ga26...@roeckx.be
