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
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 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,
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 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 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 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 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, 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
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
[ 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
[ 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
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:
> >
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
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
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
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 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 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 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
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, 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
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 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
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 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: 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
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
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://
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
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 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
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 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 (
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 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
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
38 matches
Mail list logo