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: 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: openssl on hurd
On Sun, Jul 03, 2016 at 09:07:29PM +0200, Samuel Thibault wrote: > Hello, > > Kurt Roeckx, on Sat 02 Jul 2016 15:03:32 +0200, wrote: > > 1:error:25066067:DSO support routines:dlfcn_load:could not load the shared > > library:crypto/dso/dso_dlfcn.c:111:filename(.././engines/ossltest): > > .././engines/ossltest: cannot open shared object file: No such file or > > directory > > .././engines/ossltest doesn't exist, but ossltest.so does. That was too obvious. Kurt
openssl on hurd
Hi, OpenSSL in experimental has been failing to build on hurd with the following error: invalid engine "ossltest" 1:error:25066067:DSO support routines:dlfcn_load:could not load the shared library:crypto/dso/dso_dlfcn.c:111:filename(.././engines/ossltest): .././engines/ossltest: cannot open shared object file: No such file or directory 1:error:25070067:DSO support routines:DSO_load:could not load the shared library:crypto/dso/dso_lib.c:159: 1:error:260B6084:engine routines:dynamic_load:dso not found:crypto/engine/eng_dyn.c:414: 1:error:2606A074:engine routines:ENGINE_by_id:no such engine:crypto/engine/eng_list.c:327:id=ossltest 1:error:25066067:DSO support routines:dlfcn_load:could not load the shared library:crypto/dso/dso_dlfcn.c:111:filename(libossltest): libossltest: cannot open shared object file: No such file or directory 1:error:25070067:DSO support routines:DSO_load:could not load the shared library:crypto/dso/dso_lib.c:159: 1:error:260B6084:engine routines:dynamic_load:dso not found:crypto/engine/eng_dyn.c:414: Does anybody have an idea why the loading of an object might not work? Kurt
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-hurd-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: GCC-4.5 as the default for (at least some) architectures
On Tue, Apr 26, 2011 at 08:51:04PM +0200, Aurelien Jarno wrote: > On Tue, Apr 26, 2011 at 05:03:01PM +0200, Matthias Klose wrote: > > I'll make GCC 4.6 the > > default after the release of GCC 4.5.3, expected later this week, at > > least on amd64, armel, i386 and powerpc. > > If you do the switch, please also add mips and mipsel, that would avoid > you to have to complain in two weeks that these architectures have not > yet been switched. Is there a reason not to switch the remaining (release) arches (ia64, kfreebsd-*, sparc, s390)? Maybe hurd-i386 too? I assume you want to release with at least 4.6 on all arches as the default, so I see no point in waiting with switching if there are no known issues. Kurt -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110426192857.ga10...@roeckx.be
Re: Why don't you bother to apply patches to libtool??
On Sun, Apr 03, 2011 at 08:34:33PM +0200, Samuel Thibault wrote: > Svante Signell, le Sun 03 Apr 2011 20:20:57 +0200, a écrit : > > Now libtool has been updated to 2.4.-1. And still patches sent to the > > debian bug database on libtool 2.2.10 are not applied. Why, any specific > > reason? I'm sorry, I forgot about this bug report and #603971. I will try to apply them in the next version. Kurt -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110403185003.ga20...@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-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101114125148.ga26...@roeckx.be
Re: please drop openoffice.org from Packages-arch-specific
On Mon, May 03, 2010 at 09:15:01AM +0200, Petr Salinger wrote: > Hello, > > openoffice.org got support for GNU/kFreeBSD in 1:3.2.0-9. > The hurd is still not supported, but it shouldn't be too hard to > use kfreebsd patches (#578023) as hint what have to be adjusted > by hurd porters. > > So I suggest to drop current openoffice.org line > "%openoffice.org: !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386" > from Packages-arch-specific entirely. Done. Kurt -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100503194633.ga...@roeckx.be
Moving hurd back to buildd.debian.org
Hi, I think at some point in time there was a request to move hurd back to buildd.debian.org? What happened to this? Do you still want to move there? If you want this to happen, I will atleast need: - ssh keys - name of the buildds - email addresses of the buildds. (You might want to avoid mailing that to the list.) - uid's of the people that need wanna-build access - probably the ip addresses to get access to incoming I might be forgetting something. If you export your current database I can import it. Kurt -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
