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: [Pkg-openssl-devel] openssl sha1 not working with large files on stretch arm.
On Thu, Apr 11, 2019 at 04:51:50PM -0400, Jeffrey Walton wrote: > On Thu, Apr 11, 2019 at 11:24 AM peter green wrote: > > > > I got a report from a user about "openssl sha1 " not working for > > large files on raspbian stretch. > > > > I investigated the problem and found that when I tried to use "openssl sha1 > > " for a large (>2GB) file on Debian armhf stretch or raspbian > > stretch I get an error "Value too large for defined data type" > > > > > > What puzzles me is that it worked on raspbian buster, and also worked on > > debian stretch i386. According to the user who reported it to me it worked > > on Raspbian jessie. Anyone have any clues? I'm not finding anything obvious > > in the build logs or from a quick look at the source (it seems a couple of > > source files are built with large file support and the rest are not, but > > which files doesn't seem to have changed between stretch and buster). > > > > Likely coming from the shell and not OpenSSL; see > https://serverfault.com/q/735636/145545. > > Maybe coreutils changed something recently. Note that is just the string for strerror(EOVERFLOW). It could be that we use something like fstat() and get that errno. Kurt
Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)
On Wed, Dec 07, 2016 at 03:53:31PM +, Steve McIntyre wrote:
> AFAIK there are potentially still similar problems with ARMv5 - lack
> of architcture-defined barrier primitives for C++11 atomics to
> work. (I'd love to be corrected on this if people know better!) This
> is one of the key points here. More and more software is expecting to
> use these primitives, and a lack of them is a major problem. To
> demonstrate using gcc, you can see that lock-free atomics only started
> appearing in ARMv6 and were improved in ARMv7:
>
> $ for arch in 4 5 6 7-a; do echo ARMv${arch}; echo | g++ -march=armv${arch}
> -dM -E - | grep -i lock_free; done
> ARMv4
> #define __GCC_ATOMIC_CHAR_LOCK_FREE 1
> #define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 1
> #define __GCC_ATOMIC_BOOL_LOCK_FREE 1
> #define __GCC_ATOMIC_POINTER_LOCK_FREE 1
> #define __GCC_ATOMIC_INT_LOCK_FREE 1
> #define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 1
> #define __GCC_ATOMIC_LONG_LOCK_FREE 1
> #define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 1
> #define __GCC_ATOMIC_LLONG_LOCK_FREE 1
> #define __GCC_ATOMIC_SHORT_LOCK_FREE 1
> ARMv5
> #define __GCC_ATOMIC_CHAR_LOCK_FREE 1
> #define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 1
> #define __GCC_ATOMIC_BOOL_LOCK_FREE 1
> #define __GCC_ATOMIC_POINTER_LOCK_FREE 1
> #define __GCC_ATOMIC_INT_LOCK_FREE 1
> #define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 1
> #define __GCC_ATOMIC_LONG_LOCK_FREE 1
> #define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 1
> #define __GCC_ATOMIC_LLONG_LOCK_FREE 1
> #define __GCC_ATOMIC_SHORT_LOCK_FREE 1
> ARMv6
> #define __GCC_ATOMIC_CHAR_LOCK_FREE 1
> #define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 2
> #define __GCC_ATOMIC_BOOL_LOCK_FREE 1
> #define __GCC_ATOMIC_POINTER_LOCK_FREE 2
> #define __GCC_ATOMIC_INT_LOCK_FREE 2
> #define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 2
> #define __GCC_ATOMIC_LONG_LOCK_FREE 2
> #define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 1
> #define __GCC_ATOMIC_LLONG_LOCK_FREE 1
> #define __GCC_ATOMIC_SHORT_LOCK_FREE 1
> ARMv7-a
> #define __GCC_ATOMIC_CHAR_LOCK_FREE 2
> #define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 2
> #define __GCC_ATOMIC_BOOL_LOCK_FREE 2
> #define __GCC_ATOMIC_POINTER_LOCK_FREE 2
> #define __GCC_ATOMIC_INT_LOCK_FREE 2
> #define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 2
> #define __GCC_ATOMIC_LONG_LOCK_FREE 2
> #define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 2
> #define __GCC_ATOMIC_LLONG_LOCK_FREE 2
> #define __GCC_ATOMIC_SHORT_LOCK_FREE 2
What you're actually showing is that even for ARMv4 they are
sometimes lock free by using the kernel support.
> There are kernel helpers available to provide some atomic support, but
> they'll be very slow compared to real hardware support at this level.
I was under the impression that that's not the case:
https://lwn.net/Articles/314561/
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: 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-arm-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: DSA concerns for jessie architectures
On Sat, Jun 22, 2013 at 09:45:17PM +0200, Arnaud Patard wrote: > Kurt Roeckx writes: > > > On Sat, Jun 22, 2013 at 09:21:29PM +0200, Arnaud Patard wrote: > >> Martin Zobel-Helas writes: > >> > >> > * armel: no remote management (being worked on); no archive kernel for > >> > the machines we use. > >> > >> > >> afair buildd are: > >> marvell DB-78x00 -> should be supported by armel kernel flavour mx78xx0 > >> thecus n2100 -> should be supported by armel kernel flavour iop32x > >> > >> Please, can you explain what's exactily missing on kernel support > >> side ? > > > > There is no mx78xx0 kernel in the Debian archive as far as I can > > see. There is a linux-image-3.2.0-4-iop32x however. > > > > Sorry, I made a typo. It's mv78xx0: > http://packages.debian.org/wheezy/linux-image-3.2.0-4-mv78xx0 They currently seem to be running linux-image-2.6.32-ferroceon 2.6.32-1+buildd41 Did someone try the mv78xx0 kernel on those yet? Kurt -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130622195145.ga1...@roeckx.be
Re: DSA concerns for jessie architectures
On Sat, Jun 22, 2013 at 09:21:29PM +0200, Arnaud Patard wrote: > Martin Zobel-Helas writes: > > > * armel: no remote management (being worked on); no archive kernel for > > the machines we use. > > > afair buildd are: > marvell DB-78x00 -> should be supported by armel kernel flavour mx78xx0 > thecus n2100 -> should be supported by armel kernel flavour iop32x > > Please, can you explain what's exactily missing on kernel support > side ? There is no mx78xx0 kernel in the Debian archive as far as I can see. There is a linux-image-3.2.0-4-iop32x however. Kurt -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130622194113.ga...@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-arm-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: 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-arm-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 give back paraview on armel
On Tue, Aug 24, 2010 at 10:49:36AM +0200, Mathieu Malaterre wrote: > After discussion on the debian-arm mailing list. Martin Michlmayr > offered his help and tried to reproduce the FTBFS on armel, but he > could not (*) > So I would like to request a give back on paraview on armel > > gb paraview_3.8.1-1 . armel . This seems to have been done. Kurt -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100826184851.gf32...@roeckx.be
