Re: Please test Firefox on ppc64
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=1845669 Just installed and given firefox 117.0-1 a spin on ppc64. It segfaults on startup. Not sure if that is the bug you reference. I can try to get a backtrace. Hmm the debugging symbols file is massive and gdb is already up to 85% memory and swap used. Still loading and voraciously swapping virtual memory. Maybe another day... Regards, Michael.
Re: setting up a sbuild chroot - which key?
On Fri, May 03, 2024 at 11:58:57PM +0200, Riccardo Mottola wrote: > no hint for me which key to use? or if I miss one, where to get it? > > I have apt-get working, so I think I have the key. You looking for the key to install a chroot with powerpc or ppc64 from debian-ports? Assuming you have debian-ports-archive-keyring package installed then you will find it in the directory: /etc/apt/trusted.gpg.d/ Cheers Michael.
Re: installing NETINST 20190127 on Mac mini G4
On Mon, Jan 28, 2019 at 12:45:10PM +0100, John Paul Adrian Glaubitz wrote: > On 1/28/19 12:34 PM, Rick Thomas wrote: > > I realize that this may require some programming, but would it be possible > > to have it ask a question early on (maybe at or before the beginning of > > partitioning) requesting the user to choose between yaboot and grub? Then > > the partitioner would automatically create the necessary partition(s) and > > “install boot loader” would automatically install the chosen boot loader > > conditioned on the answer to the question… > > Yaboot is unmaintained upstream and does not support modern ext4 features. In > order for Yaboot to work properly, you have to turn certain features in ext4 > off, otherwise it won't work and the boot fails. Can you not have an ext3 boot partition and the rest of the OS on an ext4 partition? Cheers Michael.
Re: installing NETINST 20190127 on Mac mini G4
On Tue, Jan 29, 2019 at 12:07:38AM -0800, Rick Thomas wrote: > > > > On Jan 29, 2019, at 12:00 AM, Michael Cree wrote: > > > > On Mon, Jan 28, 2019 at 12:45:10PM +0100, John Paul Adrian Glaubitz wrote: > >> On 1/28/19 12:34 PM, Rick Thomas wrote: > >>> I realize that this may require some programming, but would it be possible > >>> to have it ask a question early on (maybe at or before the beginning of > >>> partitioning) requesting the user to choose between yaboot and grub? Then > >>> the partitioner would automatically create the necessary partition(s) and > >>> “install boot loader” would automatically install the chosen boot loader > >>> conditioned on the answer to the question… > >> > >> Yaboot is unmaintained upstream and does not support modern ext4 features. > >> In > >> order for Yaboot to work properly, you have to turn certain features in > >> ext4 > >> off, otherwise it won't work and the boot fails. > > > > Can you not have an ext3 boot partition and the rest of the OS on > > an ext4 partition? > > I don’t know if it works with ext3, but I can personally vouch for it > with ext2. That's basically what I mean; make a boot partition with whatever the bootloader is capable of reading. That's what we do on Alpha where a similar problem exists; however the Alpha boot loader (aboot), though possibly simpler than yaboot is far superior in its user interface, and because its source package produces a binary package usable on all architectures it remains in the official Debian archive. As much as a loathe grub (and I do; I far prefer the simplicity of the Alpha aboot) I agree with Adrian that if grub can be made to work on all PowerPC/PPC64 supported computers, then yaboot should be removed from the distribution. Cheers, Michael.
Re: PPC64 Illegal Instruction
On Sat, Mar 02, 2019 at 10:48:34PM +, Noah Wolfe wrote: > I just wanted to alert you that VLC, Audacity, Audacious, and > many other applications, do not start when launched from a > graphical menu, and immediately give out "Illegal instruction" > when launched via Terminal in PPC64, Confirmed on Mac G5. Mpv crashes on invocation with the following backtrace in the x265 library: Program terminated with signal SIGILL, Illegal instruction. #0 0x7fffb3f561f8 in __static_initialization_and_destruction_0 (__priority=65535, __initialize_p=1) at ./source/common/ppc/intrapred_altivec.cpp:30808 30808 ./source/common/ppc/intrapred_altivec.cpp: No such file or directory. (gdb) bt #0 0x7fffb3f561f8 in __static_initialization_and_destruction_0 (__priority=65535, __initialize_p=1) at ./source/common/ppc/intrapred_altivec.cpp:30808 #1 _GLOBAL__sub_I_intrapred_altivec.cpp(void) () at ./source/common/ppc/intrapred_altivec.cpp:30808 #2 0x7fffb9bc5ca8 in call_init (env=0x74dda8e0, argv=0x74dda8c8, argc=2, l=) at dl-init.c:72 #3 call_init (l=, argc=, argv=0x74dda8c8, env=0x74dda8e0) at dl-init.c:28 #4 0x7fffb9bc5dfc in _dl_init (main_map=0x7fffb9bf11f0, argc=, argv=0x74dda8c8, env=0x74dda8e0) at dl-init.c:119 #5 0x7fffb9bb3c3c in ._dl_start_user () from /lib64/ld64.so.1 Disassembling lists the following offending instruction: => 0x7fffb3f561f8 <+88>:stxvw4x vs32,0,r9 I don't see that instruction in the Altivec programming manual from Freescale. Gcc manual lists this instruction as being VSX which is used if -mvsx is given on compilation invocation. There is also a comment that stxvw4x will be used if one of the vec_vsx_st() built-ins are used (but there is no such usage in the x265 source file.) I see in the x265 build-log on the compilation invocataions the definition "-DX265_ARCH_POWER8=1". Maybe that's the problem? The buildd is a Power8 (or even a Power9) machine, no? Looks like x265 is being built for the buildd, not for ppc64. I've run out of time to investigate further, sorry. Cheers, Michael.
Re: PPC64 Illegal Instruction
On Mon, Mar 04, 2019 at 11:44:37AM +0100, John Paul Adrian Glaubitz wrote: > FWIW, the x265 bug originally reported by Noah should be fixed now. Don't be funny. The fix was applied to a newer version of x265 with an SO name change in experimental. It is absolutely uselss for us. Cheers Michael.
Re: PPC64 Illegal Instruction
On Mon, Mar 04, 2019 at 06:53:56PM +, Noah Wolfe wrote: > @Michael, if I may ask (and if I have this right), if the fix was > simply a name change for a newer version, and effectively useless for > us, what was the point of changing it, and what can be done to fix our > issue? The baseline fix was applied to x265 in the experimental distribution, not in unstable. One could argue that you could just install x265 from experimental but that won't work either, because you would need to rebuild all packages that depend on the x265 library in unstable to be able to use the experimental x265. So this fix is practically useless to anyone running unstable but the maintainer gets to close the bug report as fixed. Cheers Michael.
Re: PPC64 Illegal Instruction
On Mon, Mar 04, 2019 at 07:40:56PM +, Noah Wolfe wrote: > Ah, I see. So as I understand it, the fix was applied to upstream > experimental, and will in time make its way downstream to unstable. > That's why it would be closed as fixed, right? No, it is fixed in Debian experimental (i.e., not upstream). > So it's useless only for the time being. Probably for a very large value of "only for the time being" because Debian is now essentially frozen, and the version of x265 in experimental will not be uploaded to unstable until after the release of Buster which is likely to be months away. Cheers, Michael.
Re: PPC64 Illegal Instruction
On Mon, Mar 04, 2019 at 11:05:09PM +0100, John Paul Adrian Glaubitz wrote: > On 3/4/19 9:59 PM, Noah Wolfe wrote: > > I see... I completely forgot about Buster's release schedule. > > > > Well, thank you for doing what you could. > I can upload a fixed version to the "unreleased" repository which you > can use. Please be patient, I will be traveling tomorrow but I will > be bringing my laptop. Just upgrading my PPC64 Mac and got an illegal instruction when processing triggers for vlc. Looks like this bug. Checking the unreleased distribution it looks like you never got around to building a fixed x265 and uploading. I could build a fixed x265 but I don't have upload rights to the PPC64 distribution so can't help out. Adrian: would it be too much trouble to do the x265 fix and upload to PPC64/unreleased? Cheers, Michael.
Re: PPC64 Illegal Instruction
On Sat, Jun 22, 2019 at 11:31:17AM +0200, John Paul Adrian Glaubitz wrote: > On 6/22/19 11:04 AM, Michael Cree wrote: > > Adrian: would it be too much trouble to do the x265 fix and upload > > to PPC64/unreleased? > > I'd rather have a proper fix in the Debian package such that we don't > have to touch the package manually each time VLC gets updated in the > archives. > > Could you attach the patch necessary to fix this issue? It's x265 that needs fixing. It's fixed in x265 in experimental but the fix was never uploaded to unstable. See https://salsa.debian.org/multimedia-team/x265/commits/master for the top two commits but one, one to disable altivec (which I am not sure is necessary on ppc64, but is on powerpc) and one to disable POWER8 when building on ppc64 (which is the real problem for the ppc64 distribution). Cheers, Michael.
Re: Status of OpenGL on Mac
On Thu, Sep 19, 2019 at 09:26:31PM +0200, Riccardo Mottola wrote: > > Also, have you installed the firmware-amd-graphics package which contains > > firmware necessary for many AMD/ATI cards? If I remember correctly, the > > firmware is needed on the G4 laptops with a Radeon chipset. > > you got it I have no firmware installed, because it is non-free and we > don't have non-free in "ports". > What is the best way to get it nowadays? Download from packages.debian.org? You probably want: firmware-linux-nonfree firmware-amd-graphics And if you have one of the b43 wireless interfaces you might want to get one of: firmware-b43-installer firmware-b43legacy-installer which downloads the firmware for those cards. Cheers Michael.
Re: Booting Debian 10 on powernv POWER9 machine
On Thu, Oct 17, 2019 at 02:58:37PM -0400, Lennart Sorensen wrote: > On Thu, Oct 17, 2019 at 02:57:12PM -0300, Gustavo Romero wrote: > > Sorry, I wrote my note super hastily and forgot to mention that I was > > wondering > > about BE specifically. Currently I see kernel 4.16 is used by the installer > > and > > I get a panic regarding a VMX Unavailable Exception on POWER9 powernv (both > > baremetal / OPAL and qemu emulated), so I'm wondering if anybody else is > > catching that panic too etc. I know BE support for PPC64 was dropped > > officially > > by I understand buildd builders are still building it so there are fresh > > packages out there. > > > > Thanks for replying and for the comments! > > I don't believe 64 bit powerpc big endian was ever officially released > by Debian. 32 bit was but was dropped some time ago. > > 64 bit little endian on the other hand is supported. 32-bit BE powerpc and 64-bit BE ppc64 ports are unofficially maintained at debian-ports: https://www.ports.debian.org/ There are installers there. Only unstable is available. Cheers, Michael.
Re: sid installer images with LXDE desktop environment
On Sun, Nov 03, 2019 at 07:15:14PM +0100, Jeroen Diederen wrote: > The problem I am having is that very often when I want to install a sid LXDE > environment on one of my Macs, the netinstaller stops the installation > process as some package is missing from Debian-ports. For example, the last > couple of this it stops at installing vim-tiny in sid powerpc. You would probably be better off fixing the vim FTBFS in powerpc. There are a number of FTBFS in powerpc that affect installing a desktop environment (whether it be LXDE or not) and they need to be fixed first. Once they are fixed then the standard install image should be capable of installing LXDE (assuming that is indeed one of the standard desktop options offered up by tasksel). Cheers, Michael.
Re: ofpath vs ofpathname vs grub-ofpathname
On Thu, Apr 16, 2020 at 06:07:29PM +0200, John Paul Adrian Glaubitz wrote: > Done. Could someone perform tests on various Mac systems, please and > provide the output of "ofpathname /dev/sda1", "ofpathname /dev/sd2" > and - if available - "ofpathname /dev/sdb1" and provide the same output > from the patched ofpath of Yaboot? Machine (from /proc/cpuinfo): cpu : PPC970MP, altivec supported motherboard : PowerMac11,2 MacRISC4 Power Macintosh detected as : 337 (PowerMac G5 Dual Core) Running yaboot (1.3.17-4+ports1) ofpath: root@joule:~# ofpath /dev/sda1 /ht@0,f200/pci@9/k2-sata-root@c/@1/@0:1 Running ofpathname (from your github repo): root@joule:/home/mjc/powerpc-utils.git/scripts# ./ofpathname /dev/sda1 /ht@0,f200/pci@9/k2-sata-root@c/scsi@0/sd@0,0 Cheers, Michael.
Re: ofpath vs ofpathname vs grub-ofpathname
On Fri, Apr 17, 2020 at 01:03:49AM +0200, John Paul Adrian Glaubitz wrote: > On 4/17/20 12:39 AM, Michael Cree wrote: > > Machine (from /proc/cpuinfo): > > cpu : PPC970MP, altivec supported > > motherboard : PowerMac11,2 MacRISC4 Power Macintosh > > detected as : 337 (PowerMac G5 Dual Core) > > > > Running yaboot (1.3.17-4+ports1) ofpath: > > root@joule:~# ofpath /dev/sda1 > > /ht@0,f200/pci@9/k2-sata-root@c/@1/@0:1 > > > > Running ofpathname (from your github repo): > > root@joule:/home/mjc/powerpc-utils.git/scripts# ./ofpathname /dev/sda1 > > /ht@0,f200/pci@9/k2-sata-root@c/scsi@0/sd@0,0 > > This looks like you forgot to switch to the mac_support branch, didn't you? There was no forgetting; only a misreading of the original message when skim-reading due to being in a hurry. You have a habbit of making negative assumptions of people who are only trying to help which is, frankly, not appreciated. >From the mac_support branch: root@joule:/home/mjc/powerpc-utils.git/scripts# ./ofpathname /dev/sda1 /ht@0,f200/pci@9/k2-sata-root@c/@0/@0:1 Cheers, Michael.
Re: ofpath vs ofpathname vs grub-ofpathname
On Fri, Apr 17, 2020 at 07:28:37AM +0200, John Paul Adrian Glaubitz wrote: > On 4/17/20 1:18 AM, Michael Cree wrote: > > There was no forgetting; only a misreading of the original message > > when skim-reading due to being in a hurry. You have a habbit of > > making negative assumptions of people who are only trying to help > > which is, frankly, not appreciated. > > Not sure how asking whether you may have forgotten to switch the branch a > negative assumption. I'm not sure what else I'm supposed to do when I > have doubts about the test result. The bit about "has the appearance of..." was fine. I agree that it did have that appearance. It was following it up with "didn't you?" which was both unnecessary and an untrue accusation. In NZ English that phrase is often used very negatively of people and maybe I have a heightened sensitivity to it because of that. > There is no bad intention implied, Good to hear. > just a potential language barrier > of me not being a native speaker of the English language. And even if you were a native speaker the problem remains. I quickly discovered in the early days of being online that one has to be very careful not to use sarcasm in the presence of the citizens of a certain English speaking nation as they completely misunderstand it and think it is being mean! Sigh... Now, getting back to being on-topic for this email list: > Now, the only test I would like to see is whether ofpath sees a difference > between "sda" and "sdb" because apparently, Romain got identical paths > with ofpathname for both his disks. I only have one disk in my G5. I do have some spare disks about the place and could put another one in to test, but at this point I will wait a bit to see if anyone else can easily run this test first. Cheers, Michael.
Re: More testing and pending updated installation images
On Fri, Apr 17, 2020 at 10:59:15PM +0200, John Paul Adrian Glaubitz wrote: > Currently, I'm interested in drives connected over IDE, SATA, SCSI > and USB. I have done anything for Firewire yet. I do have an external firewire hard drive which I can test, but will need to wait to at least next week to test because it is at work. Hopefully lockdown will be relaxed in a few day's time and I can get into the office to pick it up. Cheers, Michael.
Re: ofpath vs ofpathname vs grub-ofpathname
On Fri, Apr 17, 2020 at 09:48:47PM +, Dennis Clarke wrote: > On 4/17/20 9:18 PM, Michael Cree wrote: > > On Fri, Apr 17, 2020 at 07:28:37AM +0200, John Paul Adrian Glaubitz wrote: > > > On 4/17/20 1:18 AM, Michael Cree wrote: > > > > There was no forgetting; only a misreading of the original message > > > > when skim-reading due to being in a hurry. You have a habbit of > > > > making negative assumptions of people who are only trying to help > > > > which is, frankly, not appreciated. > > > > > > Not sure how asking whether you may have forgotten to switch the branch a > > > negative assumption. I'm not sure what else I'm supposed to do when I > > > have doubts about the test result. > > > > The bit about "has the appearance of..." was fine. I agree that it did > > have that appearance. It was following it up with "didn't you?" which > > was both unnecessary and an untrue accusation. In NZ English that > > phrase is often used very negatively of people and > > When did people get so damn sensitive? > > I am happy with anything JPAG[1] has to say in any language any way he > damn well wants. You may well be, but that is not the standard expected of those posting to Debian email lists [1]. > That is not just because he is doing heavy lifting but > because of language barriers and damn it in open source we should all > just be happy someone is there helping out with us and quite frankly for > us. Otherwise take it up with your HR department and bring a box of > tissue for your sensitive eyes. Your comments are not helpful. The matter was between Adrian and myself and is resolved. Cheers. Michael. [1] See under "Code of Conduct" of https://www.debian.org/MailingLists/ and https://www.debian.org/code_of_conduct
Re: ATI Mobility Radeon 7500 and iBook G3's
On Mon, Apr 20, 2020 at 10:12:10PM -0400, Steve Burkhart wrote: > While we're on the topic of display driver problems, does anyone know why > the ATI Radeon 7500 found in many iBook G3 models is non functional with > Xorg? After installing the non free firmware, the screen just blinks, and > eventually freezes. I've encountered this problem on 500Mhz, 600MHz, > 700MHz, 800MHz, and 900MHz iBooks G3's, and the common theme among them is > that they all feature the ATI Mobility Radeon 7500, with either 16MB of > VRAM, or 32MB of VRAM. Have you installed firmware-amd-graphics package in particular? That graphics card should work with the radeon kernel module and most likely requires the radeon/R100_cp.bin firmware which is in the aforementioned debian package. Cheers, Michael.
Re: iMac G3 support in Sid, Impossible?
On Tue, Apr 21, 2020 at 02:16:21PM +0200, Karl wrote: > > Am 16.04.2020 um 20:12 schrieb Lennart Sorensen > > : > > > > … that is no longer a release architecture (because > > apparently there wasn't enough people to maintain it at a high enough > > level) … > > -- > > Len Sorensen > > > > Sorry, this isn’t true ... Accusing someone of making false statements without providing any evidence in support of your accusation is a little bit on the nose. My personal observations of the public discussions of the Debian Release and DSA teams is that serious concerns were raised about both the appearance of a lack of upstream toolchain support and the continued absence of Debian Porters for the powerpc port despite that fact being raised in this very forum. Regards, Michael.
Re: iMac G3 support in Sid, Impossible?
On Tue, Apr 21, 2020 at 11:07:43PM +0200, John Paul Adrian Glaubitz wrote: > On 4/21/20 10:59 PM, Michael Cree wrote: > > My personal observations of the public discussions of the Debian > > Release and DSA teams is that serious concerns were raised about > > both the appearance of a lack of upstream toolchain support and the > > continued absence of Debian Porters for the powerpc port despite > > that fact being raised in this very forum. > > To be fair, toolchain support for 32-bit PowerPC has always been pretty > good with a few bugs here and there and most PowerPC stuff, even the > 32-bit parts, is maintained by IBM employees. Yes, but I get the impression that "pretty good" is not considered good enough for a release architecture. Whatever, powerpc had toolchain bugs that had been highlighted for a number of months, that were holding it back and that had no evidence of a fix forthcoming at the time it was kicked out. While I was disappointed by the decision, I nevertheless think it was dropped out on a well justified basis and could not complain. > Overall, 32-bit PowerPC is basically on par with 32-bit > MIPS(el) which is still a release architecture. Having said the above, I do not deny that there does seem to be some inequity in applying the standards, but I don't see much point in getting into discussions down that track. > 64-bit PowerPC (big-endian) is nearly on par with the little-endian port, So what? This discussion is about 32-bit powerpc. Cheers, Michael.
Re: Roll call for porters of architectures in sid and testing (Status update)
FWIW, I am a porter of the Alpha architecture in the following ways: - run a buildd - kernel support - work with upstreams for toolchain support - general porting work including filing bugs and patches I doubt if I will continue that for the life cycle of Jessie given that many of the former faithful seem to be deserting alpha and I don't fancy being the last one left to turn off the lights. But possibly of interest is that I seem to be finding myself using arm based hardware more and more and I anticipate that I might soon be doing arm porting work. Whether that is for all or just a subset of arm ports is yet to be seen. I am subscribed to the debian-alpha and debian-arm mail lists. I am not a DD. Cheers Michael. -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130920092747.GA6590@omega
Re: Bug#399608: fixed in sysvinit 2.88dsf-59.1
[I've trimmed the CCes a bit.] On Mon, May 18, 2015 at 07:52:12PM +0100, Luke Kenneth Casson Leighton wrote: > On Sun, May 17, 2015 at 3:48 PM, Andreas Henriksson wrote: > > Hello Adrian! > > > > Thanks for raising awareness about this issue. If there's anything > > I can do to help please tell me. That the new util-linux version hasn't > > been built yet sounds like it can't be avoided as it was just uploaded > > and unfortunately the sysvinit and util-linux update is a lockstep > > upgrade where both change at the same time as things are moved between > > the packages. There's no intermediate step possible, because the > > moved binaries always needs to be available at all times and thus > > have tight dependencies in both directions. Not sure how dependencies > > affects the build of these packages though They should both be > > able to build on systems with older versions of the packages installed > > and build independently. > > that sounds like the kind of thing that would cause nightmare > circular build dependencies for anyone porting to a new architecture > [which i'm considering doing: mvp from icubecorp]. > > would that be correct - that if there *is* no "older version" it > would now be impossible to build both [or either] of the packages - or > am i mistaken? It's not normally that bad. Old packages exist in snapshot.d.o. In the case of util-linux that the original poster talks about, the old version of util-linux is still in the chroots of the buildd, its just that wanna-build no longer knows about that version so does not offer util-linux for building, so one has to manually schedule a build and binary upload. The situation is different for boot strapping a new architecture. There are quite a number of circular build-dependencies and one breaks the circle with a variety of techniques, one of which is cross-building. Cheers Michael. -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150518195914.GA1661@tower
