Control: tags -1 + pending
On Wed, 04 Sep 2024 at 18:51:11 +0100, Simon McVittie wrote:
> src:gtk4 uses GALLIUM_DRIVER=softpipe on mips*, powerpc and sparc* to work
> around #1010838. Mesa 24.2.x is no longer built with softpipe enabled
24.2.1-4 re-enables softpipe (#1080475) which
...@lists.debian.org
Usertags: mips64el
src:gtk4 uses GALLIUM_DRIVER=softpipe on mips*, powerpc and sparc* to work
around #1010838. Mesa 24.2.x is no longer built with softpipe enabled,
so this makes the softpipe driver fail to load and as a result makes (E)GL
initialization fail, breaking the test suite
002\002\005,�d",
> inputLen=)
> at rijndael.c:780
> 780 rijndael.c: No such file or directory.
> (gdb)"
>
> Has anyone else experienced this issue? Is there a missing depends?
SIGILL is probably due to in-core AES crypto instruction from POWER8
and above. It sound
uot; received signal SIGILL, Illegal instruction.
rijndael_encryptCBC (cx=0x53a8a80, output=0x53a88c0 "\005:�\230",
outputLen=, maxOutputLen=,
input=0x52cb860 "password-check\002\002\005,�d",
inputLen=)
at rijndael.c:780
780 rijndael.c: No such file or directory.
Hi Adrian,
John Paul Adrian Glaubitz wrote:
Correct, there is an issue with the brightness controls. It sometimes randomly
turns the screen off, even when turning it to maximum setting. Then when you
change the settings again randomly, the video comes back.
Still, this needs to be bisected.
O
Hello,
On Wed, 2024-01-24 at 16:15 +0100, Riccardo Mottola wrote:
> > I have reported the issue in the Freedesktop bug tracker for the radeon
> > driver [1].
>
> video signal of the internal LCD or external video? When does this happen
> I just updated my iBook G4 14" and it works. Boot messages
orted
[ 14.222774] radeon :00:10.0: [drm] bpp/depth value of 16/16 not supported
[ 14.222780] radeon :00:10.0: [drm] No compatible format found
I have reported the issue in the Freedesktop bug tracker for the radeon driver
[1].
video signal of the internal LCD or external video? When does
] bpp/depth value of 16/16 not supported
[ 14.222780] radeon :00:10.0: [drm] No compatible format found
I have reported the issue in the Freedesktop bug tracker for the radeon driver
[1].
Adrian
> [1] https://gitlab.freedesktop.org/drm/amd/-/issues/3120
--
.''`. John Pa
__ ((target ("sse4.2")))
template
int foo ()
{
// foo version for SSE4.2
return ...;
}
__attribute__ ((target ("avx2")))
template
int foo ()
{
// foo version for AVX2
return ...;
}
And there's no measu
On Sun, 2023-06-04 at 06:51 -0400, Jeffrey Walton wrote:
> Altivec detection on Linux is relatively easy nowadays using
> getauxval(). From
...
> instead of using a query via getauxval(), OpenSSL does a runtime probe
> by executing an Altivec instruction. If a SIGILL is encountered, then
> Altivec
On Sun, 2023-06-04 at 11:56 +0200, Lorenzo wrote:
> According to mplayer upstream [1] "AltiVec runtime detection never
> worked reliably" and "the way it was detected in libavcodec was an
> unacceptable hack".. that was in back in 2007, I'll check if upstream
> still consider runtime detection unf
ding a
> > > variant of mplayer without altivec, however I can't tell if such
> > > bug can still be triggered nowadays. The ppc port is gone right?
> > > Are cpus without altivec still usable on one of Debian's powerpc
> > > ports?
> >
>
such
> > bug can still be triggered nowadays. The ppc port is gone right?
> > Are cpus without altivec still usable on one of Debian's powerpc
> > ports?
>
> No, Debian for 32-bit PowerPC is still maintained as an unofficial
> port:
>
> > https://cdimage.debian.o
ivec still usable on one of Debian's powerpc ports?
No, Debian for 32-bit PowerPC is still maintained as an unofficial port:
> https://cdimage.debian.org/cdimage/ports/snapshots/2023-05-28/debian-12.0.0-powerpc-NETINST-1.iso
As for Altivec support in mplayer: Have you tried the latest vers
On Wed, 2022-08-31 at 08:39 -0400, Dennis Clarke wrote:
> I was surprised to see, even shocked, that the hfsplus package has
> nothing for manpages. Just blank place holders.
Please report this as a bug against the package itself:
https://www.debian.org/Bugs/Reporting
There are proper manual pa
I was surprised to see, even shocked, that the hfsplus package has
nothing for manpages. Just blank place holders.
enceladus#
enceladus# uname -a
Linux enceladus 5.19.2-genunix #1 SMP Sat Aug 20 19:45:53 GMT 2022 ppc64
GNU/Linux
enceladus# dpkg -L hfsplus | xargs ls -lad
drwxr-xr-x 18 root
Control: tags -1 + fixed-upstream patch
On Wed, 08 Jun 2022 at 12:53:42 +0100, Simon McVittie wrote:
> I think the solution to this might be upstream commit acbf56d7 (trying it
> now on the ppc64el porterbox).
That seems to have been successful. MR available here:
https://salsa.debian.org/gdb-tea
On Wed, 08 Jun 2022 at 12:24:45 +0100, Simon McVittie wrote:
> > make[4]: Entering directory '/<>/build/default/sim/ppc'
> > make[4]: *** No rule to make target 'info'. Stop.
I think the solution to this might be upstream commit acbf56d7 (trying it
now on t
the ppc64el build is missing:
> make[3]: Leaving directory '/<>/build/default/gnulib'
> Doing info in sim
> make[3]: Entering directory '/<>/build/default/sim'
> Making info in ppc
> make[4]: Entering directory '/<>/build/default/sim/ppc&#x
gt; firmware onto a PC X1950 PCIe card and this card may be more easily
> > available/cheaper.
> >
> > If the OPs machine is PCI-X there are more X1900 options but I've no
> > idea how well the Radeon cards work with Linux.
>
> Based on my experience with my G5,
On Mon, May 23, 2022 at 10:41:07AM -0700, Christian Calderon wrote:
> I wonder if new nvidia cards will work now that nvidia has released an open
> source driver…
My understanding is that what has been made available right now is
only for newer hardware. In the long term it may be of benefit for
>
> If the OPs machine is PCI-X there are more X1900 options but I've no
> idea how well the Radeon cards work with Linux.
Based on my experience with my G5, I was able to use a non-Apple
Raedon card and things worked fine. I did not need to flash ROMs or
jump through other hoops.
F
ard may be more easily
> available/cheaper.
>
> If the OPs machine is PCI-X there are more X1900 options but I've no
> idea how well the Radeon cards work with Linux.
>
> Thanks
>
> --
> Tony Jones
> SUSE Kernel Performance Team
>
#x27;ve also read that people have used a Windows PC to flash Mac
firmware onto a PC X1950 PCIe card and this card may be more easily
available/cheaper.
If the OPs machine is PCI-X there are more X1900 options but I've no
idea how well the Radeon cards work with Linux.
Thanks
--
Tony Jones
SUSE Kernel Performance Team
Thanks
No ATI Radeon available !
0 experience with Nouveau
On Fri, May 20, 2022 at 4:29 PM Ben Westover wrote:
> Hello,
>
> On 5/20/22 4:20 PM, Guido R. Rolón A. wrote:
> > Thanks, I'll check it out.
> >
> > On Fri, May 20, 2022 at 4:07 PM Jeffrey Walton >
gt; wrote:
> >
> > Hi all this is my first time here and my first time with an Apple
> Machine
> >
> > My setup is a
> > Apple PowerMac7,2 5.1.5f2 BootROM built on 09/21/04 at 11:58:53
> > 5.1.5 - Power Macintosh G5 (Omega, Jun
pple PowerMac7,2 5.1.5f2 BootROM built on 09/21/04 at 11:58:53
> > 5.1.5 - Power Macintosh G5 (Omega, June 2003)
> > Model No.: A1047 EMC No.: 1969
> > Serial NO: YM337XX
> > Ethernet ID: 000A9597FAE2
> > CPU 1.6GYHZ 970
> > RAM 4096MB 333
> > DISK 160G
On Fri, May 20, 2022 at 3:54 PM Guido R. Rolón A. wrote:
>
> Hi all this is my first time here and my first time with an Apple Machine
>
> My setup is a
> Apple PowerMac7,2 5.1.5f2 BootROM built on 09/21/04 at 11:58:53
> 5.1.5 - Power Macintosh G5 (Omega, June 2003)
> Mo
Hi all this is my first time here and my first time with an Apple Machine
My setup is a
Apple PowerMac7,2 5.1.5f2 BootROM built on 09/21/04 at 11:58:53
5.1.5 - Power Macintosh G5 (Omega, June 2003)
Model No.: A1047 EMC No.: 1969
Serial NO: YM337XX
Ethernet ID: 000A9597FAE2
CPU 1.6GYHZ 970
RAM
Hello Jeffrey!
On 4/12/22 02:04, Jeffrey Walton wrote:
> I am working on an old PowerMac G5 running Debian Sid. I am trying to
> install firmware-b43-installer. It is having some trouble. I'm not
> sure how to fix it. I'm going to report it and then ask some questions
> over at the kernel's b43 ma
On 10/18/2021 07:50 PM, Alex McKeever wrote:
> Essentially, my screen can be found (I have an iMac G3 in which I’ve ran Sid
> on)… however it can’t find any usable configurations, and manually generating
> an XOrg configuration (editing it to give certain options) doesn’t help. Is
> this an XOrg
Hello!
On 10/18/21 19:39, Alex McKeever wrote:
> Essentially, my screen can be found (I have an iMac G3 in which I’ve ran Sid
> on)…
> however it can’t find any usable configurations, and manually generating an
> XOrg
> configuration (editing it to give certain options) doesn’t help. Is this an
Essentially, my screen can be found (I have an iMac G3 in which I’ve ran Sid
on)… however it can’t find any usable configurations, and manually generating
an XOrg configuration (editing it to give certain options) doesn’t help. Is
this an XOrg, driver, or kernel issue?
I’d like to know as this
s/spl/build
> > > /bin/sh: 1: /usr/src/linux-headers-4.13.0-1-common/scripts/ld-version.sh:
> > > not found
> > > /bin/sh: 1: [: -ge: unexpected operator
> > > ld: cannot find arch/powerpc/lib/crtsavres.o: No such file or directory
> > [...]
> >
>
headers-4.13.0-1-powerpc64
> > EXTRA_CFLAGS=-Werror-implicit-function-declaration
> > M=/home/glaubitz/zfstests/spl/build
> > /bin/sh: 1: /usr/src/linux-headers-4.13.0-1-common/scripts/ld-version.sh:
> > not found
> > /bin/sh: 1: [: -ge: unexpected operator
>
On 2/1/21 8:47 PM, John Paul Adrian Glaubitz wrote:
> On 2/2/21 2:32 AM, Dennis Clarke wrote:
>> Bad news ... even the default installer fails still.
>>
>> See:
>>
>> https://beta.genunix.com/debian_boot/ppc64/debian_ppc64_partman_20210202012126.txt
>>
>> https://beta.genunix.com/debian_boot/ppc64/
*/
+ WriteMDB (driveInfo, mdbp);
+ /* MDB is now big-endian */
+
+ free(nodeBuffer);
+ free(mdbp);
+
+ return (0);
+}
+
/*
* make_hfsplus
*
@@ -384,6 +545,128 @@ make_hfsplus(const DriveInfo *driveInfo, hfsparams_t *defaults)
return (0);
}
+
+/*
+ * WriteMDB
+ *
+ * Writes the Ma
On 2/2/21 2:32 AM, Dennis Clarke wrote:
> Bad news ... even the default installer fails still.
>
> See:
>
> https://beta.genunix.com/debian_boot/ppc64/debian_ppc64_partman_20210202012126.txt
>
> https://beta.genunix.com/debian_boot/ppc64/debian_ppc64_syslog_20210202012030.txt
>
> So lets just c
to Debian unstable [3].
>
> Testing the powerpc image on my iBook G4 showed that partman is no longer
> hanging
> and the partioner starts up normally. I can therefore get back to fixing the
> bootloader
> installation for Apple PowerMac systems as I can finally test the images
>
Hi!
On 2/2/21 1:44 AM, Dennis Clarke wrote:
> This could be entirely due to me using the "expert mode" :
>
> https://beta.genunix.com/debian_boot/ppc64/debian_ppc64_syslog_20210202003700.txt
>
> I will re-try with the dummy trivial accept all defaults mode.
As I said, this is missing the GRUB f
to Debian unstable [3].
>
> Testing the powerpc image on my iBook G4 showed that partman is no longer
> hanging
> and the partioner starts up normally. I can therefore get back to fixing the
> bootloader
> installation for Apple PowerMac systems as I can finally test the images
>
to Debian unstable [3].
>
> Testing the powerpc image on my iBook G4 showed that partman is no longer
> hanging
> and the partioner starts up normally. I can therefore get back to fixing the
> bootloader
> installation for Apple PowerMac systems as I can finally test the images
>
Hello!
I have created fresh installation images for the Debian Ports architectures
today [1]
and one very important change is a new upstream version of parted that was just
[2]
released and uploaded to Debian unstable [3].
Testing the powerpc image on my iBook G4 showed that partman is no
IC -DPIC -o .libs/libpll_la-hardware.o
> > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time
> > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC
> > > -g -c random.c -fPIC -DPIC -o .libs/libpll_la-random.o
> > > libtool:
e
> > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC
> > -g -c random.c -fPIC -DPIC -o .libs/libpll_la-random.o
> > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time
> > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O
On 12/9/20 3:22 PM, Riccardo Mottola wrote:
> Also, good news, I updated today and again a 5.9 kernel was installed and
> updated,
> but it is 2020-11-27 and the keyboard works again!
> (Interestingly, the external apple keyboard still doesn't work).
Have you independently verified that the ext
Hi,
Stan Johnson wrote:
Adrian,
Yes, the 5.9.0 kernel works on my PB G4 12". The built-in keyboard is
detected as ADB. In a Google search, everything I was able to find
indicated that G4 PowerBooks use ADB for their built-in keyboards and
trackpads.
I can say that 5.7 kernels recognize the i
0] adb device [7]: 7 0x1F
> [3.362968] ADB keyboard at 2 has handler 0xC3
> [3.362996] Detected ADB keyboard, type ANSI.
> [3.363294] input: ADB keyboard as /devices/virtual/input/input0
> [3.363587] input: ADB Powerbook buttons as /devices/virtual/input/input1
There were
On 11/7/20 7:24 PM, Riccardo Mottola wrote:
> Anybody who knows :) But it appears to be USB.
> Do we have the same model of powerbook? You said it works for you.
I have an iBook G4 and some older Apple Powerbooks somewhere in my
basement.
> I also have an iBook G4 which I refrained from updateing
Hi,
John Paul Adrian Glaubitz wrote:
I just upgraded the kernel to 5.9.0 on my PowerBook G4 - no keyboard, I
cannot>even login.
I reverted to 7.0-2 and everything works as expected.
I do not have intermediate kernels, so I cannot tell when exactly things broke.
You can find more ker
Hi Adrian,
John Paul Adrian Glaubitz wrote:
On 11/7/20 3:33 PM, Riccardo Mottola wrote> Hi!
As somebody else asked, I booted, attached an USB keyboard and that one works.
Is the keyboard ADB or USB? I see in the dmesg usb related messages.
Whom are you asking here?
Anybody who knows :) But
On 11/7/20 3:33 PM, Riccardo Mottola wrote> Hi!
> As somebody else asked, I booted, attached an USB keyboard and that one works.
> Is the keyboard ADB or USB? I see in the dmesg usb related messages.
Whom are you asking here?
> Here two extracts of dmesg
> [4.291256] input: PMU as /devices/vi
we want
to debug
your problem.
Interesting. In my case it stops working at console level already, so no
Xorg.log
As somebody else asked, I booted, attached an USB keyboard and that one
works. Is the keyboard ADB or USB? I see in the dmesg usb related messages.
Linux Auryn 5.9.0-1-powerpc #1
Source: hfsprogs
Severity: normal
User: debian-powerpc@lists.debian.org
Usertags: powerpc ppc64
X-Debbugs-Cc: debian-powerpc@lists.debian.org
Hello!
The recently uploaded version 540.1.linux3-1 of hfsprogs no longer supports
creating
legacy HFS filesystems as the "-h" flag is
Hello!
On 10/27/20 9:06 PM, Riccardo Mottola wrote:
> I just upgraded the kernel to 5.9.0 on my PowerBook G4 - no keyboard, I cannot
> even login. I reverted to 7.0-2 and everything works as expected.
>
> Anyone else experiencing similar symptoms?
Just upgraded my iBook G4 wit
Hello!
On 10/27/20 9:06 PM, Riccardo Mottola wrote:
> I just upgraded the kernel to 5.9.0 on my PowerBook G4 - no keyboard, I
> cannot>even login.
> I reverted to 7.0-2 and everything works as expected.
>
> I do not have intermediate kernels, so I cannot tell when exactly thi
Hi,
I just upgraded the kernel to 5.9.0 on my PowerBook G4 - no keyboard, I
cannot even login. I reverted to 7.0-2 and everything works as expected.
I do not have intermediate kernels, so I cannot tell when exactly things
broke.
Anyone else experiencing similar symptoms?
Riccardo
On Mon, May 11, 2020 at 08:31:37AM +0200, Mathieu Malaterre wrote:
> On Sun, May 10, 2020 at 10:01 PM Paul Gevers wrote:
>...
> > On 10-05-2020 15:25, Paul Gevers wrote:
> > > I'm running another check on "cannot allocate memory in static TLS
> > > block" now, will take a while.
> >
> > Also for t
On Sun, May 10, 2020 at 10:01 PM Paul Gevers wrote:
>
> Hi Adrian,
>
> On 10-05-2020 15:25, Paul Gevers wrote:
> > I'm running another check on "cannot allocate memory in static TLS
> > block" now, will take a while.
>
> Also for this one, only vtkplotter showed up.
Did you check #951704 ? This a
Hi Adrian,
On 10-05-2020 15:25, Paul Gevers wrote:
> I'm running another check on "cannot allocate memory in static TLS
> block" now, will take a while.
Also for this one, only vtkplotter showed up.
Paul
signature.asc
Description: OpenPGP digital signature
Hi Adrian,
On 07-05-2020 12:16, Adrian Bunk wrote:
> On Thu, May 07, 2020 at 10:28:33AM +0200, Paul Gevers wrote:
>> If we can detect this failure
>> mode (and similar ones in the future) we can of course generate hints
>> based on this heuristics and have the failures ignored until the
>> toolcha
ckages are effected,
Anything loading a plugin that is directly or indirectly linked
with libgomp might or might not have this problem.
Python C extensions are the most frequent ones.
Heavy usage of Python code with C extensions tends to be in the more
scientific areas of the archive, I'd g
Dear Adrian,
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? Is there any way to predict
which packages are effected, or to detect which packages are eff
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 4/19/20 3:34 AM, Dennis Clarke wrote:>
> This is progress certainly :
>
> Apr 19 01:14:56 in-target: cannot copy
> `/usr/lib/grub/powerpc-ieee1275/gcry_rijndael.mod'
> to `/boot/grub/powerpc-ieee1275/gcry_rijndael.mod': No space left on device
This s
e:
128 128 128 hfs
$bootable{ }
method{ format }
format{ }
use_filesystem{ }
filesystem{ hfs }
mountpoint{ /boot/grub } .
I have no idea how well that works though. In particular, I haven't verified
yet whether we would still need anything from partman-newworld, most
On 19.04.20 10:21, John Paul Adrian Glaubitz wrote:
On 4/19/20 10:06 AM, John Paul Adrian Glaubitz wrote:
Although I'm really wondering if we just can't format and mount the
HFS partiton with partman without having to resort to the hfs bootstrap
script you created for debian-installer.
There
On 4/19/20 10:06 AM, John Paul Adrian Glaubitz wrote:
> Although I'm really wondering if we just can't format and mount the
> HFS partiton with partman without having to resort to the hfs bootstrap
> script you created for debian-installer.
>
> There is a udeb for hfs, so why shouldn't partman-aut
ge_requests/3
>
> I can rebase it (only later this day!), and hopefully there's no freeze
> in the way this time and we can merge it. ;-)
Please also close the corresponding bug report with this PR [1].
And a shorter changelog entry is enough like:
* Resize NewWorld partition to 1
an.org/installer-team/partman-auto/-/merge_requests/3
I can rebase it (only later this day!), and hopefully there's no freeze
in the way this time and we can merge it. ;-)
Cheers
Frank
Le dim. 19 avr. 2020 09:15, Mathieu Malaterre
a écrit :
>
>
> Le dim. 19 avr. 2020 08:45, John Paul Adrian Glaubitz <
> glaub...@physik.fu-berlin.de> a écrit :
>
>> On 4/19/20 8:39 AM, John Paul Adrian Glaubitz wrote:
>> > It might just be that we will have to increase the size of the HFS boot
>>
Le dim. 19 avr. 2020 08:45, John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> a écrit :
> On 4/19/20 8:39 AM, John Paul Adrian Glaubitz wrote:
> > It might just be that we will have to increase the size of the HFS boot
> > partition as GRUB requires for disk space these days.
> >
> > Not s
On 4/19/20 8:39 AM, John Paul Adrian Glaubitz wrote:
> It might just be that we will have to increase the size of the HFS boot
> partition as GRUB requires for disk space these days.
>
> Not sure though whether the partition is allowed to be larger by the
> firmware.
It seems that Gentoo recommen
On 4/19/20 3:34 AM, Dennis Clarke wrote:
> Apr 19 01:14:56 in-target: cannot copy
> `/usr/lib/grub/powerpc-ieee1275/gcry_rijndael.mod' to
> `/boot/grub/powerpc-ieee1275/gcry_rijndael.mod': No space left on device
>
> Looking at the hfs boot partition I see that it is
This is progress certainly :
Apr 19 01:14:56 in-target: cannot copy
`/usr/lib/grub/powerpc-ieee1275/gcry_rijndael.mod' to
`/boot/grub/powerpc-ieee1275/gcry_rijndael.mod': No space left on device
Looking at the hfs boot partition I see that it is 1MB in size and can
not be made
Hi!
On 3/11/20 9:10 PM, John Paul Adrian Glaubitz wrote:
> Thanks so much for already doing some investigative work on this. I actually
> wanted to look into this issue tonight but I was out for some hours today
> so I didn't have the time.
>
> I will try to perform the manual binNMU now after di
Hi Simon and Daniel!
On 3/11/20 8:25 PM, Simon McVittie wrote:
> On Wed, 11 Mar 2020 at 01:20:56 -0400, Daniel Kahn Gillmor wrote:
>> ModuleNotFoundError: No module named 'giscanner._giscanner'
>
> I think this is the python3.8 transition, combined with powerpc n
On Wed, 11 Mar 2020 at 01:20:56 -0400, Daniel Kahn Gillmor wrote:
> ModuleNotFoundError: No module named 'giscanner._giscanner'
I think this is the python3.8 transition, combined with powerpc not having
built gobject-introspection since #950267 was fixed.
The powerpc binar
Hi!
On 2/17/20 11:20 AM, Mathieu Malaterre wrote:
>>> I do not know who is responsible for those buildd machines ?
>>
>> James and I are responsible.
>
> Added:
>
> https://wiki.debian.org/Teams/DSA/non-DSA-HW?action=diff
Didn't know about this list. But it's missing the sparc64 machines, for ex
On Mon, Feb 17, 2020 at 9:47 AM John Paul Adrian Glaubitz
wrote:
>
> On 2/17/20 8:01 AM, Mathieu Malaterre wrote:
> > Could someone please have a look at openvdb build failure:
> >
> > https://buildd.debian.org/status/fetch.php?pkg=openvdb&arch=powerpc&ver=6.2.1-4&stamp=1581890957&raw=0
> >
> > I
On 2/17/20 8:01 AM, Mathieu Malaterre wrote:
> Could someone please have a look at openvdb build failure:
>
> https://buildd.debian.org/status/fetch.php?pkg=openvdb&arch=powerpc&ver=6.2.1-4&stamp=1581890957&raw=0
>
> I do not know who is responsible for those buildd machines ?
James and I are re
Dear powerpc team,
Could someone please have a look at openvdb build failure:
https://buildd.debian.org/status/fetch.php?pkg=openvdb&arch=powerpc&ver=6.2.1-4&stamp=1581890957&raw=0
I do not know who is responsible for those buildd machines ?
ref:
sbuild (Debian sbuild) 0.79.0 (05 February 2020
On 1/27/19 15:27, John Paul Adrian Glaubitz wrote:
On 1/27/19 1:04 PM, Frank Scheiner wrote:
@Adrian:
choose-mirror seems to have regressed in some way that it doesn't work anymore
even with
the correct mirror data.
But the corresponding file hasn't been touched since 2017 (see [1]). Why
did
On 1/27/19 1:04 PM, Frank Scheiner wrote:
> @Adrian:
>> choose-mirror seems to have regressed in some way that it doesn't work
>> anymore even with
>> the correct mirror data.
>
> But the corresponding file hasn't been touched since 2017 (see [1]). Why
> did it then work with older images (tested
could get
one from the network repo later on.
When it came time to choose a network repo, I had no success trying to tell it
that
mirror protocol: http
mirror : ftp.ports.debian.org
directory : /debian-ports/
@Rick:
Was (1) the information just not accepted or (2) was
>>> get one from the network repo later on.
>>>
>>> When it came time to choose a network repo, I had no success trying to tell
>>> it that
>>> mirror protocol: http
>>> mirror : ftp.ports.debian.org
>>> direct
Dear Adrian, Rick,
On 1/27/19 09:41, John Paul Adrian Glaubitz wrote:
On 1/27/19 4:16 AM, Rick Thomas wrote:
I decided to “continue without installing a kernel” in hopes that I could get
one from the network repo later on.
When it came time to choose a network repo, I had no success trying
On 1/27/19 4:16 AM, Rick Thomas wrote:
> So I dug out an old Mac mini G4 and attempted to install the “powerpc NETINST
> 20190124-23:05” CD on it.
>
> I accepted all the defaults (no “expert” mode) until it came up with the error
> “No installable kernel was found in
So I dug out an old Mac mini G4 and attempted to install the “powerpc NETINST
20190124-23:05” CD on it.
I accepted all the defaults (no “expert” mode) until it came up with the error
“No installable kernel was found in the defined APT sources”.
This occurred before it went looking for a
On 17/04/18 09:53 AM, Gabriel F. T. Gomes wrote:
Hi, Dennis.
On Tue, 17 Apr 2018, Dennis Clarke wrote:
nix$ cat pq.c
Where does this test case file come from?
nix$ grep "FLT128_DIG"
/usr/local/gcc7/lib/gcc/powerpc64-unknown-linux-gnu/7.3.0/include/float.h
#undef FLT128_DIG
#define FLT128_D
l standard and the other seems to be a glibc/gcc idea made up out
of thin air.
nix$ /usr/local/gcc7/bin/gcc -v -m64 -g -S -o pq.s pq.c
To get compiler support for the __float128 type, you also need to pass
-mfloat128 to the compiler.
Nope. There is no libquadmath nor a quadmath.h so nothing compiles in
any case.
dc
Hi, Dennis.
On Tue, 17 Apr 2018, Dennis Clarke wrote:
>nix$ cat pq.c
Where does this test case file come from?
>nix$ grep "FLT128_DIG"
>/usr/local/gcc7/lib/gcc/powerpc64-unknown-linux-gnu/7.3.0/include/float.h
>#undef FLT128_DIG
>#define FLT128_DIG __FLT128_DIG__
Notice that FLT1
l : 5
model name : Pentium II (Deschutes)
cpu MHz : 399.017
physical id : 0
cpu cores : 1
cpuid level : 2
i686$
* yes really *
i686$ gcc --version
gcc (Debian 7.3.0-14) 7.3.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the s
>
> Working on it :
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895452
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82686
https://gcc.gnu.org/ml/gcc-testresults/2018-04/msg01351.html
nix$ cat pq.c
#define _XOPEN_SOURCE 600
/* #include */
#include
#include
#include
#include
:~/pgm/C/ieee754$ grep "quad" ld.s | grep "0x"
.quad 0x400921fb54442d18,0x3ca1a62633145c06
dclarke@nix:~/pgm/C/ieee754$
So the default is the IBM type. No idea on the libquadmath yet.
I should have more info on this issue in another 16 or 20 hours.
Dennis
On 05/04/18 01:24 AM, John Paul Adrian Glaubitz wrote:
On 04/05/2018 12:01 AM, Dennis Clarke wrote:
So there we see "--disable-libquadmath --disable-libquadmath-support".
damn. :-(
Please file a bug report against Debian's gcc-5, gcc-6, gcc-7 and gcc-8
packages if you think that libquadmath
On Thu, 05 Apr 2018, Breno Leitao wrote:
>On 04/04/2018 07:01 PM, Dennis Clarke wrote:
>> So there we see "--disable-libquadmath --disable-libquadmath-support".
>
>This is also disabled on ppc64el and it should be enabled, so, put both ppc64
>and ppc64el on your bug, please.
>
>Since ppc64 suppo
On 04/04/2018 07:01 PM, Dennis Clarke wrote:
> So there we see "--disable-libquadmath --disable-libquadmath-support".
This is also disabled on ppc64el and it should be enabled, so, put both ppc64
and ppc64el on your bug, please.
Since ppc64 supports float128 I suppose this should be enabled by de
On 04/05/2018 12:01 AM, Dennis Clarke wrote:
> So there we see "--disable-libquadmath --disable-libquadmath-support".
>
> damn. :-(
Please file a bug report against Debian's gcc-5, gcc-6, gcc-7 and gcc-8
packages if you think that libquadmath must be enabled.
There are usually good reasons for
ppc64el? This package you listed should be used if you
are cross compiling, which does not seem to be the case.
Just pure ppc64 here with the 970MP processors.
However :
nix$ gcc -mcpu=970 -mno-altivec -g -m64 -std=iso9899:1999 -o s.o s.c
s.c:82:10: fatal error: quadmath.h: No such file or
1 - 100 of 1466 matches
Mail list logo
