Re: xserver-xorg-video-sunffb oudated

Hi Adrian, I can review and sponsor the package for you, I wasn't aware that you had a package ready. I checked quickly, upstream is indeed working on fixing this video driver. They released a new version in December (1.2.3), but there's more activity on the master branch right now. I'll

Re: xserver-xorg-video-sunffb oudated

On 31 January 2024 19:10:19 CET, Angel wrote: >Hello, > >The Debian fork driver (officially linked in the Wiki) for the Creative 3D >card in Sun Ultra 10 is broken since at least xorg-xserver 21. >The repo is very outdated, 10 years without a commit. > >The upstream from Xorg is still maintained

Re: Installing Debian - Sun Ultra1

Hi, I've tried moving RAM around. It didn't seem to make a difference. FYI. The package that fails is often different even without moving RAM around. Solaris 2.5, NetBSD, and OpenBSD all install and function properly on this machine. I've had similar success with my Sun Fire V215. System

SMP kernel on sparc64 working

Hi, I've finally managed to set some time aside to test the latest installer images and kernel 6.4 on a Fire V215. I haven't had time to try it out on my Ultra 10 yet. The good news is that the previous problems I had with SMP are now gone. The SMP kernel was basically unusable before,

Re: V210 booted from iso and installed but could not find mirror?

Also got a kernel panic with vsftpd. Is this with the SMP kernel? You should try the normal one first, it works very stable on my V215. I get crashes all over the the place with the SMP kernel. Unfortunately, that means you'll only have one CPU available...

Re: V210 booted from iso and installed but could not find mirror?

> However, I was unable to find a mirror to download any packages from. > I'm onlyafter basic stuff like tcsh, alpine, openssh-server, etc. > > What are my next steps now to make this system useful? That shouldn't be a problem, you only need to make sure that your apt.sources contains the

Installer message about EFI

Hi, I recently acquired an old Sun Fire V215, which I intend to use for Debian experimentation. Found a minor oddity in the current Debian installer. During GRUB installation, it presents the standard message: It seems that this computer is configured to boot via EFI, but maybe that

Re: LibreOffice architecture support (was: Fwd: Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*))

speak up at upstream or  they will be gone. And without those bridges no architecture support for it. Can you clarify what the consequence of this will be? Will it mean that LibreOffice will become unbuildable for these architectures? Yes. Thanks for informing us, then! I'm 100% in favor

Re: LibreOffice architecture support (was: Fwd: Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*))

