Version: 1.48.0-1
On Sat, Jan 13, 2024 at 03:49:17PM +0100, John Paul Adrian Glaubitz wrote:
> Control: tags -1 +patch
>
> On Fri, 2024-01-12 at 01:31 +0100, John Paul Adrian Glaubitz wrote:
> > This has now been tracked down to the libuv upstream change that introduced
> > support
> > for io_ur
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 (in
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 w
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
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: Si
On Thu, Nov 17, 2022 at 12:46:59PM +0100, John Paul Adrian Glaubitz wrote:
>...
> On 8/24/22 16:50, Frédéric Bonnard wrote:
> > powerpc-utils 1.3.9-1 fails to build atm with gcc-12.
> > I checked latest 1.3.10 and it's roughly the same.
> > I've opened an issue upstream.
>
> Interestingly, the err
On Tue, Jan 12, 2021 at 07:06:36PM +, Sudip Mukherjee wrote:
> I had been testing little more and I can see the same problem with
> other packages (syndie and stegosuite) which are using
> libswt-cairo-gtk-4-jni.
> So, all the three packages using libswt-cairo-gtk-4-jni triggers the
> segfault
Control: found -1 14.1-1
On Sat, Feb 13, 2021 at 02:53:58PM -0500, Andres Salomon wrote:
> Package: pulseaudio
> Version: 14.2-1
> Severity: serious
>
> Pulseaudio is failing to build on ppc64el. The version of pulseaudio in
> bullseye suffers from a pretty serious usability bug (see #980836)
> w
On Sun, Dec 06, 2020 at 01:03:17PM +0100, Matthias Klose wrote:
> On 12/1/20 5:02 AM, YunQiang Su wrote:
> > I am sorry for the later response.
> >Hi,
> >
> > I am an active porter for the following architectures and I intend
> > to continue this for the lifetime of the Bullseye release (
On Sun, Dec 06, 2020 at 01:03:17PM +0100, Matthias Klose wrote:
> On 12/1/20 5:02 AM, YunQiang Su wrote:
> > I am sorry for the later response.
> >Hi,
> >
> > I am an active porter for the following architectures and I intend
> > to continue this for the lifetime of the Bullseye release (
On Sat, May 30, 2020 at 02:24:16PM +0200, John Paul Adrian Glaubitz wrote:
> On 5/30/20 2:17 PM, Adrian Bunk wrote:
> > On Sat, May 30, 2020 at 01:58:02PM +0200, John Paul Adrian Glaubitz wrote:
> >> Hello!
> >>
> >> I was wondering whether there is
On Sat, May 30, 2020 at 01:58:02PM +0200, John Paul Adrian Glaubitz wrote:
> Hello!
>
> I was wondering whether there is a way around this large reduction in
> portability
> of KDE that occurred recently [1]?
>...
"recently" was 3 years ago, it is already this way in buster.
There is no way aro
uot; now, will take a while.
> >
> > Also for this one, only vtkplotter showed up.
>
> Did you check #951704 ? This affect python3 package using jemalloc.
I wrote earlier:
On Thu, May 07, 2020 at 01:16:15PM +0300, Adrian Bunk wrote:
>...
> #951704 looks like a similar but
On Thu, May 07, 2020 at 10:28:33AM +0200, Paul Gevers wrote:
>...
> On 07-05-2020 10:07, Adrian Bunk wrote:
> > This is a toolchain problem affecting many packages:
> > https://sourceware.org/bugzilla/show_bug.cgi?id=25051
>
> Do you have any rough estimate how many
On Fri, Mar 06, 2020 at 10:57:20AM +0100, Paul Gevers wrote:
>...
> However, it fails on arm64. I copied some of the output at the bottom of
> this report.
>
> Currently this regression is blocking the migration to testing [1]. Can
> you please investigate the situation and fix it?
>...
> https://
Package: gcc-6
Version: 6.3.0-8
Severity: serious
Control: affects -1 src:d-itg src:gtk-gnutella
https://buildd.debian.org/status/fetch.php?pkg=gtk-gnutella&arch=ppc64el&ver=1.1.8-2+b1&stamp=1488642493&raw=0
...
cc -c -I../.. -I.. -I../if/gen -pthread -I/usr/include/glib-2.0
-I/usr/lib/powerpc64
Source: yadifa
Version: 2.2.2-1
Severity: serious
https://buildd.debian.org/status/fetch.php?pkg=yadifa&arch=ppc64el&ver=2.2.2-1&stamp=1480164499
...
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I./include/dnscore -Wdate-time
-D_FORTIFY_SOURCE=2 -DNDEBUG -g -DDNSCORE_BUILD -D_THREAD_SAFE -D_REENT
On Thu, Nov 24, 2016 at 04:35:28PM +0100, Guillem Jover wrote:
>...
> On Thu, 2016-11-24 at 14:52:33 +, Thorsten Glaser wrote:
>...
> > Worse, they break *differently* on whether…
> >
> > >Precisely to make the behavior consistent on all architectures, dpkg
> > >enables PIE (conditionally if n
Source: numexpr
Version: 2.6.1-1
Severity: serious
https://buildd.debian.org/status/fetch.php?pkg=numexpr&arch=ppc64el&ver=2.6.1-1&stamp=1479607449
Lots of failures like:
...
==
FAIL: test_scalar0_int_aggressive_OPERATIONS_0309
On Tue, Nov 08, 2016 at 03:29:43PM -0500, Lennart Sorensen wrote:
>...
> -CFLAGS="${CFLAGS} -maltivec"
> +CFLAGS="${CFLAGS} -maltivec -fno-tree-vectorize"
>...
> And I realized the reason it was broken is that when using -maltivec and
> -O4 (which vlc uses), you get -ftree-vectorize automat
On Tue, Nov 01, 2016 at 01:08:03PM -0400, Lennart Sorensen wrote:
> On Tue, Nov 01, 2016 at 12:22:19PM -0400, Lennart Sorensen wrote:
> > On Tue, Nov 01, 2016 at 04:34:01PM +0200, Adrian Bunk wrote:
> > > This doesn't looks wrong to me.
> > >
> > > Not
On Tue, Nov 01, 2016 at 09:56:45AM -0400, Lennart Sorensen wrote:
> On Mon, Oct 31, 2016 at 11:13:00PM +0200, Adrian Bunk wrote:
> > This actually looks like a bug in upstream configure.ac to me:
> > VLC_ADD_CFLAGS([libvlccore],[${ac_cv_c_altivec}])
> > ALTIVEC_C
Control: retitle -1 vlc: configure.ac altivec setting broken
On Sun, Oct 30, 2016 at 11:40:50AM +, James Cowgill wrote:
>...
> On 30/10/16 00:16, Robert Ou wrote:
> > On Sat, Oct 29, 2016 at 3:43 PM, James Cowgill wrote:
> >> Control: tags -1 help
> >> Control: severity -1 grave
> >>
> >> Hi,
On Tue, Oct 25, 2016 at 08:08:29PM +0200, Erik Brangs wrote:
> Hi,
Hi Erik,
> Thanks for the hints, but those machines use 64-bit processors or 32-bit
> processors with SPE. I would need a 32-bit PPC with FPU, preferably with
> multiple cores. The projects that I'm interested in are related to
On Tue, Oct 25, 2016 at 04:50:43PM -0400, Lennart Sorensen wrote:
> On Tue, Oct 25, 2016 at 08:32:23PM +0200, Karoly Balogh (Charlie/SGR) wrote:
> > 64bit PPCs should be compatible with 32bit user space with most operating
> > systems. So unless you specifically target kernel space and MMU code, yo
On Fri, Oct 21, 2016 at 01:30:13PM -0400, Lennart Sorensen wrote:
> On Thu, Oct 20, 2016 at 11:18:39PM +0300, Adrian Bunk wrote:
> > Freescala/NXP is not even on the OpenPOWER member list - this is not the
> > old power.org
>
> Neither is AMCC as far as I can tell. Doe
On Thu, Oct 20, 2016 at 03:58:21PM -0400, Lennart Sorensen wrote:
> On Thu, Oct 20, 2016 at 03:54:43PM -0400, Lennart Sorensen wrote:
> > I think Freescala/NXP might disagree. Not sure if the e6500 core could
> > ruin ppc64el or not, but they certainly make a lot of powerpc chips.
>
> That should
On Wed, Oct 19, 2016 at 12:06:59PM +0200, Aurelien Jarno wrote:
> Hi,
Hi Aurelien,
>...
> To me it looks like they are really skilled for that job. Do you have
> actual facts showing the contrary?
Niels said that I shouldn't hesitate to let the release team know when
I believe there is an issue
pc64el port in general.
I am just saying that I see a risk for the ppc64el port in the
unlikely case that IBM makes a sudden move away from PowerPC
during the lifetime of stretch.
> On Mon, Oct 17, 2016 at 10:50:01PM +0300, Adrian Bunk wrote:
> > Is a DM enough, if the only DD gets kil
Disclaimer:
I am not a member of the release team, and I am only speaking for myself.
The architecture requalification status for stretch [1] lists the
ppc64el porter situation as green, but there are three reasons why
the situation doesn't look that good to me.
First, official status of the p
On Sun, Oct 09, 2016 at 11:13:21PM +0100, Adam D. Barratt wrote:
> On Sun, 2016-10-09 at 21:12 +0300, Adrian Bunk wrote:
> > [ adding debian-powerpc ]
> >
> > On Sun, Oct 09, 2016 at 06:54:44PM +0200, Moritz Mühlenhoff wrote:
> > > Niels Thykier schrieb:
> >
[ adding debian-powerpc ]
On Sun, Oct 09, 2016 at 06:54:44PM +0200, Moritz Mühlenhoff wrote:
> Niels Thykier schrieb:
> > If I am to support powerpc as a realease architecture for Stretch, I
> > need to know that there are *active* porters behind it committed to
> > keeping it in the working. Pe
[ fullquote adding -ports, for people not following -release or -devel ]
On Fri, Oct 07, 2016 at 06:35:07PM +0100, Jonathan Wiltshire wrote:
> Hi,
>
> I am arranging the final architecture qualification meeting for Stretch.
> This is primarily of interest to the release team, but I will also take
Package: wnpp
Severity: normal
The current maintainer of spu-tools, Arthur Loiret ,
is apparently not active anymore. Therefore, I orphan this package now.
Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.
If
On Sun, 28 Oct 2001, Tom Rini wrote:
> On Sun, Oct 28, 2001 at 08:16:50PM +0100, Adrian Bunk wrote:
> > All right. Is the special casing of the PReP machines obsolete, too or
> > should I keep it?
>
> Obsolete.
Thanks for this clarification, I'll remove the special han
On Sun, 28 Oct 2001, Daniel Jacobowitz wrote:
> > As far as I understand it clock from powerpc-utils is obsolete and you can
> > use hwclock on all machines (including PReP machines?). Does that mean you
> > will remove the clock program from powerpc-utils?
>
> No, I'm not going to; it's obsolete,
Hi Daniel, hi *,
after reading this discussion I have the following questions/remarks:
As far as I understand it clock from powerpc-utils is obsolete and you can
use hwclock on all machines (including PReP machines?). Does that mean you
will remove the clock program from powerpc-utils?
I don't h
On Tue, 23 Oct 2001, John Goerzen wrote:
> Package: util-linux
> Version: 2.11l-1
> Severity: important
>
> On many PowerPC machines (maybe all?), the program "clock" should be used
> from powerpc-utils. Using hwclock actually hangs the bootup procedure
> because it confuses the RTC driver in the
38 matches
Mail list logo