Bug#944697: security.debian.org: please bring back MD5Sum, at least for buster/updates
Package: ftp.debian.org Severity: serious Justification: breaks image generation tools Hi, I've mentioned this on #debian-ftp already, but filing a bug report in addition to make sure it's not lost. Assuming the FTP team is responsible for security's dak setup as well, we'd like to get MD5Sum back in buster/updates. python-apt relies on md5 fields internally, as documented in #944696, and a current symptom is live-wrapper's tracebacking accordingly when packages are available in security; this has been the case for the intel-microcode package, for a few hours. jessie/updates and stretch/updates seem fine (MD5Sum is present there). I don't have an opinion regarding bulleyes/updates (MD5Sum is missing there) at this point, but given at least some apt bindings don't support missing MD5Sum, it would seem premature to remove it from there as well? Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/
Bug#944696: python-apt: relies on MD5 internally to download packages
Package: python-apt
Version: 1.8.4
Severity: serious
Justification: some people want to get rid of MD5Sum in indices
Hi,
While debugging a live-wrapper (lwr) failure that started occurring
(literally) overnight, I ended up discovering it was triggered by the
intel-microcode package's getting a security upgrade.
live-wrapper 0.10 isn't affected, but live-wrapper's master branch has
an extra commit that automatically enables security sources for stable
releases.
Here's the traceback for a simple build (with a local mirror but anyone
would do) with that master branch:
$ sudo lwr -d buster -m http://wodi.home/debian -f intel-microcode
[…]
DEBUG environment: LWR_MIRROR = 'http://wodi.home/debian'
DEBUG environment: LWR_EXTRA_PACKAGES = ''
DEBUG environment: LWR_BASE_DEBS = ''
DEBUG environment: LWR_DISTRIBUTION = 'buster'
DEBUG environment: LWR_FIRMWARE_PACKAGES = 'intel-microcode'
DEBUG environment: LWR_TASK_PACKAGES = ''
[…]
Downloading udebs for Debian Installer...
INFO Downloading udebs for Debian Installer...
Updating a local cache for amd64 buster ...
DEBUG Updating local cache...
CRITICAL Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/cliapp/app.py", line 193, in _run
self.process_args(args)
File "/usr/lib/python2.7/dist-packages/lwr/run.py", line 143, in
process_args
self.start_ops()
File "/usr/lib/python2.7/dist-packages/lwr/run.py", line 286, in start_ops
apt_udeb.download_udebs(exclude_list)
File "/usr/lib/python2.7/dist-packages/lwr/apt_udeb.py", line 157, in
download_udebs
self.download_apt_file(pkg_name, pool_dir, False)
File "/usr/lib/python2.7/dist-packages/lwr/apt_udeb.py", line 141, in
download_apt_file
version.fetch_binary(destdir=pkg_dir)
File "/usr/lib/python2.7/dist-packages/apt/package.py", line 867, in
fetch_binary
if _file_is_same(destfile, self.size, self._records.md5_hash):
SystemError: error return without exception set
After some debugging, it turned out that merely accessing the
self._records.md5_hash item is sufficient to reproduce this issue.
Looking at the current (as of 2019-11-14 00:27:00 UTC) indices for
buster/updates on security.debian.org, one can only see SHA256 entries
in Release and Packages files, which is likely the reason for
python-apt's explosion. I've asked #debian-ftp to add MD5Sum entries
back at least for buster/updates, and will file another bug report for
that in a moment to make sure it isn't lost.
Looking at even the most recent python-apt code in experimental (1.9.0),
MD5 still seems hardwired, e.g. in apt/packages.py's fetch_binary():
def fetch_binary(self, destdir='', progress=None):
# type: (str, AcquireProgress) -> str
"""Fetch the binary version of the package.
The parameter *destdir* specifies the directory where the package will
be fetched to.
The parameter *progress* may refer to an apt_pkg.AcquireProgress()
object. If not specified or None, apt.progress.text.AcquireProgress()
is used.
.. versionadded:: 0.7.10
"""
base = os.path.basename(self._records.filename)
destfile = os.path.join(destdir, base)
if _file_is_same(destfile, self.size, self._records.md5_hash):
logging.debug('Ignoring already existing file: %s' % destfile)
return os.path.abspath(destfile)
acq = apt_pkg.Acquire(progress or apt.progress.text.AcquireProgress())
acqfile = apt_pkg.AcquireFile(acq, self.uri, self._records.md5_hash, #
type: ignore # TODO: Do not use MD5 # nopep8
self.size, base, destfile=destfile)
acq.run()
if acqfile.status != acqfile.STAT_DONE:
raise FetchError("The item %r could not be fetched: %s" %
(acqfile.destfile, acqfile.error_text))
return os.path.abspath(destfile)
Notice the TODO on the apt_pkg.AcquireFile(), but it would probably
break in the same way as in the live-wrapper case a few lines before, on
the self._records.md5_hash item.
The same goes for fetch_source().
Since getting rid of MD5Sum entirely is a topic that comes up on a
regular fashion (with fingers being pointed at jigdo in particular), it
looks to me python-apt should get some attention as well; hence filing
at serious severity. Feel free to adjust as required.
Cheers,
--
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/
Re: Kernel / modules version do not match in weekly testing install CD
On Wed, 2019-11-13 at 14:58 +, Steve McIntyre wrote: > On Sun, Nov 10, 2019 at 10:26:18AM +0100, Julien Bigot wrote: > Hi guys, > > We've had a spate of build failures in debian-installer recently that > have triggered problems like this. I've just pushed a fix now thay > should hopefully get things going again. Thank you for your reply. However, poking around I don't find any updated iso files (yet) :(
Missing November 11 2019 testing iso
To whom it may concern, I could not find any testing iso in the November 11 2019 weekly build. Thanks, JT
Bug#944679: extlinux: Visual bugs while editing a long kernel command line
Package: extlinux Version: 3:6.04~git20190206.bf6db5b4+dfsg1-1 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear Maintainer, My current kernel command line is about 400-character long. When it was shorter, I didn't have any issues when I wanted to edit this line in the bootloader screen by selecting some entry and pressing "E". I recently added some other kernel parameters to the cmd line, and I noticed many visual bugs in the bootloader screen. Basically with each cursor movement (back and forth), I get an extra text line in the screen output (copy of the current line scrolled up). Also characters in the cmd line disappear or change when I move the cursor back. The visual bugs make it almost impossible to edit the kernel cmd line. Also When I press the backspace key (or the back arrow key) for a longer period of time (let's assume I want to delete some parameters entirely from the line), I hear the hardware beeper which is really annoying. I found out that the problem appears when I have more than 4 lines of text on the screen when editing the cmd line. So fifth (and next ones) will trigger the visual bugs, while 4 (and less) won't. So what to do with it? - -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (130, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.3.11-amd64 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages extlinux depends on: ii libc6 2.29-3 Versions of packages extlinux recommends: ii syslinux-common 3:6.04~git20190206.bf6db5b4+dfsg1-1 extlinux suggests no packages. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEE5JPPWm5C7TFDUMqpzQRoEHcbZSAFAl3MNmEACgkQzQRoEHcb ZSCybg/+LbzriiSLoPsLRK9iW+GmMD4U82YnK6OoEjz7YMIWi8yJzzzgsRgoSJs5 yOpXTdbMQchScmbrloMb7jBDWkaK594+2RvL+ZOyeYt7SNAwIyZEv4AdA1DiNArn moKQk48WPKV4gNqVXnjlvs+Eab6nFh7AokzMSG7TxHiZ283s1aQYOdUjiVWdU2YH pLgd1qRsKf7tz1kJfTmTx4tx8w8dR7Qxe6vuesShEr+QHwb4PjliroXzxrTJYBAe WVikkk6aYkWrDJHmn2SOmrXdwzUOpkIOuSludoP2ctDZfjsHbigNMI40smQI/t0F qnLwZ0QscOybxE1z4l4WHnpr3opl3EyLg2XNvbdDCXBZdFP+YmVHG06sZrEwJktc UALj5pTAytB87vK7p77kMsAOniZJj2T47mdh8ggJmYiGby4JkGWr3Ya9YTWRoQxX v1ohflHg8OC88iXWaAQPzi/gtpcM17IkeR5EDWV+/FtOzSVReqjpXwI37DvJ0CUp BcB/ZBdLJ2MTAU5D7UKm/0OIjPcfE110ICXrbCn+oBvhZ+Tn1GeYrQje4nW1Rfb5 dWU2Ue4FzGPun/d/M1zVmVSUYocPpY6nLOn6Qh5+t6yK0vKzkuyhFgsrURrJwLQ8 qFEjFQfep4vpM0NF+JHriPGglyVpkaEHklCl9IqxcPVbIEL7AjQ= =QWGV -END PGP SIGNATURE-
Re: Kernel / modules version do not match in weekly testing install CD
On Sun, Nov 10, 2019 at 10:26:18AM +0100, Julien Bigot wrote: >Hello again, > >After some digging I found this rather old (but still open?) bug that >describes something pretty similar to what I'm seeing (at least from the >symptoms point of view, I don't know about the root causes) >https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779616 > >Is the behavior I'm observing a known one that is described by this bug or >should I open a new bug? On Tue, Nov 12, 2019 at 11:20:54PM +0100, Svante Signell wrote: >Hello, > >Downloading both the latest weekly (20191028) and daily build (2019110) of >debian-testing-amd64-netinst.iso the following error message is displayed: >"No kernel modules were found. This is probably due to a mismatch between the >kernel used by this version of the installer and the version of the kernel >version available in the archive. etc" > >Other people, Julien Bigot, on this list have also seen the problem. Where can >I >find the latest netinst iso not having this problem. An yes, a bug should be >filed for this problem. Hi guys, We've had a spate of build failures in debian-installer recently that have triggered problems like this. I've just pushed a fix now thay should hopefully get things going again. -- Steve McIntyre, Cambridge, UK.st...@einval.com "The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts." -- Bertrand Russell
Re: missing debian iso files in cdimage.debian.org (weekly-live-builds)
On Wed, Nov 13, 2019 at 03:06:33PM +0100, Saverio Brancaccio wrote: >Dear Debian CD Team, > >since a couple of weeks, looking at the path below, there are no iso image >files anymore but only meta files updates (.log, checksums, packagelists, >etc.). >Is there any reason for not uploading/updating also debian testing iso images? >(e.g. CI breaks?) > >https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/ >weekly-live-builds/amd64/iso-hybrid/ We've had a spate of broken d-i builds lately. I've just pushed a fix now. Assuming that works, I'll trigger a rebuild of the weeklies tomorrow. -- Steve McIntyre, Cambridge, UK.st...@einval.com Google-bait: https://www.debian.org/CD/free-linux-cd Debian does NOT ship free CDs. Please do NOT contact the mailing lists asking us to send them to you.
missing debian iso files in cdimage.debian.org (weekly-live-builds)
Dear Debian CD Team, since a couple of weeks, looking at the path below, there are no iso image files anymore but only meta files updates (.log, checksums, packagelists, etc.). Is there any reason for not uploading/updating also debian testing iso images? (e.g. CI breaks?) https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/weekly-live-builds/amd64/iso-hybrid/ Many thanks in advance for the information, regards. Saverio
