(...)
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
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
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/Adrian
[2] https://cdimage.debian.org/cdimage/ports/debian-installer/
[3] https://buildd.debian.org/status/package.php?p=vim&suite=sid
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
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/19 12:24 AM, rkn wrote:I'm reporting the exact readout that the system gives me when I run
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 it on the video output of the DS10L I'm trying to set it up onI'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
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 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 itI'm using the ISO image from the pool, I'm installing from a CD to aCan you list the CD contents of pool-alpha/main/l/linux?
raw disk on a system that does not have Linux on 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.
[1] https://cdimage.debian.org/cdimage/ports/2019-11-22/debian-10.0-alpha-NETINST-1.iso
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,Yes, I'm aware of what this error means.
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.
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.I'm using it on the video output of the DS10L I'm trying to set it up onI'm using the ISO image from the pool, I'm installing from a CD to aCan you list the CD contents of pool-alpha/main/l/linux?
raw disk on a system that does not have Linux on it.
(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
[1] https://cdimage.debian.org/cdimage/ports/2019-11-22/debian-10.0-alpha-NETINST-1.iso
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.
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.
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,
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.
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.
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:
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).
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.
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.
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.
I don't seem to have received that message.
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.
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.
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.
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)))
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 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.
(...) 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.
On Nov 30, 2019, at 4:54 PM, Skye <skye@20maguire.com> wrote:
Bob, that is excellent information. Thank you for sharing!
On Nov 30, 2019, at 4:54 PM, Skye <skye@20maguire.com> wrote:
Bob, that is excellent information. Thank you for sharing!
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
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"*
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.debJust 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
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.debJust 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
Yes, I did use the previous images and it did work.The images in the date folders should be considered untested.
I just wanted to report on the new images with new kernel ;)
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 349 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 138:25:56 |
| Calls: | 7,613 |
| Calls today: | 1 |
| Files: | 12,789 |
| Messages: | 5,685,991 |