• Updated installation images for Debian Ports 2019-11-22

    From Bob Tracy@21:1/5 to John Paul Adrian Glaubitz on Fri Nov 22 15:10:01 2019
    On Fri, Nov 22, 2019 at 11:23:10AM +0100, John Paul Adrian Glaubitz wrote:
    (...)
    The images for alpha and ia64 could have issues because of the missing
    vim package [3]. Someone needs to have a look at vim on these two architectures.

    (...)
    [3] https://buildd.debian.org/status/package.php?p=vim&suite=sid

    I've noticed I haven't been able to update the "vim" packages for a long
    time. Michael Cree -- if you see this, I think you explained the
    problem to me many moons ago. In any event, there has been a held
    update to "vim-common" on alpha for at *least* the past year. We seem
    to be stuck at version "2:8.1.0875-5".

    --Bob

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael Cree@21:1/5 to John Paul Adrian Glaubitz on Fri Nov 22 20:10:02 2019
    On Fri, Nov 22, 2019 at 03:09:09PM +0100, John Paul Adrian Glaubitz wrote:
    On 11/22/19 2:40 PM, Bob Tracy wrote:
    I've noticed I haven't been able to update the "vim" packages for a long time. Michael Cree -- if you see this, I think you explained the
    problem to me many moons ago. In any event, there has been a held
    update to "vim-common" on alpha for at *least* the past year. We seem
    to be stuck at version "2:8.1.0875-5".

    Someone needs to fix the testsuite on alpha:

    https://buildd.debian.org/status/fetch.php?pkg=vim&arch=alpha&ver=2%3A8.1.2136-1&stamp=1570855095&raw=0

    That's not going to help at the moment because vim is bd-uninstallable.

    The real problem is guile-2.0 and guile-2.2, both of which FTBFS, and
    are blocking the building of many other packages.

    Cheers
    Michael.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From rkn@21:1/5 to John Paul Adrian Glaubitz on Fri Nov 22 23:50:01 2019
    Alpha installer errors with a mismatch between installer kernel version
    and archive kernel version.

    On 11/22/2019 7:23 PM, John Paul Adrian Glaubitz wrote:
    Hi!

    I just uploaded updated installation images 2019-07-22 for the
    following Debian Ports architectures [1]:

    * alpha
    * hppa
    * ia64
    * m68k
    * powerpc
    * ppc64
    * sparc64

    debian-installer images for netboot and sh4 can be found in [2].

    I have successfully tested the sparc64 image, but not the other images,
    so the issue with the kernel module versions mismatch has been fixed.

    The images for alpha and ia64 could have issues because of the missing
    vim package [3]. Someone needs to have a look at vim on these two architectures.

    [1] https://cdimage.debian.org/cdimage/ports/2019-11-22/
    [2] https://cdimage.debian.org/cdimage/ports/debian-installer/
    [3] https://buildd.debian.org/status/package.php?p=vim&suite=sid
    Adrian


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From rkn@21:1/5 to John Paul Adrian Glaubitz on Sat Nov 23 00:30:01 2019
    uname -a gives: 5.3.0-2-alpha-generic and Debian 5.3.9-2 (2019-11-12). 
    Exact error message is that no kernel modules can be found.

    I'm using the ISO image from the pool, I'm installing from a CD to a raw
    disk on a system that does not have Linux on it.


    On 11/23/2019 7:47 AM, John Paul Adrian Glaubitz wrote:
    On 11/22/19 11:41 PM, rkn wrote:
    Alpha installer errors with a mismatch between installer kernel version and archive kernel version.
    Are you sure about that? I just checked the CD image contents in pool-alpha/ main/l/linux/ and the udebs have the correct version number which is 5.3.9-3.

    What kernel version does "uname -a" report? Did you boot your own custom kernel?

    Adrian


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to rkn on Sat Nov 23 00:50:01 2019
    On 11/23/19 12:24 AM, rkn wrote:
    uname -a gives: 5.3.0-2-alpha-generic and Debian 5.3.9-2 (2019-11-12).  Exact error message is that no kernel modules can be found.

    But the ISO image contains the correct module packages. I just verified that again.

    I'm using the ISO image from the pool, I'm installing from a CD to a raw disk on a system that does not have Linux on it.

    Can you list the CD contents of pool-alpha/main/l/linux?

    Adrian

    --
    .''`. John Paul Adrian Glaubitz
    : :' : Debian Developer - glaubitz@debian.org
    `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
    `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From rkn@21:1/5 to John Paul Adrian Glaubitz on Sat Nov 23 01:10:01 2019
    On 11/23/2019 8:41 AM, John Paul Adrian Glaubitz wrote:

    On 11/23/19 12:24 AM, rkn wrote:
    uname -a gives: 5.3.0-2-alpha-generic and Debian 5.3.9-2 (2019-11-12).  Exact error message is that no kernel modules can be found.
    But the ISO image contains the correct module packages. I just verified that again.
    I'm reporting the exact readout that the system gives me when I run
    uname -a, I don't know anything more than that and I've done nothing to
    the image but burn it.  The error states that it is probably due to a
    mismatch between the kernel the installer uses and the kernel available
    in the archive.  The installer can't see anything that isn't the same
    version as itself.
    I'm using the ISO image from the pool, I'm installing from a CD to a raw disk on a system that does not have Linux on it.
    Can you list the CD contents of pool-alpha/main/l/linux?
    I'm using it on the video output of the DS10L I'm trying to set it up on
    (using aboot option 0), I can reboot and run aboot option 1 and copy it
    from the terminal if you need a specific/complete listing.  An example
    is: srm-modules-5.2.0-2-alpha-generic-di_5.2.9-2_alpha.udeb.  The other contents are *-modules-5.2.0-2-alpha-generic-di_5.2.9-2_alpha.udeb.
    Adrian


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to rkn on Sat Nov 23 10:20:02 2019
    On 11/23/19 1:04 AM, rkn wrote:
    I'm reporting the exact readout that the system gives me when I run uname -a, I don't know anything more than that and I've done nothing to the image but burn it.  The error states that it is probably due to a mismatch between the kernel the installer uses and the kernel available in the archive.  The installer can't see anything that isn't the same version as itself.

    Yes, I'm aware of what this error means.

    I'm using the ISO image from the pool, I'm installing from a CD to a
    raw disk on a system that does not have Linux on it.
    Can you list the CD contents of pool-alpha/main/l/linux?
    I'm using it on the video output of the DS10L I'm trying to set it up on (using aboot option 0), I can reboot and run aboot option 1 and copy it
    from the terminal if you need a specific/complete listing.
    An example is: srm-modules-5.2.0-2-alpha-generic-di_5.2.9-2_alpha.udeb.
    The other contents are *-modules-5.2.0-2-alpha-generic-di_5.2.9-2_alpha.udeb.

    If it lists 5.2.9-2, you are using the wrong image. I just again verified the ISO from [1] and it definitely has 5.3.9-3 udebs in it.

    Adrian

    [1] https://cdimage.debian.org/cdimage/ports/2019-11-22/debian-10.0-alpha-NETINST-1.iso

    --
    .''`. John Paul Adrian Glaubitz
    : :' : Debian Developer - glaubitz@debian.org
    `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
    `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From rkn@21:1/5 to John Paul Adrian Glaubitz on Sun Nov 24 22:00:01 2019
    Thank you for the help, I've re-downloaded and re-burned the image, I
    must have been using an older version because it does now sense the
    hardware.

    Unfortunately, it now fails during the base system install, there seems
    to be something wrong with the whiptail package.  It doesn't give a
    specific error.  Installation media integrity check passes.


    On 11/23/2019 6:18 PM, John Paul Adrian Glaubitz wrote:
    On 11/23/19 1:04 AM, rkn wrote:
    I'm reporting the exact readout that the system gives me when I run uname -a,
    I don't know anything more than that and I've done nothing to the image but >> burn it.  The error states that it is probably due to a mismatch between the
    kernel the installer uses and the kernel available in the archive.  The
    installer can't see anything that isn't the same version as itself.
    Yes, I'm aware of what this error means.

    I'm using the ISO image from the pool, I'm installing from a CD to a
    raw disk on a system that does not have Linux on it.
    Can you list the CD contents of pool-alpha/main/l/linux?
    I'm using it on the video output of the DS10L I'm trying to set it up on
    (using aboot option 0), I can reboot and run aboot option 1 and copy it
    from the terminal if you need a specific/complete listing.
    An example is: srm-modules-5.2.0-2-alpha-generic-di_5.2.9-2_alpha.udeb.
    The other contents are *-modules-5.2.0-2-alpha-generic-di_5.2.9-2_alpha.udeb.
    If it lists 5.2.9-2, you are using the wrong image. I just again verified the ISO from [1] and it definitely has 5.3.9-3 udebs in it.

    Adrian

    [1] https://cdimage.debian.org/cdimage/ports/2019-11-22/debian-10.0-alpha-NETINST-1.iso

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to rkn on Sun Nov 24 22:50:01 2019
    On 11/24/19 9:53 PM, rkn wrote:
    Unfortunately, it now fails during the base system install, there seems to be something
    wrong with the whiptail package.  It doesn't give a specific error.

    Yes, it's the broken vim package that needs to be fixed as I mentioned in my initial mail.

    vim is considered an essential package and installation won't finish if it's not
    installable.

    Adrian

    --
    .''`. John Paul Adrian Glaubitz
    : :' : Debian Developer - glaubitz@debian.org
    `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
    `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bob Tracy@21:1/5 to Michael Cree on Mon Nov 25 13:50:01 2019
    On Sat, Nov 23, 2019 at 07:36:11AM +1300, Michael Cree wrote:
    That's not going to help at the moment because vim is bd-uninstallable.

    The real problem is guile-2.0 and guile-2.2, both of which FTBFS, and
    are blocking the building of many other packages.

    I downloaded the Debian source for "guile-2.0_2.0.13+1-5.3" and successfully built the binary packages on my PWS-433au without having to modify anything.
    My guess is some kind of toolchain or other build environment issue on
    the "buildd" servers.

    Michael -- I've got the following ".deb" packages available, and you're
    welcome to them if they would be of any help getting us unstuck:

    guile-2.0_2.0.13+1-5.3_alpha.deb
    guile-2.0-libs_2.0.13+1-5.3_alpha.deb
    guile-2.0-dev_2.0.13+1-5.3_alpha.deb
    guile-2.0-libs-dbgsym_2.0.13+1-5.3_alpha.deb
    guile-2.0-doc_2.0.13+1-5.3_all.deb

    Just need a place to upload them where you can get to them, or I could
    send them as e-mail attachments if all else fails: the "libs" package is
    the largest at 2,262,128 bytes.

    I'll get started on trying to build "guile-2.2" later today.

    --Bob

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to Skye on Mon Nov 25 16:50:02 2019
    On 11/25/19 4:41 PM, Skye wrote:
    Are the build servers for Alpha public facing? I plan to test install on Alpha in a few day and having access to the code and environment could prove useful.
    What do you mean with "public facing"? They are on the internet, of course,
    but they are not publicly accessible for obvious reasons.

    Adrian

    --
    .''`. John Paul Adrian Glaubitz
    : :' : Debian Developer - glaubitz@debian.org
    `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
    `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Skye@21:1/5 to Michael Cree on Mon Nov 25 16:50:02 2019
    Are the build servers for Alpha public facing? I plan to test install on Alpha in a few day and having access to the code and environment could prove useful.

    =Skye

    -----Original Message-----
    From: Bob Tracy [mailto:rct@frus.com]
    Sent: Monday, November 25, 2019 5:40 AM
    To: Michael Cree; John Paul Adrian Glaubitz; debian-alpha@lists.debian.org Subject: Re: Updated installation images for Debian Ports 2019-11-22

    On Sat, Nov 23, 2019 at 07:36:11AM +1300, Michael Cree wrote:
    That's not going to help at the moment because vim is bd-uninstallable.

    The real problem is guile-2.0 and guile-2.2, both of which FTBFS, and
    are blocking the building of many other packages.

    I downloaded the Debian source for "guile-2.0_2.0.13+1-5.3" and successfully built the binary packages on my PWS-433au without having to modify anything.
    My guess is some kind of toolchain or other build environment issue on
    the "buildd" servers.

    Michael -- I've got the following ".deb" packages available, and you're
    welcome to them if they would be of any help getting us unstuck:

    guile-2.0_2.0.13+1-5.3_alpha.deb
    guile-2.0-libs_2.0.13+1-5.3_alpha.deb
    guile-2.0-dev_2.0.13+1-5.3_alpha.deb
    guile-2.0-libs-dbgsym_2.0.13+1-5.3_alpha.deb
    guile-2.0-doc_2.0.13+1-5.3_all.deb

    Just need a place to upload them where you can get to them, or I could
    send them as e-mail attachments if all else fails: the "libs" package is
    the largest at 2,262,128 bytes.

    I'll get started on trying to build "guile-2.2" later today.

    --Bob

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to Bob Tracy on Mon Nov 25 18:40:02 2019
    Hi Bob!

    On 11/25/19 1:40 PM, Bob Tracy wrote:
    I downloaded the Debian source for "guile-2.0_2.0.13+1-5.3" and successfully built the binary packages on my PWS-433au without having to modify anything. My guess is some kind of toolchain or other build environment issue on
    the "buildd" servers.

    What build environment did you use? Were you on the latest version of gcc-9
    and binutils? Was the default compiler gcc-9 or anything lower?

    Michael -- I've got the following ".deb" packages available, and you're welcome to them if they would be of any help getting us unstuck:

    guile-2.0_2.0.13+1-5.3_alpha.deb
    guile-2.0-libs_2.0.13+1-5.3_alpha.deb
    guile-2.0-dev_2.0.13+1-5.3_alpha.deb
    guile-2.0-libs-dbgsym_2.0.13+1-5.3_alpha.deb
    guile-2.0-doc_2.0.13+1-5.3_all.deb

    Just need a place to upload them where you can get to them, or I could
    send them as e-mail attachments if all else fails: the "libs" package is
    the largest at 2,262,128 bytes.

    In order to be able to use them, you need the .changes and .buildinfo files
    as well. And the build must not include the all.deb package, only the architecture-dependent packages.

    Adrian

    --
    .''`. John Paul Adrian Glaubitz
    : :' : Debian Developer - glaubitz@debian.org
    `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
    `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Skye@21:1/5 to Skye on Mon Nov 25 18:50:01 2019
    Thanks. That answers my question ;-) I was thinking if they were on GitLab or similar one could pull intermediate builds for testing.

    If someone could kindly provide the link for issues for Alpha that would be most helpful.

    =Skye

    -----Original Message-----
    From: John Paul Adrian Glaubitz [mailto:glaubitz@physik.fu-berlin.de]
    Sent: Monday, November 25, 2019 8:44 AM
    To: Skye; 'Bob Tracy'; 'Michael Cree'; debian-alpha@lists.debian.org
    Subject: Re: Updated installation images for Debian Ports 2019-11-22

    On 11/25/19 4:41 PM, Skye wrote:
    Are the build servers for Alpha public facing? I plan to test install on Alpha in a few day and having access to the code and environment could prove useful.


    What do you mean with "public facing"? They are on the internet, of course,
    but they are not publicly accessible for obvious reasons.

    Adrian

    --
    .''`. John Paul Adrian Glaubitz
    : :' : Debian Developer - glaubitz@debian.org
    `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
    `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael Cree@21:1/5 to Bob Tracy on Tue Nov 26 00:10:01 2019
    On Mon, Nov 25, 2019 at 06:40:04AM -0600, Bob Tracy wrote:
    On Sat, Nov 23, 2019 at 07:36:11AM +1300, Michael Cree wrote:
    That's not going to help at the moment because vim is bd-uninstallable.

    The real problem is guile-2.0 and guile-2.2, both of which FTBFS, and
    are blocking the building of many other packages.

    I downloaded the Debian source for "guile-2.0_2.0.13+1-5.3" and successfully built the binary packages on my PWS-433au without having to modify anything. My guess is some kind of toolchain or other build environment issue on
    the "buildd" servers.

    Did you build with latest toolchain? I suspect the issue has
    appeared with toolchain changes (hard to pin down when because there
    was quite a period in which a new version of guile-2.0 was not
    uploaded).

    And the bug (a segfault when texi documentation is built with the
    recently built guild executable) looks to be present elsewhere too
    (take a look at #941218 where comment #10 seen on Ubuntu looks
    suspiciously like what we see on Alpha assuming it occurs at the
    same place).

    Michael -- I've got the following ".deb" packages available, and you're welcome to them if they would be of any help getting us unstuck:

    Unless built in clean chroot with only the build dependencies installed
    and with an up to date toolchain they won't be much use to us.

    Cheers,
    Michael.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bob Tracy@21:1/5 to Michael Cree on Tue Nov 26 02:10:02 2019
    On Tue, Nov 26, 2019 at 12:00:59PM +1300, Michael Cree wrote:
    Did you build with latest toolchain? I suspect the issue has
    appeared with toolchain changes (hard to pin down when because there
    was quite a period in which a new version of guile-2.0 was not
    uploaded).

    And the bug (a segfault when texi documentation is built with the
    recently built guild executable) looks to be present elsewhere too
    (take a look at #941218 where comment #10 seen on Ubuntu looks
    suspiciously like what we see on Alpha assuming it occurs at the
    same place).

    I think I answered the toolchain question in my reply to Adrian's
    earlier message. There was an attached "packages" file with the complete
    list of what I've got installed on the PWS.

    Unless built in clean chroot with only the build dependencies installed
    and with an up to date toolchain they won't be much use to us.

    The toolchain is up-to-date, but I don't have the infrastructure to
    support a clean chroot environment, even on another local system if I
    were to try and use a cross-compiler vs. a native build. In reference
    to the build dependencies, if particular versions aren't specified, or
    are only loosely specified (e.g., >= some value), are the dependencies considered "best" satisfied with a stable package version meeting the requirement? Or is the current unstable version of a dependency
    preferred when building for "sid"? Many variables to consider, I guess.

    --Bob

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael Cree@21:1/5 to Bob Tracy on Tue Nov 26 04:50:01 2019
    On Mon, Nov 25, 2019 at 07:02:15PM -0600, Bob Tracy wrote:
    On Tue, Nov 26, 2019 at 12:00:59PM +1300, Michael Cree wrote:
    Did you build with latest toolchain? I suspect the issue has
    appeared with toolchain changes (hard to pin down when because there
    was quite a period in which a new version of guile-2.0 was not
    uploaded).

    I think I answered the toolchain question in my reply to Adrian's
    earlier message. There was an attached "packages" file with the complete list of what I've got installed on the PWS.

    I don't seem to have received that message.

    Taking it that you did use up to date toolchain then that is rather
    interesting that guile-2.0 built for you. I ran a test rebuild a
    week or two ago and it failed.

    Maybe I should try again, but if it fails for me again that would
    raise issues of:

    - UP versus SMP since I test built on an SMP system.

    - sbuild environment.

    I will set a test rebuild going again soon and report back.

    are only loosely specified (e.g., >= some value), are the dependencies considered "best" satisfied with a stable package version meeting the requirement? Or is the current unstable version of a dependency
    preferred when building for "sid"? Many variables to consider, I guess.

    Yes, built against up to date sid.

    Cheers
    Michael.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bob Tracy@21:1/5 to Michael Cree on Tue Nov 26 05:50:02 2019
    (This is a separate copy to the list, just to keep everyone informed.
    No attachment included.)

    On Tue, Nov 26, 2019 at 04:49:15PM +1300, Michael Cree wrote:
    I don't seem to have received that message.

    I'll try sending again just to you... The attached "packages" file was
    on the order of 500k, and it's possible an upstream mailer got offended
    at the message size. In *this* letter, I'll append the list gzipped.

    Here's the relevant portion of that earlier posting:

    gcc is version 9.2.1 (Debian 9.2.1-19)
    ld is version 2.33.1 (binutils 2.33.1-4)
    kernel version is 5.3.0 built from the kernel.org source tree

    Other packages are as in the attached "packages" file ("dpkg -l"
    output).

    Started the "guile-2.2" build. So far, so good after 12+ hours :-).

    --Bob

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to Darren Goossens on Wed Nov 27 08:40:03 2019
    On 11/27/19 8:13 AM, Darren Goossens wrote:
    I am thinking I am going to have to make my own installer, since
    apparently the DFSG prevent the requisite firmware going on the disk.

    No, it's not the DFSG. It's my lack of time to patch the debian-cd package
    to support building firmware images for Debian Ports architectures.

    I am planning to get this resolved during the Christmas holidays.

    Adrian

    --
    .''`. John Paul Adrian Glaubitz
    : :' : Debian Developer - glaubitz@debian.org
    `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
    `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Darren Goossens@21:1/5 to All on Wed Nov 27 08:20:03 2019
    Just recording this simpleton's experience.

    I booted the 22 Nov image. AlphaServer1200

    It boots fine, but asks for qlogic 1040.bin firmware on removable media.

    The system has a PCI card that controls an IDE HDD and an IDE CDRW,
    plus a SCSI CDROM (that I boot off) plus a floppy drive plus a PCI USB
    card and a few SCSI HDD.

    the boot messages show the USB -- including identifying the device, eg
    SanDisk CRUZ. But when I try to load the firmware from removable media
    (USB, floppy, CD), there is no evidence of any removable media even
    being accessed/polled.

    No CD lights come on, no floppy light comes on, no USB stick LEDs come on.

    It does initialise the network (DEC tulip).

    I tried putting s CD with firmware into the SCSI CDROM drive and
    mounting it manually on /cdrom, but the installer still does not see
    it, though I can look at it in the shell.

    I am thinking I am going to have to make my own installer, since
    apparently the DFSG prevent the requisite firmware going on the disk.

    I'm not a complete newbie, but I am not a developer or sysadmin. I've
    read around a bit, but a pointer to the most useful guide to adding
    stuff to the iso and burning my own version would be helpful. I assume
    I have to mount the iso, unpack the initramfs image and add stuff in
    there, but it's a bit daunting. I'm not asking anyone to do it for me,
    but an pointer to a good tutorial or how-to would help. I've found
    some stuff on the Debian pages and elsewhere, but no luck so far.

    Cheerio

    Darren

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to Michael Cree on Wed Nov 27 14:20:01 2019
    On 11/26/19 4:49 AM, Michael Cree wrote:
    Taking it that you did use up to date toolchain then that is rather interesting that guile-2.0 built for you. I ran a test rebuild a
    week or two ago and it failed.

    Maybe I should try again, but if it fails for me again that would
    raise issues of:

    - UP versus SMP since I test built on an SMP system.

    - sbuild environment.

    I will set a test rebuild going again soon and report back.

    If it's indeed an issue of UMP vs SMP again like we have for openjdk-8, we
    can just blacklist guile-2.0 and guile-2.2 on electro and imago and have
    it built on tsunami only which is a UMP machine.

    Adrian

    --
    .''`. John Paul Adrian Glaubitz
    : :' : Debian Developer - glaubitz@debian.org
    `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
    `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael Cree@21:1/5 to John Paul Adrian Glaubitz on Sat Nov 30 00:20:01 2019
    On Wed, Nov 27, 2019 at 02:15:30PM +0100, John Paul Adrian Glaubitz wrote:
    On 11/26/19 4:49 AM, Michael Cree wrote:
    Taking it that you did use up to date toolchain then that is rather interesting that guile-2.0 built for you. I ran a test rebuild a
    week or two ago and it failed.

    Maybe I should try again, but if it fails for me again that would
    raise issues of:

    - UP versus SMP since I test built on an SMP system.

    - sbuild environment.

    I will set a test rebuild going again soon and report back.

    If it's indeed an issue of UMP vs SMP again like we have for openjdk-8, we can just blacklist guile-2.0 and guile-2.2 on electro and imago and have
    it built on tsunami only which is a UMP machine.

    I've done a test on an XP1000 (UP) and it got past the failure seen
    on the buildds but errored out in one of 40000 or so tests in the
    test suite.

    Relevant line in log:

    ERROR: 00-repl-server.test: repl-server: HTTP inter-protocol attack - arguments: ((system-error "fport_write" "~A" ("Broken pipe") (32)))

    Bob: how did you get past this test or did it pass on your build?

    Cheers,
    Michael.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael Cree@21:1/5 to Michael Cree on Sat Nov 30 02:00:02 2019
    On Sat, Nov 30, 2019 at 12:10:28PM +1300, Michael Cree wrote:
    On Wed, Nov 27, 2019 at 02:15:30PM +0100, John Paul Adrian Glaubitz wrote: I've done a test on an XP1000 (UP) and it got past the failure seen
    on the buildds but errored out in one of 40000 or so tests in the
    test suite.

    Relevant line in log:

    ERROR: 00-repl-server.test: repl-server: HTTP inter-protocol attack - arguments: ((system-error "fport_write" "~A" ("Broken pipe") (32)))

    I've worked out how to run the test manually. Just run:

    ./check-guile 00-repl-server.test

    in the guile build directory. It passes more often than not and
    only fails occasionally. I see that there is a patch in the
    debian/patches directory to avoid a race condition in this test.
    But I don't know guile so don't understand the code.

    I could try building again and hope we get a successful build soon...

    Cheers,
    Michael.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bob Tracy@21:1/5 to Michael Cree on Sat Nov 30 06:30:01 2019
    On Sat, Nov 30, 2019 at 12:10:28PM +1300, Michael Cree wrote:
    ERROR: 00-repl-server.test: repl-server: HTTP inter-protocol attack - arguments: ((system-error "fport_write" "~A" ("Broken pipe") (32)))

    Bob: how did you get past this test or did it pass on your build?

    It passed on mine. I didn't save the build log for the 2.0 build,
    but here's the relevant section of the 2.2 build log:

    (...)
    make check-TESTS
    make[4]: Entering directory '/opt/downloads/work/guile-2.2/guile-2.2-2.2.6+1' Testing /opt/downloads/work/guile-2.2/guile-2.2-2.2.6+1/meta/guile ...
    with GUILE_LOAD_PATH=/opt/downloads/work/guile-2.2/guile-2.2-2.2.6+1/test-suite Running 00-initial-env.test
    Running 00-repl-server.test
    Running 00-socket.test
    Running alist.test
    (...)

    --Bob

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bob Tracy@21:1/5 to Michael Cree on Sat Nov 30 06:40:01 2019
    On Sat, Nov 30, 2019 at 01:59:36PM +1300, Michael Cree wrote:
    (...) It passes more often than not and
    only fails occasionally. I see that there is a patch in the
    debian/patches directory to avoid a race condition in this test.
    But I don't know guile so don't understand the code.

    There are a few of the "guile" tests that have some timing aspects where sometimes you "win" the race, and other times you "lose". In an earlier private message, I indicated one such test where I had to lengthen the
    sleep intervals before following actions were taken (because my system
    is so slow relative to modern hardware). If I didn't mention the
    specific test, it had to do with making sure the "guild" compiler would
    clean up after itself if interrupted. On the PWS, it was taking a few
    more seconds for the interrupt to be received and processed than the
    test originally allowed. You wouldn't have seen or experienced that
    particular problem on any of the "buildd" systems.

    --Bob

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Skye@21:1/5 to Michael Cree on Sat Nov 30 17:00:01 2019
    Bob, that is excellent information. Thank you for sharing!

    =Skye

    -----Original Message-----
    From: Bob Tracy [mailto:rct@frus.com]
    Sent: Friday, November 29, 2019 10:31 PM
    To: Michael Cree; John Paul Adrian Glaubitz; debian-alpha@lists.debian.org Subject: Re: Updated installation images for Debian Ports 2019-11-22

    On Sat, Nov 30, 2019 at 01:59:36PM +1300, Michael Cree wrote:
    (...) It passes more often than not and
    only fails occasionally. I see that there is a patch in the
    debian/patches directory to avoid a race condition in this test.
    But I don't know guile so don't understand the code.

    There are a few of the "guile" tests that have some timing aspects where sometimes you "win" the race, and other times you "lose". In an earlier private message, I indicated one such test where I had to lengthen the
    sleep intervals before following actions were taken (because my system
    is so slow relative to modern hardware). If I didn't mention the
    specific test, it had to do with making sure the "guild" compiler would
    clean up after itself if interrupted. On the PWS, it was taking a few
    more seconds for the interrupt to be received and processed than the
    test originally allowed. You wouldn't have seen or experienced that
    particular problem on any of the "buildd" systems.

    --Bob

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to All on Sat Nov 30 18:00:01 2019
    Hi!

    On Nov 30, 2019, at 4:54 PM, Skye <skye@20maguire.com> wrote:

    Bob, that is excellent information. Thank you for sharing!

    I suggest turning this into a patch. Fixing guile-2.0 and guile-2.2 on alpha is dearly needed, so patches are really welcome.

    Adrian

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Skye@21:1/5 to All on Sat Nov 30 21:50:01 2019
    If someone could point me to the web location I would be happy to do so. It seems I am a little in the dark on that aspect.

    =Skye

    -----Original Message-----
    From: John Paul Adrian Glaubitz [mailto:glaubitz@physik.fu-berlin.de]
    Sent: Saturday, November 30, 2019 9:52 AM
    To: Skye
    Cc: Bob Tracy; debian-alpha@lists.debian.org
    Subject: Re: Updated installation images for Debian Ports 2019-11-22

    Hi!

    On Nov 30, 2019, at 4:54 PM, Skye <skye@20maguire.com> wrote:

    Bob, that is excellent information. Thank you for sharing!

    I suggest turning this into a patch. Fixing guile-2.0 and guile-2.2 on alpha is dearly needed, so patches are really welcome.

    Adrian

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bob Tracy@21:1/5 to John Paul Adrian Glaubitz on Sun Dec 1 01:10:02 2019
    On Sat, Nov 30, 2019 at 05:51:45PM +0100, John Paul Adrian Glaubitz wrote:
    On Nov 30, 2019, at 4:54 PM, Skye <skye@20maguire.com> wrote:

    Bob, that is excellent information. Thank you for sharing!

    I suggest turning this into a patch. Fixing guile-2.0 and guile-2.2 on alpha is dearly needed, so patches are really welcome.

    Adrian

    I definitely appreciate that fixing the guile-2.0 and guile-2.2 builds on
    alpha is a priority, and if there was anything useful I could contribute
    beyond demonstrating it can be done, I'd be happy to provide patches.

    The problem *I* ran into was entirely due to how s-l-o-w my system is.
    Since the issue is associated with exactly *one* of the guile-2.2 tests
    (for the "guild" compiler), I'm reluctant to have a "hack" workaround
    become part of the test suite source, especially since the problem will
    never be seen on one of the "buildd" hosts. I didn't see the problem
    with the exact same test on the "guile-2.0" build because 2.0 runs more efficiently on older, slower systems.

    If you feel otherwise as far as wanting a patch, the simple diff is
    appended below. Nothing magical about the "sleep" values I picked. The
    first one is to allow enough time for the "guild" compiler to actually
    begin doing something, and *may* be too long to wait for a machine that
    can actually get out of its own way :-(. The second sleep value can be anything less than the 100 seconds allowed by the test script for the
    compile to complete, but needs to be long enough to allow the "guild"
    compiler to receive and process the sent SIGINT.

    All that being said, I'd *definitely* think twice about blindly changing
    the sleep values. Again, you'll never see this issue on the "buildd"
    systems. If I were the package maintainer, I'd reject this patch :-).

    (file is in "guile-2.2-2.2.6+1/test-suite/standalone" after extracting
    the source package)

    --- test-guild-compile.orig 2019-11-30 17:56:39.276270948 -0600
    +++ test-guild-compile 2019-11-30 17:57:18.874959718 -0600
    @@ -23,10 +23,10 @@
    pid="$!"

    # Send SIGINT.
    -sleep 2 && kill -INT "$pid"
    +sleep 5 && kill -INT "$pid"

    # Wait for 'guild compile' to terminate.
    -sleep 2
    +sleep 15

    # Check whether there are any leftovers.
    for file in "$target"*

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to Bob Tracy on Tue Dec 3 13:30:02 2019
    Hi!

    On 12/1/19 1:07 AM, Bob Tracy wrote:
    All that being said, I'd *definitely* think twice about blindly changing
    the sleep values. Again, you'll never see this issue on the "buildd" systems. If I were the package maintainer, I'd reject this patch :-).

    (file is in "guile-2.2-2.2.6+1/test-suite/standalone" after extracting
    the source package)

    --- test-guild-compile.orig 2019-11-30 17:56:39.276270948 -0600
    +++ test-guild-compile 2019-11-30 17:57:18.874959718 -0600
    @@ -23,10 +23,10 @@
    pid="$!"

    # Send SIGINT.
    -sleep 2 && kill -INT "$pid"
    +sleep 5 && kill -INT "$pid"

    # Wait for 'guild compile' to terminate.
    -sleep 2
    +sleep 15

    # Check whether there are any leftovers.
    for file in "$target"*

    I don't think there is anything wrong per se with increasing the test timeouts, it won't hurt on any architecture and build machine.

    Adrian

    --
    .''`. John Paul Adrian Glaubitz
    : :' : Debian Developer - glaubitz@debian.org
    `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
    `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Witold Baryluk@21:1/5 to glaubitz@physik.fu-berlin.de on Wed Jan 22 23:30:01 2020
    Ok, thanks.

    Yes, I did use the previous images and it did work.
    I just wanted to report on the new images with new kernel ;)

    Cheers,
    Witold

    On Wed, 22 Jan 2020 at 22:12, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:

    Hello!

    On 1/22/20 11:08 PM, Witold Baryluk wrote:
    I tried alpha ISO, and it does boot, and I can proceed with most of the steps, but debootstrap does fail installing init_1.57_alpha.deb
    Just use one of the older images for the time being. Such installation issues can occur when images were built when the archive was in an inconsistent state.

    You can dist-upgrade the system later.

    Adrian

    --
    .''`. John Paul Adrian Glaubitz
    : :' : Debian Developer - glaubitz@debian.org
    `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
    `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to Witold Baryluk on Wed Jan 22 23:20:01 2020
    Hello!

    On 1/22/20 11:08 PM, Witold Baryluk wrote:
    I tried alpha ISO, and it does boot, and I can proceed with most of the steps, but debootstrap does fail installing init_1.57_alpha.deb
    Just use one of the older images for the time being. Such installation issues can occur when images were built when the archive was in an inconsistent
    state.

    You can dist-upgrade the system later.

    Adrian

    --
    .''`. John Paul Adrian Glaubitz
    : :' : Debian Developer - glaubitz@debian.org
    `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
    `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to Witold Baryluk on Wed Jan 22 23:40:02 2020
    On 1/22/20 11:25 PM, Witold Baryluk wrote:
    Yes, I did use the previous images and it did work.
    I just wanted to report on the new images with new kernel ;)
    The images in the date folders should be considered untested.

    There are a couple of things that I need to fix before I can
    create reliable images again, including adding firmware to the
    images.

    Adrian

    --
    .''`. John Paul Adrian Glaubitz
    : :' : Debian Developer - glaubitz@debian.org
    `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
    `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)