- sparc and sparc64 (which are for many BD-Uninstallable since ages because it does not have Java (anymore), didn't do a long-ago transition, ...) Can you clarify this? According to https://buildd.debian.org/status/package.php?p=openjdk-20 , there _is_ a JDK/JRE built for sparc64 (and other

Re: sparc64 pbuilder/cowbuilder setup with qemu

As I mentioned earlier in this thread, you can just configure apt to run as root to avoid this problem. Ah, I missed that. Thanks for the hint. Unfortunately, the "uname: Bad address" doesn't appear in qemu. Looks like I'll have to debug this on the actual hardware after all. Is this a

Re: sparc64 pbuilder/cowbuilder setup with qemu

I suggest reporting this as a QEMU bug first and they'll tell you whether you're at the right address or need to forward this to the kernel or glibc people. Done: https://gitlab.com/qemu-project/qemu/-/issues/1394 I'll create an appropriate Debian bug when I have more information (i.e. which

Re: sparc64 pbuilder/cowbuilder setup with qemu

Hi Adrian, Where should I report this bug, then? On the glibc Bugzilla, or on https://gitlab.com/qemu-project/qemu/-/issues ? Or is this a kernel bug? It looks like another case of values not properly passed between the host and guest in a qemu-user setup. Another very prominent case are

Re: sparc64 pbuilder/cowbuilder setup with qemu

After a lot of yak shaving, I managed to add some debugging to apt: apt/apt-pkg/contrib/fileutl.cc:3364 return _error->Error("Could not switch saved set-user-ID (expected %lu got %lu)", (unsigned long) pw->pw_uid, (unsigned long) suid); (added the typecast to be sure printf isn't doing

Re: sparc64 pbuilder/cowbuilder setup with qemu

[pid 102267] setgroups(1, [0] [pid 102267] <... setgroups resumed>)   = 0 ... [pid 102267] setresgid(65534, 65534, 65534) = 0 [pid 102267] setresuid(42, 42, 42)  = 0 [pid 102267] getgid()   = 65534 [pid 102267] getegid()  = 65534 [pid 102267] getuid()  

Re: sparc64 pbuilder/cowbuilder setup with qemu

E: Method gave invalid 400 URI Failure message: Could not switch saved  set-user-ID E: Method http has died unexpectedly! E: Sub-process http returned an error code (112) This seems to be the problem and related to apt. For some reason, apt is not  able to switch its user id to "_apt". I'm not 

sparc64 pbuilder/cowbuilder setup with qemu

Hi, Since the sparc64 build hosts @The GCC Compile farm are currently a bit hard to reach and my Ultra 10 isn't in working order, I was thinking of setting up a local Qemu cowbuilder/pbuilder installation. But I ran into a problem after following https://wiki.debian.org/Sparc64Qemu : I:

Re: Bug#1020319: openldap: FTBFS on sparc64 due to unaligned access in testsuite

openldap FTBFS on sparc64 due to an unaligned access in the testsuite: Adding __attribute__((packed)) to the MDB_page struct creates some memory alignment warnings, but it will make the test cases succeed: ./../../../libraries/liblmdb/mdb.c: In function ‘mdb_cursor_put’:

Re: newfstatat available on sparc64?

> LLVM has been failing to build on sparc64 for some weeks with the > following error which indicates that the syscall newfstatat is not > available on sparc64 (see below). > > Looking at [1] it seems to be missing. Can it be wired up? The glibc man page[1] states: > The underlying system call

Re: Re: Install Etch on Sparc NFS

Perhaps you could do the base install with Debootstrap from another system?

Re: Bug#1003181: cython: sparc64 is not building cython ("Not For Us")

> The package is currently blocked on sparc64 because the testsuite kept > crashing > the host system and no solution was found yet. It seems that the testsuite > will > put a lot of strain on the host system when the machine has many CPU cores > which > is true for most sparc64 systems we use.

Re: Mozilla Software on Sparc64/Linux

> but how would this work for a patch set of a specific old release .deb > where the .deb is only available on snapshot.debian.org > ? > > I guess i have to then load the specific source package form snapshot > manually? Isn't it possible to add a specific snapshot as

Re: Updated Debian Ports installation images 2021-09-23

> An update on this. > For interest sake I tried an install of Ubuntu 8.04 Sparc. > That gets far further than either of the Debian installs. This would be comparable to Debian etch or lenny. I remember having had a very stable experience with etch on my Ultra 10 back in the day, although this

Re: sunffb xorg driver - was: Re: Bullseye planned on sparc64?

>> Actually... most of what I did was concerned with making the package >> buildable again. It contained some cruft and needed a bit of cleanup and >> re-alignment. > > OK. If you have a patch for that, please post it to the list as this will > help me save some time. I mainly updated standards

Re: sunffb xorg driver - was: Re: Bullseye planned on sparc64?

> In the mean time, we could look into the package that Gregor Riepl made > for that matter. Maybe he can comment on that. > > If that package works, I can build it and make an unofficial upload to > the archive as a temporary hack. I haven't uploaded the package anywhere, but bui

Re: Bullseye planned on sparc64?

Hi Adrian, You are right, of course. It's been a while and I had forgotten what the circumstances were. Did anybody else encounter the input issue I mentioned? I'm not sure if could be related to the graphics driver or not. There is a possibility that Xorg is actually working, but not

Re: Bullseye planned on sparc64?

> On 8/18/21 2:57 AM, Phillip Stevens wrote: >> Yes, I'd also love (pay) to have decent graphics support. I migrated my >> Ultra 5 to Sparc64 in 2018 >> >> and since then hardly turned it on. >> The graphics are a real weak

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

> How should I proceed? Which kernel sources? > > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-official > > > is 4.3 correct for me? 4.6 ? You should clone the upstream Git repo, otherwise bisecting will be much more difficult. I think these instructions

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

> Do you know if I can via serial-console reset the system? > I tried sending a break on the serial console, but the errors just keep > running. > Break is received, since I see it as SC Alert, but I am not put into the > console, maybe there is some further trick on these newer machine? I am >

Re: grub-installer: info: Calling 'apt-install grub-ieee1275' failed

> I have no clue which image you used and I'm not sure what you did to end up > in a situation > where the installer would try to download the grub2 packages over the net > which are actually > on the installation ISO, so they don't have to be downloaded. The only situation where I can imagine

Re: [PATCH v1 08/13] sparc32: Drop sun4d/sun4m smp support

> - case sun4u: > - printk("SUN4U\n"); > - BUG(); > - break; > - default: > - printk("UNKNOWN!\n"); > - BUG(); > - break; > - } Assuming there was a reason why there's a check for sun4u here: What will be the user

Re: mmdebstrap'ping sparc64 failure on amd64 host

> fails with > > Preparing to unpack .../perl-base_5.32.0-5_sparc64.deb ... > *** longjmp causes uninitialized stack frame ***: terminated > > I wonder if it is caused by incomplete emulation by qemu-user-static package, > but I am unsure. Searching for that error reveals a possibly similar

Re: Glint 1.2.9 deb package debian 10 sparc64

> Please assemble a list of packages we need to have for Debian Ports in > "unrelased" > and I'll take care of it later this week or next week. Thank you! These would be: https://salsa.debian.org/onitake-guest/xserver-xorg-video-sunffb

Re: Glint 1.2.9 deb package debian 10 sparc64

> This weekend I sat down and wrestled with the missing Glint driver for > the PGX32 PCI Card. It turned out to be pretty straightforward and I > suspect it was dropped because of lack of interest. I probably took way > more steps then needed but I’ve never done this before on debian. Sounds

Re: sun4u pci Video Card recommendations [openboot not required]?

Hi Mike, > Given the state of the old video drivers missing or non-functioning > in modern Xorg does anyone have any recommendations for PCI Card that > should work well enough on the old hardware. In my case that’s an > Ultra 5, Openboot support is not a requirement. > > Currently I have PGX32

Re: Bug#965342: openjdk-15: Please update build configuration for sparc64

> The latest pre-release version of OpenJDK 15 unfortunately dropped native > Hotspot > support for Solaris and Linux SPARC which is why we have to resort to using > Zero > only. > > The updated diff patches the debian/rules to reflect these changes by > switching > sparc64 to Zero-only and

Re: Does '5.7.6-1' work on USIIIi for you? (was: Re: sparc64 kernel crashes, & using SAS/SATA drives instead of SCA/FC-AL)

> (the XVR-600 isn't supported in X). >From what I can gather on the net, the GPU on this card is a 3DLabs Wildcat, with conflicting information about its generation (2 or 4). Sadly, there's no open-source drivers for these cards, and the only proprietary ones available[1] will likely not work

Re: xserver-xorg-video-mach64 missing

> The Debian Xorg maintainers unfortunately had those packages removed > without asking anyone first whether they still need them , see these > discussions [1][2]. > > I will work on getting the Xorg drivers back. Any help is welcome. See also this sunffb bug:

Re: mkfs.ext2 - state D partitioning stops at 33% /boot

> No, not that I remember, it looked like from the factory. > > But I was also referring to something like [1]. And I also seem to > remember similar issues with ALi/ULi chipsets (e.g. used in Blade 100 > and 150). > > [1]: https://ata.wiki.kernel.org/index.php/Pata_cmd64x#Limitations Found it

Re: mkfs.ext2 - state D partitioning stops at 33% /boot

> Rethinking that, I assume if an UltraSPARC machine boots from a CDROM > drive attached to the built-in ATA controller and the installer later > can find the disc to start the installation, it should also work with > HDDs on that controller, though maybe not with UDMA speeds, but that was > a

Re: mkfs.ext2 - state D partitioning stops at 33% /boot

> @all: > Are there any users that had success with Promise based ATA controllers > on UltraSPARC? As a matter of fact, I do. I had a software RAID running on 2 SATA disks on a Promise SATA300 TX4 controller and even built a custom mounting bracket for my old Ultra 10 to hold more than one disk.

Re: General beginners questions for debian sparc64

> At an X.org conference in Montreal last year I chatted with someone who > was fixing these sorts of problems for IBM. We might get better progress > by looking at the recent fixes in the PPC and ZOS trees (sorry, I have > that name incorrect). These architectures are big endian so the fixes >

Re: General beginners questions for debian sparc64

> I think i should have the PGX64 chipset in this machine, but i am not > sure if it uses the correct driver. glxinfo tells me everything is > fine with direct rendering using llvm. The Rage XL[1] is a fairly dated and limited GPU, but it has very good 2D driver support on Linux. I think it can

Re: 2020-04-19 debian-10.0-sparc64 NETINST working fine sort of but libc6-dev ???

> Ah well, that certainly explains that. Seems deb-src does not exist > either. I think you should use the regular Debian source repo. There is no "special" ports source repo.

Re: Broken Perl or libc?

> Well, I already answered you that this bug exists in glibc 2.30 but not 2.31 > which is why I uploaded glibc 2.31 to unreleased for sparc64. > > I have not verified yet whether this commit fixes the problem, but I assume > it's a commit that is part of the working 2.31 and not in 2.30 branch.

Re: Broken Perl or libc?

[1] https://salsa.debian.org/glibc-team/glibc/-/blob/sid/debian/debhelper.in/libc.postinst >> >> Could you check if b33e946fbb1659d2c5937c4dd756a7c49a132dff changes anything? Where can I find that commit? > Yes, sure. That will take 2-3 hours though. Does that mean you've been able

Broken Perl or libc?

Hi, While upgrading libc and other packages on my old Ultra 10 today, I ran into a pretty serious problem: Setting up libc6:sparc64 (2.30-2) ... dpkg: error processing package libc6:sparc64 (--configure): installed libc6:sparc64 package post-installation script subprocess was killed by signal

Re: How to support the Debian Sparc64 Port

> Yes, feel free to create a bug report if there isn't already one. But be > sure it's actually a bug in src:gcr and not any of the libraries it links > in. > > Report the bug with "reportbug --src gcr" and include the following header > in your bug report: > > User:

Bug#945414: gcr: FTBFS on sparc64 due to 64bit memory access alignment issues

Source: gcr Version: 3.18.0-1 Severity: normal User: debian-sparc@lists.debian.org Usertags: sparc64 Dear Maintainer, The package build of gcr currently fails for the sparc64 architecture due to misaligned access to 64-bit memory, as can be seen in the build log:

Re: How to support the Debian Sparc64 Port

> Yes, feel free to create a bug report if there isn't already one. But be sure > it's actually a bug in src:gcr and not any of the libraries it links in. It is, and I've already found a workaround for one of the alignment problems. gcr is basically at the bottom of the food chain here, causing

Re: How to support the Debian Sparc64 Port

> To see all bugs related to sparc64, use this link: > >> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=sparc64;users=debian-sparc@lists.debian.org > > Note, I haven't checked the list for a long time, some of these bugs might > have fixed themselves over the time through package uploads.

Re: Bug#931873: texlive-bin: FTBFS on sparc64

>> Doesn't that contradict with what the patch does? >> >> (...) >> This merely adds a test for the SPARC architecture, but still keeps the >> special case for Solaris. Hence it will still enable alignment on >> Solaris/x86. > > Well, you're quoting part of my mail only which is where the

Re: Bug#931873: texlive-bin: FTBFS on sparc64

> Testing for "( defined(__sun) && defined(__SVR4))" actually assumes that > Solaris runs on SPARC only which is not the case. Solaris runs on x86 > as well and x86 doesn't have these alignment issues. Hence, the proper > way is to detect the architecture and not the opering system. Doesn't that

Re: Fwd: Fail to boot Fujitsu M10-4

> It's a rather generic error message. You are also getting this when building > GRUB with "-fpie" in CASFLAGS. Doesn't this also happen when an invalid instruction due to a broken boot loader binary (wrong executable format, invalid offset, etc.) is encountered?

Re: Making MAX_PHYS_ADDRESS_BITS configurable

>> On sparc64, MAX_PHYS_ADDRESS_BITS is currently defined as 53 meaning that >> a lot of JITs crash on a sparc64 userspace [1]. > > Correction, it shouldn't be MAX_PHYS_ADDRESS_BITS but sparc64_va_hole_top as > defined in mm/init_64.c. That sounds like a good compromise, considering that

Re: Updated installation images for Debian Ports 2019-05-09

Hi, Finally got around to test the updated image on my Ultra 10 now. A few things to note: - The new GRUB-based CD boot works well. Kudos! - Mirror listing during install and automatic sources.list config afterwards is still broken, requiring manual changes according to

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

>> How can the installation system eat so much memory? > > It shouldn't. There is even a lowmem udeb which reduces the memory footprint > [1]. > > I could even install with debian-installer on my Amiga 1200 with 64 MiB. > > Please don't necessarily take tests on qemu as a reference. Rather

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64

> Apr 28 08:11:44 debconf: Setting debconf/priority to medium > Apr 28 08:11:44 kernel: [ 135.647875] main-menu[242]: segfault at 8 ip > 0100298c (rpc f80100128e08) sp 07feff83ead1 error 1 in > main-menu[100+4000] > > After some further poking it looks like the latest

Sun mouse and keyboard unusable

Hi, I recently ran into a serious problem with Xorg on my Ultra 10: Keyboard and mouse input no longer works. The machine is still responsive, and I can SSH into it and kill the X server, so it's not completely frozen. Pressing Caps Lock or Num Lock has no effect, the keyboard LEDs don't light

Re: Bug#895131: linux-perf: Add libopencsd support to perf

> I guess we could do this. I just find it odd that a profiling library for > ARM is a build dependency on all architectures. > > I'll look into fixing libopencsd. The library seems to also include a decoder for (debug?) traces, which may be useful on other archs as well. Anyway, I reported the

Re: Bug#920902: firefox: Please split out Javascript builds into arch:all package

> While it's certainly a good idea not to ship precompiled Javascript > files in the source, the change to build-depend on NodeJS made Firefox > less portable. I'm speechless... What's the point of writing code in an arch-independent language, when you *still* end up with arch-dependency due to

Re: Latest Debian Sparc64 installer

> I'm working on a newer release, but I need to fix GRUB2 on sparc64 first > which currently fails to build there due to a change in binutils. > > It's on my TODO list for the holidays. Great! Are you going to move sparc-utils back into the tree then, so elftoaout can be used to convert the

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

Hi Adrian I do think this just reinforces the point that second-class architectures should have better, more robust support from the Debian project. For example, arch-specific packages most decidedly have a place in Debian (although they should not be the norm). There will always be such

Re: xserver problem 9.0-sparc64 netinst

> There were very few options for the old sun ultra5. It was to be a sun > experiment into low cost PC-like dirt cheap slapped together low-end > workstations. So the graphics options were bottom dollar. The ultra10 > had the benefit of actual OpenGL ready hardware but that is another > story.

Re: xserver problem 9.0-sparc64 netinst

> Am I right to guess that you have an ATI Mac64 PCI card in the Ultra5? In that > case, the error below seems important: > > [542823.455] (WW) Warning, couldn't open module mach64 > > [542823.456] (EE) Failed to load module "mach64" (module does not > exist, 0) Did you install

Re: sparc64 most important tasks

> I don't know if this is helpful, but Ubuntu Launchpad has a ppa package for > elftoaout which has been built recently. > > https://launchpad.net/~likemartinma/+archive/ubuntu/elftoaout Thanks for the pointer, but we have the tool in the repos already. It's in the sparc-utils package. But it

Re: Sid on ultra1 status

> 1) when grub starts, after "GRUB Loading kernel", I have two error lines: > # > error: out of memory. > error: no suitable video mode found. > # > then I get the menu just fine anyway. I believe this is 'normal', I got the same with two different video adapters. (Creator3D and

Re: sunffb revival

> Can you upload your package to Debian Mentors so I can review and sponsor it? I already did, and I thought I had announced it here? (please see my previous message) > Also, please don't forget to file an ITP bug report. Good idea. Since Romain has verified that it works, I think we can go

Re: sparc64 most important tasks

>>> We could modify sparc-utils maybe that it builds on the release >>> architectures similar to what the hppa porters do with their palo package. >> >> I'll have a look. It doesn't look like this package would only build/work on >> sparc. Usefulness is a different matter - but that's probably

Re: sparc64 most important tasks

> Huh? sparc64 *is* UltraSPARC. Any SPARC machine made around the mid-90ies > is an UltraSPARC. Are you confusing sun4u and sun4v? Maybe; I was referring to sun4u vs. other, older sparc32 architectures. I had SparcStation at one point, and those were certainly not sparc64. These are (obviously)

Re: sparc64 most important tasks

> Feel free to take this part over: > >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902635 Umm, ok. That's pushing it a bit. Where is that fix you mentioned in your last message, and what needs to be done to get it working? Or, are you going to finish this before your vacation? Also,

Re: sparc64 most important tasks

> It's a binutils bug: https://sourceware.org/ml/binutils/2018-08/msg00138.html > > Upstream intentionally removed a.out and coff support. I protested, it didn't > help. Further down, someone suggested switching to elftoaout - does that tool still exist? Do we need to package it?

Re: sparc64 most important tasks

> It's a binutils bug: https://sourceware.org/ml/binutils/2018-08/msg00138.html > > Upstream intentionally removed a.out and coff support. I protested, it didn't > help. Looking at https://sourceware.org/ml/binutils/2018-08/msg00166.html - I think it's likely a.out will be gone for good. Even

Re: sparc64 most important tasks

> I agree. I haven't had the time yet to upstream my patch to Qt yet. There > are a couple of other issues in upstream Qt code that I wanted to fix. In the meantime, are you going to push a patch to the Debian repo, or do you need any help? > It's a binutils bug:

Re: sparc64 most important tasks

> qtwebsockets-opensource-src: FTBFS on sparc64 and x32: tst_qmlwebsockets > segfault at startup > >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879970 I think this one is reported upstream and you already found a workaround for it? https://bugreports.qt.io/browse/QTBUG-56264 Unless it's

Re: Testing Firefox 62 on sparc64

> Yes, I know. But that means extra work with Vnc unless I want the pain that > is X11 tunneling. ssh -X doesn't work for you? It's usually relatively painless... usually.

Re: Testing Firefox 62 on sparc64

> It's an assertion that's triggered from here: > >> https://hg.mozilla.org/mozilla-central/file/tip/js/src/jit/ProcessExecutableMemory.cpp > > Did you install the debug package so we can see where it actually > crashes in ProcessExecutableMemory.cpp? Yes, otherwise the backtrace wouldn't have

Re: Testing Firefox 62 on sparc64

> Could someone with a desktop installed on their sparc64 box please > test the firefox package from experimental and check whether the > alignment-related crash is still present [1]? I have bad news, unfortunately. :( firefox crashes (reproduceably) right after launch, and it seems it might be

Re: Testing Firefox 62 on sparc64

> Could someone with a desktop installed on their sparc64 box please > test the firefox package from experimental and check whether the > alignment-related crash is still present [1]? Many thanks for building it, I will try the package later tonight! > You also should pin down experimental in

Re: sunffb revival

>> I'd be happy to maintain the package. >> The build I prepared for my system works, I just verified it this morning. > > Do you need a sponsor for that package? If yes, please upload it to > Debian Mentors and I'm happy to review it. I had to change a few things and re-import the source

Re: Latest netinst iso

>> I don't remember exactly, but I think I couldn't install any desktop tasks >> because some crucial packages were missing from the dependencies of >> desktop-base. > > We can't fix bugs that we don't know about. Sure. I can verify later if it still fails to install. > Getting Chromium to

Re: Latest netinst iso

> In addition to the information Adrian asked for, it could be interesting to > know, to which IDE channel your CDROM drive is attached and how it is > configured (Master, Slave, Cable select). > > The CDROM drive in my Ultra 10 is attached to IDE channel #2 (the IDE port > farer away from the

Re: Latest netinst iso

> You probably didn't specify the correct FTP server which is: > > Server: http://ftp.ports.debian.org > Folder: /debian-ports/ Yeah, I tried several regular mirrors first until I discovered that they don't carry debports architectures... > This bug will be fixed once debian-installer has

Re: Latest netinst iso

> Could you be also more specific about which instructions you followed to make > it work for you? The specific problem I had was due to the sparc64 installation requiring unstable repositories, which is apparently not very well supported in the Debian installer. I was able to get around this by

Re: Latest netinst iso

> The latest net install image I have found is dated 18 May 2018. Is that the > latest version?  Will that install on an Ultra 10 without problems? I wasn't able to install with the netinst ISO on my Ultra 10 without problems, but if you follow the instructions on the Debian Wiki, it should work

Re: sunffb revival

> I'll try as soon as I can on my Ultra 1. I had a working driver some > time ago (), > but not the Debian way. > > I assume the driver should work on SBus machine as well as PCI > machine, as it's UPA-based in both cases ? I'm not

Re: sunffb revival

Hi Steffen, > I am only on the periphery of this mailing list. If you are maintaining > the package from now on, I am confident that the package would be > accepted in the distribution again. I could also help with sponsoring. I'd be happy to maintain the package. The build I prepared for my