Hi,
The LLVM Relocation is the cause of the failing tests ?
If yes it is safe to disable all tests or only problematic tests ?
,
| 1: LLVM ERROR: Relocation type not implemented yet!
| 1: QDEBUG : KCrashTest::testAutoRestart() ""
| 1: FAIL! : KCrashTest::testAutoRestart() Compared values ar
Usertags: armhf
https://buildd.debian.org/status/fetch.php?pkg=pcre2&arch=armhf&ver=10.44-2&stamp=1731586953&raw=0
shows lots of test failures that look like this:
> /((?i)b)/
> -Memory allocation - compiled block : 153
> +Memory allocation - compiled block : 129
&g
Hello Claudia,
On Thu, 2024-10-24 at 10:22 +0200, Claudia Neumann wrote:
> Test on iMac G5 with Radeon graphic card:
>
> DVD hängs with
> smp_core99_probe
> smp_core99_bringup_done
The underlying issue has already been localized and is handled here:
> https://bugs.
On Thu, 2024-10-24 at 11:01 +0200, Claudia Neumann wrote:
> Is there a newer ISO-image, that I could/should test.
No, because there haven't been any changes yet to address the bug.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Phys
Is there a newer ISO-image, that I could/should test.
CU
Claudia
Am Donnerstag, 24. Oktober 2024, 10:44:28 CEST schrieb John Paul Adrian
Glaubitz:
> Hello Claudia,
>
> On Thu, 2024-10-24 at 10:22 +0200, Claudia Neumann wrote:
> > Test on iMac G5 with Radeon graphic card:
>
Hi all,
Test on iMac G5 with Radeon graphic card:
DVD hängs with
smp_core99_probe
smp_core99_bringup_done
CU
Claudia
Am Sonntag, 20. Oktober 2024, 20:34:51 CEST schrieb John Paul Adrian Glaubitz:
> Hello,
>
> I created updated installation images for Debian Ports earlier this mont
Hi Cedar,
On Tue, 2024-10-22 at 20:09 -0500, Cedar Maxwell wrote:
> I'm not sure how to take a screenshot. I can take a photo later.
> I tried this image: https://cdimage.debian.org/cdimage/ports/12.0/powerpc/
> and it works.
This is a very old image and not what I meant.
When I talk about ol
Hello Adrian,
I'm not sure how to take a screenshot. I can take a photo later. I
tried this image: https://cdimage.debian.org/cdimage/ports/12.0/powerpc/
and it works.
On 10/21/24 01:34, John Paul Adrian Glaubitz wrote:
Hi Cedar,
On Sun, 2024-10-20 at 22:38 -0500, Cedar Maxwell wrote:
T
Pierre,
I actually tried to check for this kernel bug (OOPS) on the latest
vanilla kernel and I wasn't able to reproduce it (with my test
powerpc64 lpar), so let me manually update kernel on gcc203 to the
latest vanilla stable (something like v6.12-rc4), up until more recent
debian sid/uns
On Mon, 2024-10-21 at 21:52 +0200, John Paul Adrian Glaubitz wrote:
> On Mon, 2024-10-21 at 10:06 -0700, tal...@coyoterave.net wrote:
> > This image boots right away, no problems getting into a shell or the
> > installer.
>
> Thanks for the confirmation. I'll start bisecting the issue tomorrow the
Hi Talija,
On Mon, 2024-10-21 at 10:06 -0700, tal...@coyoterave.net wrote:
> This image boots right away, no problems getting into a shell or the
> installer.
Thanks for the confirmation. I'll start bisecting the issue tomorrow then.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian D
Hi Adrian,
This image boots right away, no problems getting into a shell or the
installer.
Thanks,
Talija
On Mon, Oct 21, 2024 at 06:10:29PM +0200, John Paul Adrian Glaubitz wrote:
> Hello,
>
> On Mon, 2024-10-21 at 17:22 +0200, John Paul Adrian Glaubitz wrote:
> > So, I bu
Hello,
On Mon, 2024-10-21 at 17:22 +0200, John Paul Adrian Glaubitz wrote:
> So, I built such a test image and that one boots fine for me on PowerKVM.
>
> Could you test whether this one boots on your PowerMac G5:
>
> > https://cdimage.debian.org/cdimage/ports/tests/ppc64-te
Hi Talija,
On Mon, 2024-10-21 at 16:52 +0200, John Paul Adrian Glaubitz wrote:
> I will build some test images with older kernel and GRUB versions in order
> to track down what particular change introduced the problem.
So, I built such a test image and that one boots fine for me on Po
n illegal
> address error that went by very fast as it just kept saying "Ok" over
> and over again.
Interesting, I have never seen that. Thanks for the data point.
> I can probably test on an actual 32 bit machine tonight if it will boot on
> an old world G3. I did ve
" over
and over again. I can probably test on an actual 32 bit machine
tonight if it will boot on an old world G3. I did verify the SHA sums
and the disks validated successfully when burned.
Thanks for all the work you put into this, it's much appreciated.
Talija
On Mon, Oct 21, 2024
Hi Cedar,
On Sun, 2024-10-20 at 22:38 -0500, Cedar Maxwell wrote:
> Thank you for creating new images. I tested
> debian-12.0.0-powerpc-NETINST-1.iso
> on my iBook G4 (PowerBook 6,7) and after selecting "Default install" at the
> GRUB
> menu, it loaded for a while then panicked and gave the fol
I'm currently using the last working ones from 2023-06-10.
I don't exactly have PPC32 hardware to test on... I could try one day.
On Sun, Oct 20, 2024 at 3:35 PM John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:
> Hello,
>
> I created updated installatio
Hi Talija,
On Sun, 2024-10-20 at 12:41 -0700, tal...@coyoterave.net wrote:
> After selecting expert mode:
>
> smp_core99_probe
> smp_core99_kick_cpu
> smp_core99_kick_cpu done
> smp_core99_kick_cpu
> smp_core99_kick_cpu done
> smp_core99_kick_cpu
> smp_core99_kick_cpu done
> smp_core99_bringup_do
eal hardware.
The reason I ask is because during my tests, the kernel got stuck directly
after booting from CD on QEMU while the installed system later on boots just
fine even with the latest kernel.
Images are found here:
https://cdimage.debian.org/cdimage/ports/snapshots/2024-10-10/
It w
Images are found here:
>
> > https://cdimage.debian.org/cdimage/ports/snapshots/2024-10-10/
>
> It would be good to test on as many different setups as possible to help
> localize
> the problem. I don't rule out that it might be a problem with the CD image
> creation
>
on boots just
fine even with the latest kernel.
Images are found here:
> https://cdimage.debian.org/cdimage/ports/snapshots/2024-10-10/
It would be good to test on as many different setups as possible to help
localize
the problem. I don't rule out that it might be a problem with the
Source: gtk4
Version: 4.16.1+ds-2
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: debian-powerpc@lists.debian.org
User: debian-powerpc@lists.debian.org
Usertags: powerpc
gtk4 passes most of its test suite on powerpc, but fails one test:
https://buildd.debian.org/status/fetch.php?pkg=gtk4&arch=pow
Package: ruby-mysql2
Version: 0.5.5-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: debian-powerpc@lists.debian.org
Hi,
https://buildd.debian.org/status/fetch.php?pkg=ruby-mysql2&arch=ppc64el&ver=0.5.5-2&stamp=1715331286
On 2024-02-14 at 11:35:09 +0100, Elena ``of Valhalla'' wrote:
> I've opened a bug to keep track of the issue, and I'm also going to
> report it on the upstream bugtracker, in case they would also have
> useful hints to find a solution.
and for the record, this is the upstream issue I've opened:
roper
> solution I'd be grateful.
One of the first things to do is, sign up for a GCC Compile Farm
account, <https://gcc.gnu.org/wiki/CompileFarm> and
<https://portal.cfarm.net/>. It is free for free and open source
software developers. See "Request an Account"
Hello
I'm the maintainer of camelot-py and when I enabled autopkgtests for the
package I've had a failure on ppc64el
https://ci.debian.net/packages/c/camelot-py/testing/ppc64el/42972030/
all other architectures pass, and I have no experience on ppc64el, so I
don't know what could be causing this
git bisect says commit df4aea76 "gdatetime: Add support for %E modifier
> > to g_date_time_format()" is the first bad commit, which would be consistent
> > with it being...
> >
> > > instead
> > > of segfaulting, the test failed with an assertion error invol
gdatetime: Add support for %E modifier
> to g_date_time_format()" is the first bad commit, which would be consistent
> with it being...
>
> > instead
> > of segfaulting, the test failed with an assertion error involving dates with
> > a Japanese era marker:
>
> .
a general problem with 64-bit BE, rather than specifically s390x.
git bisect says commit df4aea76 "gdatetime: Add support for %E modifier
to g_date_time_format()" is the first bad commit, which would be consistent
with it being...
> instead
> of segfaulting, the test failed with an ass
preparation for NEW processing) and it failed tests on s390x and on
the 64-bit, big-endian ports ppc64 and sparc64. I suspect this means
it's a general problem with 64-bit BE, rather than specifically s390x.
The 32-bit big-endian powerpc and hppa ports seem to pass this test fine,
although hppa h
Source: mariadb
Version: 1:10.11.5-1
Tags: upstream, confirmed, help, ftbfs
X-Debbugs-CC: debian-powerpc@lists.debian.org
User: debian-powerpc@lists.debian.org
Usertags: ppc64
Builds on ppc64 repeatedly failed on test main.mysql_upgrade with error message:
main.mysql_upgrade 'i
On Sun, 18 Jun 2023 at 15:58:10 +0200, John Paul Adrian Glaubitz wrote:
> TIL about debbisect. I can try to bisect this on big-endian PowerPC,
> I have root on multiple big-endian machines.
Were you able to do this?
Thanks,
smcv
s://bugzilla.mozilla.org/show_bug.cgi?id=1845669
>
> Adrian
>
Hi Adrian,
I was just able to test it using an upgraded Debian Sid ppc64:
It crashes because of:
Thread 1 "firefox-esr" received signal SIGSEGV, Segmentation fault.
i32_load8_u (addr=2014643200, mem=) at rlbox.wasm.c:146
1
Hello Carsten,
On 9/3/23 11:40 AM, Carsten Jacobi wrote:
> ... I'm reluctant
> on "just trying out the new version", I'm not sure whether I'll be able
> to get back to the still working version in case the new one doesn't
> run and just crashes.
> ...
You could create a backup before you install
Hello Adrian,
On 8/31/23 3:06 PM, John Paul Adrian Glaubitz wrote:
> Hi!
>
> Thanks to the efforts of Debian's Firefox maintainer, the Firefox package
> is building again on ppc64 (big-endian) the first time in a long period.
>
> However, we don't know whether Firefox actually works on 64-bit Bi
Hello,
I'm running firefox on 64-bit Big-Endian and am till current date stuck
on these packages:
ii firefox 85.0.1-1 ppc64 Mozilla Firefox
web browser
ii firefox-esr 78.14.0esr-1+b1 ppc64 Mozilla Firefox
web browser - Extended Support Release (ES
On Thu, Aug 31, 2023 at 11:16:01PM +0200, John Paul Adrian Glaubitz wrote:
> On Thu, 2023-08-31 at 23:06 +0200, John Paul Adrian Glaubitz wrote:
> > Can anyone running Debian on ppc64 please give it a try?
>
> It might crash because of this bug:
>
> > https://bugzilla.mozilla.org/show_bug.cgi?id=
On Thu, 2023-08-31 at 23:06 +0200, John Paul Adrian Glaubitz wrote:
> Can anyone running Debian on ppc64 please give it a try?
It might crash because of this bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1845669
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `'
Hi!
Thanks to the efforts of Debian's Firefox maintainer, the Firefox package
is building again on ppc64 (big-endian) the first time in a long period.
However, we don't know whether Firefox actually works on 64-bit Big-Endian
PowerPC.
Can anyone running Debian on ppc64 please give it a try?
Tha
Control: severity -1 important
On Sun, 18 Jun 2023 at 14:52:18 +0100, Simon McVittie wrote:
> On Sun, 18 Jun 2023 at 14:47:00 +0100, Simon McVittie wrote:
> > I rebuilt librsvg in bookworm on the s390x porterbox zelenka, and can
> > confirm that 2.54.5+dfsg-1 now fails in bookworm too. So somethin
> On Jun 18, 2023, at 3:53 PM, Simon McVittie wrote:
>
> On Sun, 18 Jun 2023 at 14:47:00 +0100, Simon McVittie wrote:
>> I rebuilt librsvg in bookworm on the s390x porterbox zelenka, and can
>> confirm that 2.54.5+dfsg-1 now fails in bookworm too. So something must
>> have triggered a regress
On Sun, 18 Jun 2023 at 14:47:00 +0100, Simon McVittie wrote:
> I rebuilt librsvg in bookworm on the s390x porterbox zelenka, and can
> confirm that 2.54.5+dfsg-1 now fails in bookworm too. So something must
> have triggered a regression between September 2022 and now.
It would be helpful if someon
On Sun, 18 Jun 2023 at 13:40:09 +0100, Simon McVittie wrote:
> librsvg 2.54.5+dfsg-2 failed to build on s390x, powerpc and ppc64 with
> multiple test failures. At first glance, they seem to be the same test
> failures, meaning this is about endianness rather than any specific
>
/librsvg/-/issues/972
librsvg 2.54.5+dfsg-2 failed to build on s390x, powerpc and ppc64 with
multiple test failures. At first glance, they seem to be the same test
failures, meaning this is about endianness rather than any specific
architecture.
2.54.5+dfsg-2 only contains packaging changes and no
sparc64, the test failures
are exactly the same as on s390x which is also 64-bit big-endian.
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
--- pydevd2/py
ts_innodb 'innodb' w12 [ pass ] 48457
main.parser_bug21114_innodb 'innodb' w13 [ pass ] 86834
worker[1] Test still running: main.index_merge_innodb
worker[1] Test still running: main.index_merge_innodb
worker[1] Test still running: main.index_merge_innodb
worker[1] Test still r
Source: ffmpeg
Version: 7:5.1.1-1
Severity: normal
User: debian-powerpc@lists.debian.org
Usertags: hppa m68k powerpc ppc64 sparc64
X-Debbugs-Cc:
debian-...@lists.debian.org,debian-h...@lists.debian.org,debian-powerpc@lists.debian.org,debian-sp...@lists.debian.org
Hello!
The test filter
On 3/28/22 18:00, John Paul Adrian Glaubitz wrote:
Hi!
On 3/28/22 22:58, Dennis Clarke wrote:
Works like a charm!
Good to hear!
Indeed. I am still unsure how I landed in this spot but it all started
with the dreaded nvram --update-config boot-device="" step. That gave
me a machine th
Hi!
On 3/28/22 22:58, Dennis Clarke wrote:
> Works like a charm!
Good to hear!
> I simply used the default install option from the GRUB menu that
> is provided by the installer and then followed the prompts. Not sure
> what you changed but this time everything just flows naturally. Shoul
On 3/28/22 14:42, John Paul Adrian Glaubitz wrote:
On Mar 28, 2022, at 8:38 PM, Dennis Clarke wrote:
With great thanks to John Paul Adrian Glaubitz we see new test images
have landed :
https://cdimage.debian.org/cdimage/ports/snapshots/2022-03-28/
Therefore I shall jump on that
On 3/28/22 14:42, John Paul Adrian Glaubitz wrote:
On Mar 28, 2022, at 8:38 PM, Dennis Clarke wrote:
With great thanks to John Paul Adrian Glaubitz we see new test images
have landed :
https://cdimage.debian.org/cdimage/ports/snapshots/2022-03-28/
Therefore I shall jump on that
> On Mar 28, 2022, at 8:38 PM, Dennis Clarke wrote:
>
>
>
> With great thanks to John Paul Adrian Glaubitz we see new test images
> have landed :
>
>https://cdimage.debian.org/cdimage/ports/snapshots/2022-03-28/
>
> Therefore I shall jump on that right
With great thanks to John Paul Adrian Glaubitz we see new test images
have landed :
https://cdimage.debian.org/cdimage/ports/snapshots/2022-03-28/
Therefore I shall jump on that right away and begin a test install
on my dual disk PowerMac G5 "quad" and I hope for wonder
porters, the root cause seems more or less evident and should be fixed
by upstream in a later version.
Latest mariadb-10.6 1:10.6.7-3 does build, but test suite fails with:
main.grant_kill w10 [ fail ]
Test ended at 2022-03-11 17:19:58
CURRENT_TEST: main.grant_kill
Hi!
On 4/11/21 3:27 PM, John Paul Adrian Glaubitz wrote:
> If everything works as intended, the partitioning program should automatically
> create and format a GRUB boot partition and mount it to /boot/grub. If that's
> the case, I can commit the changes to partman-auto and submit the new
> partm
Hi!
Here is a new test image [1] which is supposed to test the proper partitioning
of the HFS boot partition and mounting it to /boot/grub.
Note: This image will *not* install GRUB yet properly. The purpose of this image
is just to test whether the changes I made to the package partman
Ok, in that case, I think that a comment in the d/rules files is enough in
order to keep in mind that we have this issue with ppc64el.
> Well, the test is obviously broken and upstream currently can't be bothered
> to fix
> it on non-x86 targets. He will certainly have to do it at some point given
> that ARM64
> is replacing more and more x86_64 systems, but I wouldn't bother, personally.
so what is t
On 12/18/20 4:49 PM, Andreas Tille wrote:
>> Well, the test is obviously broken and upstream currently can't be bothered
>> to fix
>> it on non-x86 targets. He will certainly have to do it at some point given
>> that ARM64
>> is replacing more and more x8
> Yes, good catch. The spec file for the openSUSE package has this [1]:
so it does not fit with our policy: do not hide problems ;)
The problem is that I do not have enougt time to investigate... on a porter box
On Fri, Dec 18, 2020 at 04:44:04PM +0100, John Paul Adrian Glaubitz wrote:
> >
> > so it does not fit with our policy: do not hide problems ;)
Well, we do not need to *hide* the problem. We can exclude the test and
*document* the problem - say in a README.Debian on the affected
On 12/18/20 4:42 PM, PICCA Frederic-Emmanuel wrote:
>> Yes, good catch. The spec file for the openSUSE package has this [1]:
>
> so it does not fit with our policy: do not hide problems ;)
>
> The problem is that I do not have enougt time to investigate... on a porter
> b
hgo_scipy_vs_lmfit_2)'
> [ 97s] ===== test session starts
> ==
>
> does it means that the failling test on Debian is skipped during the build on
> OBS ?
Yes, good catch. The spec file for the openSUSE package has thi
Hello
looking at the Opensuze log, I can find this
[ 93s] + pytest-3.8 --ignore=_build.python2 --ignore=_build.python3
--ignore=_build.pypy3 -v -k 'not speed and not (test_model_nan_policy or
test_shgo_scipy_vs_lmfit_2)'
[ 97s] = test sess
On Fri, Dec 18, 2020 at 03:41:58PM +0100, John Paul Adrian Glaubitz wrote:
> On 12/18/20 3:19 PM, Andreas Tille wrote:
> > I wonder whether we could get some help from PowerPC team to solve this
> > issue. If we can not get that test working I see only two options:
> >
On 12/18/20 3:19 PM, Andreas Tille wrote:
> I wonder whether we could get some help from PowerPC team to solve this
> issue. If we can not get that test working I see only two options:
>
>1. Skip this specific test
>2. Exclude ppc64el from architecture list
>
> Any
Control: tags -1 -upstream
Control: tags -1 help
Hi,
I wonder whether we could get some help from PowerPC team to solve this
issue. If we can not get that test working I see only two options:
1. Skip this specific test
2. Exclude ppc64el from architecture list
Any help would be really
On 1/4/20 3:25 PM, Rene Engelhard wrote:
> On Sat, Jan 04, 2020 at 03:15:02PM +0100, John Paul Adrian Glaubitz wrote:
>> Feel free to do the same for powerpc as the build machine
>> for ppc64 and powerpc is the same and the new one for
>> both architectures will be even faster.
>
> No, powerpc in
On Sat, Jan 04, 2020 at 03:15:02PM +0100, John Paul Adrian Glaubitz wrote:
> Feel free to do the same for powerpc as the build machine
> for ppc64 and powerpc is the same and the new one for
> both architectures will be even faster.
No, powerpc in 32bits is dead.
And I even enabled i386 there onl
On 1/4/20 2:57 PM, Rene Engelhard wrote:
> Yes, because BUILD_NOGUI_PACKAGES=y is set because of findstring vs. filter.
>
> There you *are* right, I didn't say anything else.
This bug report was just about this particular issue
of using the wrong keyword.
>> What? I'm not sure why this would be
Hi,
On Sat, Jan 04, 2020 at 02:33:51PM +0100, John Paul Adrian Glaubitz wrote:
> On 1/4/20 2:28 PM, Rene Engelhard wrote:
> > That just means that BUILD_NOGUI_PACKAGES=n is set and the nogui part is
> > not even tried.
> > ppc64 is fast and has server uses, so should definitel get -nogui.
>
> Th
Hi,
On Sat, Jan 04, 2020 at 02:07:36PM +0100, John Paul Adrian Glaubitz wrote:
> On 1/4/20 10:19 AM, John Paul Adrian Glaubitz wrote:
> > I haven't verified it, but my suspicion is that the following conditional
> > test is
> > incorrect as the function findst
be a workaround. You didn't
put ppc64 in the list of NOGUI architectures. That means the
nogui code itself wasn't build.
>From [1]:
"Searches in for an occurrence of find. If it occurs, the value is find;
otherwise, the value is empty. You can use this function in a co
On 1/4/20 10:19 AM, John Paul Adrian Glaubitz wrote:
> I haven't verified it, but my suspicion is that the following conditional
> test is
> incorrect as the function findstring will match "ppc64" in OOO_NOGUI_ARCHS if
> it contains "ppc64el":
&g
/applications/*.desktop’: No such
file or directory
make: *** [debian/rules:2699: debian/stampdir/install-arch] Error 1
I haven't verified it, but my suspicion is that the following conditional test
is
incorrect as the function findstring will match "ppc64" in OOO_NOGUI_ARCHS if
it co
On 2019-05-11, John Paul Adrian Glaubitz wrote:
>>> If you find some time, I think it would be interesting if we had a
>>> grub-boot test image where BootX is using:
>>>
>>>
>>> boot &device;:,\System\Library\CoreServices\grub.elf
>>
On 5/11/19 8:07 AM, John Paul Adrian Glaubitz wrote:
>> If you find some time, I think it would be interesting if we had a
>> grub-boot test image where BootX is using:
>>
>>
>> boot &device;:,\System\Library\CoreServices\grub.elf
>>
>>
>> I
rom the grub.chrp.in located in the same folder:
> http://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/boot/powerpc/grub.chrp.in
> When I get some free time I'll try to find out where &partition; came
> from and why BootX is using it.
>
> If you find some time, I think it would be i
would be interesting if we had a
grub-boot test image where BootX is using:
boot &device;:,\System\Library\CoreServices\grub.elf
I suspect Apple users would then be able to "properly" boot from USB
with:
boot usb0/disk:,\\:tbxi
John Ogness
better to follow the common practice for creating these
> images.
It's difficult to say because the Debian images you've created are the first
ones I
have that use grub unless you have pointers to any others? But certainly across
all
the OS images I use to test boot QEMU/Open
he /System/Library/CoreServices/grub.elf path is completely
unnecessary,
and not part of any standard or like anything else I have in my OpenBIOS image
test
suite. If you search for "CoreServices" you can see that it's a MacOS-specific
directory, and the only way that example could
Hi,
i wrote:
> > If a file CD1/System/Library/CoreServices/BootX had existed on hard disk,
> > the pathspec "CD1" would have overwritten the previously inserted IsoNode
> > object which held the instruction to copy from "grub.chrp".
John Paul Adrian Glaubitz wrote:
> But there is no file CD1/Syst
On 5/4/19 9:19 PM, John Paul Adrian Glaubitz wrote:
> I just created the first test image for debian-installer which boots
> with GRUB instead of Yaboot. The image is available from the usual
> location for GRUB tests:
>
>> https://cdimage.debian.org/cdimage/ports/grub-test/
On 5/5/19 5:19 PM, Thomas Schmitt wrote:
>> BootX is an enhanced bootloader written by Apple [...]
>> in real life BootX is a COFF executable and not a bootinfo file.
>
> This seems to be not mutually exclusive.
>
> https://opensource.apple.com/source/bless/bless-11/README.BOOTING
> states
>
On 5/5/19 4:24 PM, Mark Cave-Ayland wrote:
> Right, these graft points are unnecessary - if you look at the BootX file on
> the ISO
> then it's simply a pointer to /boot/grub/powerpc-ieee1275/grub.chrp which is a
> bootinfo file containing this:
>
>
> boot &device;:&partition;,\System\Library\Co
On 5/5/19 3:59 PM, Thomas Schmitt wrote:
> It's name on hard disk was "grub.chrp".
> (Its purpose and format is beyond my knowledge.)
It's a CHRP bootscript for PowerMacs.
> If a file CD1/System/Library/CoreServices/BootX had existed on hard disk,
> the pathspec "CD1" would have overwritten the p
On 5/5/19 2:47 PM, Mark Cave-Ayland wrote:
> Ah no, that's not correct - BootX is an enhanced bootloader written by Apple
> to
> enable multi-booting with MacOS X and grub-mkrescue is assuming that it is
> being
> installed on a HD containing MacOS X with BootX in the default location.
> Whilst
On 5/5/19 16:35, Mark Cave-Ayland wrote:
On 05/05/2019 15:02, Frank Scheiner wrote:
On 5/5/19 14:47, Mark Cave-Ayland wrote:
On 05/05/2019 13:24, John Paul Adrian Glaubitz wrote:
I think the bootinfo.txt is for IBM CHRP machines while the BootX is for Macs.
Ah no, that's not correct - Bo
Hi,
Mark Cave-Ayland wrote:
> Right, these graft points are unnecessary - if you look at the BootX file on
> the ISO then it's simply a pointer to /boot/grub/powerpc-ieee1275/grub.chrp
They are copy siblings. libisofs knew that they came from the same hard
disk inode and thus decided to store the
On 05/05/2019 15:02, Frank Scheiner wrote:
> On 5/5/19 14:47, Mark Cave-Ayland wrote:
>> On 05/05/2019 13:24, John Paul Adrian Glaubitz wrote:
>>
>>>> On May 5, 2019, at 2:16 PM, Mark Cave-Ayland
>>>> wrote:
>>>>
>>>> Presumabl
10.0-powerpc-grub-NETINST-1.iso /mnt/iso
>
> cat /mnt/iso/.disk/mkisofs
>
> yields in a single line which i break up here:
>
> xorriso -as mkisofs \
> -r \
> -checksum_algorithm_iso md5,sha1 \
> -V 'Debian 10.0 ppc n' \
> -o /home/glaub
On 5/5/19 14:47, Mark Cave-Ayland wrote:
On 05/05/2019 13:24, John Paul Adrian Glaubitz wrote:
On May 5, 2019, at 2:16 PM, Mark Cave-Ayland
wrote:
Presumably for the test ISO image you were manually copying
/System/Library/CoreServices/* into the image yourself? Hopefully with the above
which i break up here:
xorriso -as mkisofs \
-r \
-checksum_algorithm_iso md5,sha1 \
-V 'Debian 10.0 ppc n' \
-o /home/glaubitz/debian-cd-test/debian-10.0-powerpc-NETINST-1.iso \
-J -joliet-long \
-cache-inodes \
-hfsplus -apm-block-size 2048 \
-hfsp
On 05/05/2019 13:24, John Paul Adrian Glaubitz wrote:
>> On May 5, 2019, at 2:16 PM, Mark Cave-Ayland
>> wrote:
>>
>> Presumably for the test ISO image you were manually copying
>> /System/Library/CoreServices/* into the image yourself? Hopefully with the
>>
> On May 5, 2019, at 2:16 PM, Mark Cave-Ayland
> wrote:
>
> Presumably for the test ISO image you were manually copying
> /System/Library/CoreServices/* into the image yourself? Hopefully with the
> above
> changes then you should no longer have to do this.
No, I
On 04/05/2019 20:19, John Paul Adrian Glaubitz wrote:
> Hello!
>
> I just created the first test image for debian-installer which boots
> with GRUB instead of Yaboot. The image is available from the usual
> location for GRUB tests:
>
>> https://cdimage.debian.org
> On May 5, 2019, at 8:46 AM, Frank Scheiner wrote:
>
> @Adrian:
> The `hfsprogs` package was also not included in the older ISO from
> 2019-04-20 (I only checked the ppc64 one). Should we include it, so
> off-line installations work?
Yes. I will include hfsprogs to the package list for d-i.
On 5/5/19 08:46, Frank Scheiner wrote:
@Adrian:
The `hfsprogs` package was also not included in the older ISO from
2019-04-20 (I only checked the ppc64 one). Should we include it, so
off-line installations work?
OTOH should this even work? I.e. to install a base OS from just the
netinstall ISOS?
On 5/5/19 00:27, Karl wrote:
Hope this helps
https://ibb.co/hmHrvfT
The installer can't find the `hfsprogs` package. I just checked the
Debian Ports FTP service and it's there, both for powerpc and ppc64. So
either your Internet connection was down or - if packages were installed
from the insta
1 - 100 of 938 matches
Mail list logo
