Re: Bug#729699: debian-installer: apt-setup/multiarch argument amd64 isn't numeric in multiplication debconf-apt-progress
Source: apt
Source-Version: 0.9.13~exp1
Sorry for my extremely long delay in looking at this bug. Fortunately,
it seems to have been fixed long ago, so this has just been a
bookkeeping delay.
On Tue, Mar 11, 2014 at 03:20:15AM +0100, Cyril Brulebois wrote:
> bofh80 <afm404@gmail.com> (2013-11-16):
> > using cdimage / non-free/ daily / testing
> > To install testing/jessie
> > used apt-setup/multiarch option, which appears to work fine.
> >
> > Get spurious messages all the way through the package install after
> > the initial base setup.
> >
> > The attached preseed as you can see is quite basic, when adding :i386
> > packages you also get messages with amd64 replace with i386. again
> > nothing seems to be broken. installer/syslog will be attached.
> >
> >
> > in-target: Argument "amd64" isn't numeric in multiplication (*) at /usr/bin/debconf-apt-progress line 168, <STDIN> line ##.
>
> AFAICT this is due to the way lines are split up:
> | sub handle_status ($$$) {
> | my ($from, $to, $line) = @_;
> | my ($status, $pkg, $percent, $description) = split ':', $line, 4;
> | …
> | $percent = ($percent * $len / 100 + $min);
>
> multiarch means you get arch-qualified package ($pkg:$arch), which
> breaks the assumption made above. I'm therefore reassigning this bug
> report to debconf. Same code in 1.5.49 (wheezy) and 1.5.42 (current
> sid).
It pretty much has to be apt's responsibility to get the message framing
right here; I don't think it would be reasonable to expect debconf to
guess at how to split up the fields, particularly because the
"description" field at the end continues to the end of the line and
might itself contain colons.
Fortunately, it looks as though this was fixed some time back in apt.
The git history is confusing to me, but it seems to have been this
commit:
https://salsa.debian.org/apt-team/apt/commit/dd640f3cece45693b57b49d90ba7cc4134577070
Notice in particular the 'StringSplit(PackageName, ":")[0]' change.
This seems to have been part of apt 0.9.13~exp1:
apt (0.9.13~exp1) experimental; urgency=low
* Improve the API for APT::Upgrade::Upgrade()
* Re-add "Calculating upgrade..." message
* move upgrade related code into upgrade.{cc,h}
* Move ListUpdate/AcquireUpdate into update.{cc,h}
* Add new apt-pkg/install-progress.h with APT::Progress::PackageManager
progress reporting classes
* Move the status-fd progress reporting out of the pkgDPkgPM class
and into PackageManagerProgressFd
* Fix reading dpkg --status-fd on reinstalls
* Add new APT::Status-deb822-Fd progress output
* add Acquire::http::Proxy-Auto-Detect to the apt.conf.5 manpage
(closes: 726597)
* Fix detection when multiarch packages are reported by dpkg as
disappeared Packages
* test/integration/run-tests: output the failed test names
* Code Cleanup in pkgDPkgPM
* prepare next ABI via #if (APT_PKG_MAJOR >= 4 && APT_PKG_MINOR >= 13)
* add new pid_t ExecFork(std::set<int> KeepFDs)
* Avoid flickering when "apt-get -o DpkgPM::Progress-Fancy=1" is use
* use sysconf(_SC_OPEN_MAX) in ExecFork()
-- Michael Vogt <mvo@debian.org> Fri, 01 Nov 2013 10:03:06 +0100
If there's still a similar corner case somewhere that I missed when
looking for this, it should probably be taken up with the apt
maintainers, for the same reason as above.
--
Colin Watson (he/him) [cjwatson@debian.org]
Reply to: